1. 11

  2. 1

    This is exciting stuff. For me aside from a few hardware things, the biggest thing preventing me from moving 100% to BSD is certain programs I can’t live without. I’m hoping this can help bridge the gap a little.

    1. 2

      Which programs will you miss on FreeBSD?

      1. 1

        Can’t speak for the OP, but for me not having Spotify is annoying. I haven’t tried Linuxulator, though.

        I’ve also had problems with audio in general on FreeBSD, but in fairness I haven’t much time to read up on it or debug it.

        1. 5

          I do not use Spotify but there are two ‘native’ ways of using Spotify on FreeBSD.

          1. Using TUI interface in console using audio/spotify-tui port and/or package: https://github.com/Rigellute/spotify-tui

          2. Using daemon mode with audio/spotifyd port and/or package: https://github.com/Spotifyd/spotifyd

          There are also ‘non native’ ways like using WINE for example: https://forums.freebsd.org/threads/howto-spotify-on-freebsd-amd64.34780/

          For me personally Spotify is the same bitch as Netflix. Support FreeBSD (or just be OS-agnostic using web service) or GTFO (or even die) for me. Besides even on Firefox/Chrome on Linux/Windows you still can not get even 1080p with Netflix … and people pay for that …

          Till they get their mind back I prefer 1080p from Torrent downloads.

          Its nice that Netflix uses and commits code to FreeBSD but its hypocrisy to use FreeBSD and NOT allow using the service on it … at least for me.

          Same with TOM TOM maps which use Linux and Linux is not one of the supported systems.

          Not sure if that helps but regards ;)

          1. 1

            Thank you! This pointed me in the right direction, and I have it working now.

            In case anybody stumbles on this later (there’s apparently not much info around for spotify on FreeBSD), what I found is that spotify-tui doesn’t actually play anything, but uses the Spotify web API to view playlists and other info and control playback. Installing and running it (the command is spt, not spotify-tui) shows a “device” list that was empty for me.

            I spent some time trying to configure my sound card (a Roland UA-25EX USB card) to show up in the list. This ended up being a dead end with respect to Spotify, but I discovered how to set the default sound card with “sysctl hw.snd.default_auto=9”, and that made audio work in Firefox (at least on YouTube). Finally, buried in the README on GitHub, I found out it doesn’t support streaming directly, but requires another player.

            So I looked at spotifyd, which can play audio but has no UI. I learned my lesson and followed its README, and I’m able to play back after telling it my username, password, and to use the “portaudio” backend.

            My only complaint is that I liked finding “related” artists in the Web player UI, but I’ve been working on a tool to help with that anyway.

            1. 1

              Welcome. Glad you got it working :)

          2. 1

            Seamonkey supports flash; could use that.

            1. 1

              FWIW, Spotify doesn’t seem to use Flash.

        2. 1

          You may be lucky, but probably not. The Linux compat layer is good for things that could easily have FreeBSD versions but are not open source and so can’t be rebuilt. It doesn’t support things that use very Linux-specific features (such as Chrome or Docker).

          The things I like about FreeBSD are well-designed kernel interfaces. For example, Chrome’s sandboxing is far simpler to implement with Capsicum than seccomp-bpf or SELinux (though the Chrome team is incredibly hostile to taking patches to support other operating systems). Containers are trivial with jails instead of the mess of kernel namespaces, cgroups, and more seccomp-bpf (which, ironically, means no one invested in the tooling for making them useable, because they almost work usefully out of the box, whereas on Linux you need a load of goo to make them work at all and so it’s easier to justify building the tooling). Unfortunately, this significant difference in kernel API design philosophies means that implementing these Linux-specific APIs is nontrivial (especially when, for things like seccomp-bpf, they leak kernel implementation details) in a compat layer.