1. 44

  2. 7

    Lets get back to FreeBSD audio then. What FreeBSD offered? A whooping 256 OSS channels mixed live in kernel for low latency. Everything audio related just worked out of the box – and still works today.

    This is literally the exact opposite of my experience with OSS on BSD. Terrible audio quality, lagging and crackling, audio distortion. OSS was complete garbage every time I’ve tried and I could never get audio to work properly ever.

    1. 3


      which FreeBSD version and which hardware was that?


      1. 2

        I’ve tried FreeBSD 11.4, 12.1, and 13.0.

        I’ve also tried various versions of NetBSD, OpenBSD, and HardenedBSD.

        I really want to use BSD. There is so much about it that I really like about it. But as someone who listens to music almost 24/7, I just can’t do it when the audio is like this. Nothing I ever tried would fix the audio, I had literally given up after a certain point.

        And my speakers are: Logitech Z-2300 Computer Speakers

        1. 1

          I don’t think speakers have much to do with it - the OS talks to the sound card.

          As a counter example, for me, audio has worked as well under FreeBSD as it does in Linux. Which is to say, it’s not the easiest to configure, but once that’s out of the way it works fine.

          I mainly use a Roland UA-25EX external USB sound card, and sometimes also an ancient Creative SBLive! Value “CT4780” PCI card. I’m not doing anything fancy, though, they’re going into boring, $100 Bose stereo speakers.

          My only real complaint about audio on FreeBSD is poor Spotify support. The TUI isn’t that great, and spotifyd crashes a lot.

          1. 3

            I don’t think speakers have much to do with it - the OS talks to the sound card.

            If they’re USB speakers, then it does, because it has to talk to it as a USB device, ignoring the computer’s sound chip in favour of the speakers’.

            1. 2

              I run FreeBSD as a deskop, and my solution to Spotify is to run Mopidy with the Iris frontend and the spotify plugin in a linux virtual machine with Icecast outputing a radio stream. It sounds hopelessly complicated, but in practices is not more than a few config files and setting up a VM with some flavor of modern linux on it (I use debian).

              I can create a how to blog post if you’re interested.

              The bonus here is anything with a web browser and a stream player can interface with this.

              1. 1

                Yeah, for a while I was using the Spotify app on my phone as a remote control to spotifyd running on the desktop, but spotifyd had a bug where it crashed on songs shorter than 60 seconds. So I tried building from source, thinking I’d try fixing it myself. The bug seems to be fixed in the Git repo, but I was getting so many other crashes I gave up.

                For now I’m running the spotify app on my macbook and plugging the speakers into that. :-/

            2. 1

              Speakers are not important here - what is your sound card/chipset?

              1. 1

                Oh, uh… according to lspci -v | grep -i audio I’m using:

                00:1b.0 Audio device: Intel Corporation 7 Series/C216 Chipset Family High Definition Audio Controller (rev 04)
                        Subsystem: Dell 7 Series/C216 Chipset Family High Definition Audio Controller

                And according to ALSA, my card is HDA-Intel - HDA Intel PCH

                1. 1

                  I have similar/same audio chipset here:

                  # pciconf -lv | grep -A 4 hdac
                  hdac0@pci0:0:27:0:	class=0x040300 card=0x21cf17aa chip=0x1c208086 rev=0x04 hdr=0x00
                      vendor     = 'Intel Corporation'
                      device     = '6 Series/C200 Series Chipset Family High Definition Audio Controller'
                      class      = multimedia
                      subclass   = HDA

                  … and sound is nothing less then great here.

                  I do not know how else I can help you :(

        2. 5

          Hey vermaden - nice post.

          I have a couple of questions.

          1. What is the state of FreeBSD on a raspberry Pi?
          2. How is accelerated OpenGL/Vulkan looking on FreeBSD? Relatedly - how about X11+compositor or Wayland?

          I am definitely going to move my old RAID server over to FreeBSD from Linux+zfs. I want to see if other use cases make sense.

          1. 4


            thank You.

            AD. 1. It works and most ‘server’ things are supported. I own Raspberry Pi 2 and while I did not tried X11 there all other things worked flawlessly there. Recently (week ago maybe) I got a report from person on Twitter that Raspberry Pi 4 with 4 GB RAM was also fully supported and even with X11 desktop. The ‘3’ is older then ‘4’ so it should also be working well.

            AD. 2. I did not tried Wayland on FreeBSD but I have heard that some people use it. OpenGL acceleration works as desired no matter if with Intel, AMD or Nvidia but I am not sure about Vulkan support. I was able to find this thread on Nvidia Forums so Vulkan with Nvidia is probably not possible:


            About that RAID setup … I do not know how much data/space you need but if you fit below 5 TB then this may be interesting for you :)


            1. 2

              How is accelerated OpenGL/Vulkan looking on FreeBSD?

              Opengl: good. Vulkan: I wasn’t able to get it to work. Mesa has only experimental support for vulkan on my gpu, though it does work on linux. Probably works with a well-supported gpu (newer amd/intel; any nvidia).

              Relatedly - how about X11+compositor or Wayland?

              X11: good. Wayland: no idea.

              1. 2

                You didn’t ask about it directly, but FWIW, FreeBSD doesn’t support OpenCL with NVIDIA GPUs.

                Other than that, I haven’t had any problems with NVIDIA GPUs and OpenGL or graphics in general.

                1. 2

                  Thanks - I don’t need Cuda or OpenCL.

                  Having accelerated OpenGL is the only requirement.

              2. 5

                What I’d like to ask is, why FreeBSD over its fork by the former project lead, Dragonfly?

                1. 6

                  FreeBSD 4.x had UP kernel - only single processor was supported. FreeBSD 5.x was first version with SMP kernel - multiple processors/cores supported. Matt Dillon - the man that leaved FreeBSD project and started DragonflyBSD - wanted to have very simple implementation of that SMP with 1:1 threading model while the majority of FreeBSD developers wanted to implement quite more complicated version with M:N threading model. It was probably not only space where they disagreed but was one of the major ones for sure. The problem with M:N model is that when done correctly then it can be more efficient then 1:1 model but making M:N efficient is very hard task to do and FreeBSD devs failed to make M:N better. That is why FreeBSD went back to the 1:1 in their newer scheduler but Dillon was miles away with its DragonflyBSD back then.

                  1. 8

                    From people who were in the project back then, Dillon also had a habit of doing large commits with code that made big changes to core things without any explanation and without fixing any of the things that he broke. The FreeBSD project didn’t speak publicly about his departure, so he was able to frame it as a disagreement over design direction and not about his inability to work with others.

                    1. 3

                      Thanks for that back stage information. Did not knew that.

                  2. 3

                    As a freebsd user, I have the opposite question. What reason is there to prefer dfly over freebsd? HAMMER2?

                    1. 3

                      The best SMP implementation out there, seeing virtually no contention due to Matt’s insistence on lockfreeness/locklessness.

                      1. 6

                        Several things that keeps me away from migrating to DragonflyBSD:

                        • no ZFS - that can be replaced with HAMMER2 probably but still …
                        • no ZFS Boot Environments - I heard a talk that some work for similar stuff on HAMMER has begun
                        • no virtualization - I know the work began on that part recently but will take time
                        • no Virtualbox - very easy and fast for various systems testing
                        • no WINE - at least last time I checked
                        • smaller amount of packages/ports - some software available on FreeBSD is absent here

                        I really like DragonflyBSD approach to SMP efficiency and HAMMER2 concept/implementation but FreeBSD currently just offers more. I also like DragonflyBSD’s decision to dump Sendmail and use DMA instead. Maybe in several years I will try to make a switch :)

                        Also running FreeBSD on 9 years old laptop (ThinkPad W520) means I do not strive for performance (or SMP efficiency) that much these days :p


                  3. 4

                    That article was amazing. I really enjoyed reading it. I wish there were similar in depth articles about NetBSD and OpenBSD as well.

                    1. 3

                      Thank You :)

                    2. 2

                      Docker has become like a “universal server executable” by now. It does not matter if other container-systems can do the same, if you want 100 developers at your company to quickly have the same development environment, tell them to pull the versioned build docker from the local docker registry server, and most of them should be able do this without any major issues. Want to quickly set up a service somewhere? They are likely to support Docker too. FreeBSD jails are unique to FreeBSD.

                      Also, most modern Linux distros now place binaries in just /usr/bin, then add symlinks from /bin,/sbin and /usr/sbin. Why FreeBSD thinks it’s a good idea to place binaries in these six directories: /bin, /sbin, /usr/bin, /usr/sbin, /usr/local/bin and /usr/local/sbin, is beyond me. What does it solve that a modern Linux distro can not?

                      I get the separation between “system packages” and “user installed packages that are also available to other users”, but this should IMO be handled by a package manager, not by letting users place stray files outside of /home. I assume that’s why FreeBSD has an emphasis of being able to reset everything to the “base system” because /usr/local may easily become a mess?

                      1. 4

                        Docker has become like a “universal server executable” by now.

                        I must admit it - and many other people from FreeBSD ‘world’ admit that too - that Docker tooling (not the technology behind) was the thing that Docker got so much traction. IMHO its pity that Jails management was not put into similar way (may little more thought out). But from what I heard Docker containers run only on Linux so that does not make them portable. CentOS to Ubuntu migration does not count :p

                        Also, most modern Linux distros now place binaries in just /usr/bin.

                        That is separation between Base System binaries (at /{bin,sbin} and /usr/{bin,sbin} dirs) and Third Party Packages mainained by pkg(8) located at /usr/local/{bin/sbin} dir.

                        We all know differences between bin (user) and sbin (admin) binaries but in FreeBSD there is also more UFS related division. When there was only UFS in FreeBSD world then /bin and /sbin were available at boot before /usr was mounted - this the historical (and useful in UFS setups) distinguish between /{bin,sbin} and /usr/{bin,sbin} dirs. In ZFS setups it does not matter as all files are on ZFS pool anyway.

                        I get the separation between “system packages” and “user installed packages that are also available to other users” (…)

                        Users on FreeBSD are not allowed to install packages, only root can do that.

                        I assume that’s why FreeBSD has an emphasis of being able to reset everything to the “base system” because /usr/local may easily become a mess?

                        Its not about ‘mess’ in /usr/local as FreeBSD Ports Maintainers keep the same logic and order in the /usr/ports as in the Base System. Its about another layer of ‘security’ if you fuck up something. If you broke RPM database in the Linux distribution you need to reinstall (or need really heavy repair time). On FreeBSD when you (for some readon) mess up the packages you just reset the packages to ‘zero’ state and Base System is untouched.

                        Hope that helps.

                        1. 1

                          Thanks for the thoughtful answers! I have considered using FreeBSD on a server or two, since it seems like a very solid and well put together system, while at the same time keeping things minimal and fast.

                          I feel like a good package system in combination with ZFS (or another filesystem with snapshots) makes many of the old ideas and solutions obsolete. Why keep anything in /usr/local if a package system can handle (possibly manually built) packages better? For instance, on Arch Linux, creating a custom package is so easy and fast that the threshold is low enough to never having to install anything directly in /usr/local. And once a user did that, the threshold is equally low to upload it to AUR, so that new users can just use that one.

                          Similarly, I’m not sure that the additional layer of ‘security’ of having a Base System covers anything that a good package system (like pacman) in combination with filesystem snapshots can cover. Do you have an example?

                          About Docker, AFAIK it can also be used on Windows and macOS, not only Linux. There is some heavy black box lifting going on within those applications, though. :)

                          1. 3

                            One of the things you want to avoid is if some package gets the great idea to install a new compiler and name it “cc” and override the system compiler, or add libs/includes in such a way that makes it super hard to get back into a working system. If some random bsd port adds libc.so to /usr/local/lib, you are not prevented from running programs, because system programs link to stuff in /usr/lib, and not “any random lib everywhere I find .so files in”. A well meaning package system will of course tell you that this new “cc” seems to collide with the system compiler packaged cc if that did exist before, but if it didn’t, then the package system might work against you trying to get back. BSD wants you to be able to use base things without hiccups (which is lovely when things act up), then allow packages to add things on top of that, without risking the base set of files, be it manpages, libs, includes, fsck tools or whatever.

                            1. 1

                              I could not stress this better. Thanks.

                              1. 1

                                These seem like theoretical problems to me. Two packages can’t both install cc in /usr/bin on Arch Linux, and that’s the only directory that is in $PATH by default (since the other bin directories are symlinks).

                                Isn’t it better to just install everything on the system with a package manager, so that nothing collides and everything is in its place? Then, if the combined results of a package upgrade should ever go wrong, one can just undo it by using filesystem snapshots.

                                1. 2

                                  Indeed, if the package manager is in control of all installed software then it’s not a problem. It’s only relatively recently that this has happened with FreeBSD (Package Base) and the work is still ongoing - before this the base system was distributed purely in tarball format, with the package manager only managing /usr/local.

                                  1. 1

                                    It’s quite common on FreeBSD to have both a base-system version with long-term support guarantees in /usr/bin and a newer version from ports in /usr/local/bin. It’s up to you which order you put the two in you PATH and it’s also up to you whether you install aliases that favour one over the other in specific cases.

                                    1. 1

                                      Why would you want that? If you want to use an experimental version, install that and test that it looks good. Or, replace it with the stable version again if your tests didn’t pass.

                                      Or, for example, Firefox and Open Office are available as both stable and fresher versions on Arch Linux, and you can install both at the same time.

                                      If you need some special piece of software to have an old and stable environment, you can use a jail, docker or a VM for that.

                          2. [Comment removed by author]

                            1. 1

                              Velut :)