1. 24

  2. 7

    Good that there is various alternatives depending on the use case and that it’s not too hard to simply run FreeBSD installing what you need.

    1. 4

      The writing was on the wall with the first rebranding.

      1. 2

        There’s other Freebsd-based alternatives, although I find Dragonfly makes a much better desktop than anything freebsd-based.

        Freebsd really went to hell ever since they booted Matt from it.

        1. 3

          What makes DragonflyBSD a better desktop OS in your opinion?

          1. 5

            The LWKT design and the concurrent lockfree/lockless system servers design does allow for improved responsiveness. HAMMER2 is a great filesystem with checksums and snapshotting but without the overhead of ZFS. Dragonfly also does generally do a better job of keeping graphics drivers synced against Linux’s.

            This is of course Ignoring Freebsd’s defaults (terrible for desktop, terrible for servers, terrible in general).

            IMHO, Freebsd’s been severely mismanaged after the Dragonfly crowd left the project.

            1. 4

              That “freebsd defaults” link is really not a great source of information as you can tell it was done by someone who has a lot of grudges and did a lot of research about certain areas but the author isn’t well versed in those areas either.

              But more to the point: I’ve tried getting defaults changed, as a project committer. The reactions I’m conditioned to expect are “we don’t know if that’s safe to change or what it will break” (even though tons of users make the change for best practices); “get a ports exp-run done” which may happen, but results seem to be ignored because nobody else cares; “Please provide extremely detailed performance benchmarks” and feel like you’re expected to produce a master’s thesis on the topic; and finally, “our downstream vendors will be affected”.

              So I kind of gave up on getting those changes made.

              1. 22

                I feel your pain. I’ve stepped back quite a bit from the FreeBSD community in general since I stood down from the Core Team and it’s been really good for my mental health. There are some amazing people in the community but there are enough toxic individuals that I find it really hard to remain actively involved, especially when senior members of the community actively enable these people. The project has lost good contributors who have learned that there are projects that they can be paid to work on and don’t have to deal with obnoxious people.

                It’s a shame, because there are a lot of things I really like about FreeBSD:

                • A stable ABI (and KBI) across major releases makes it really easy to support.
                • Up-to-date packages. A recent thread prompted me to try spotifyd for a FreeBSD-based NAS that’s connected to my living-room speakers. pkg ins spotifyd and a bit of config and it worked (with the gotcha that it only starts if you start it before avahi-daemon, not afterwards, with a really unhelpful error message), so I decided to install it on the Raspberry Pi in the bedroom that runs musicpd (with an NFS mount from the NAS). After 15 minutes of trying to follow the official instructions, I still didn’t have it working.
                • It’s a great dev system. This is related to the two above points, but it’s trivial to install the latest C++ toolchain, for example. The latest LLVM is always available, whereas for Ubuntu we end up having to enable a bunch of third-party repos that, on a good day, don’t conflict with the base system. At $WORK, I do a lot of my development in a FreeBSD VM with libc patched to use snmalloc instead of jemalloc (which works as a nice stress test of snmalloc). Rebuilding the entire base system for this to work is trivial.
                • ZFS out of the box with boot environments is great. Accidentally broke libc with one of my patches? Never mind, just revert to the old BE and reboot. Incremental backups are trivial with zfs send / zfs receive (I really like zfsbackup-go for sending encrypted backups to the cloud).
                • Capsicum and Jails actually give me the security abstractions that I want (and, apparently, so does everyone else: WASI is basically Capsicum).
                • The base system is small and doesn’t install thousands of packages that I don’t want.
                • They don’t break things that work. The interface to ifconfig is the same as when I learned it in the ’90s. The thing that originally made me switch to FreeBSD from Linux full time around 2002 that sound Just Worked. Linux went through a ‘we’ve deprecated OSS, rewrite everything to use ALSA’ phase (and ALSA was so bad that you had years of GNOME and KDE doing sound mixing in [incompatible] userspace daemons, that were then replaced with PulseAudio). Back then, on Linux, I could have either a KDE app or a GNOME app able to send notification bings, but not both. On FreeBSD 4.x, I had to configure each one to use a different /dev/dspN, and XMMS to use a third, leaving the default /dev/dsp for things like BZFlag, but then it worked. With 5.x, that manual configuration step went away. Most recently, I plugged a 5.1 surround-sound system into a FreeBSD box and it worked out of the box, no configuration, and things like VLC used it automatically

                But there are also some systematic failings.

                • There is a strong resistance to anything other than C in the base system. The OS still suffers from classes of vulnerabilities that could be eliminated by using modern C++.
                • The build system and developer infrastructure (revision control, CI, and so on) infrastructure are archaic. When I contribute to FreeBSD, more than half of my time is wasted fighting these things. It’s not surprising that I rarely have the motivation to do so.
                • There is a strong resistance to taking dependencies on things that most people use. Taking a dependency on ZFS (or, at least, on a filesystem with cheap snapshots and clones, which can be taken as a given for any future filesystem) would enable a load of useful things in terms of updates, jail management, and so on, but these are all relegated to third-party components that aren’t tightly integrated with the base system. Similarly, kernel modules use an extra function call for locks (to preserve the ABI), whereas the code compiled into the kernel inlines them. Shipping kernel modules as LLVM bitcode and compiling at install time would eliminate this, but add an LLVM dependency which only 99.9% of the users want.
                • /etc must be in the root FS and contains both defaults and user-modified things. This means you can’t have a read-only root FS and do any configuration updates (which makes sharing a root FS difficult, which is annoying for PXE boot, jails, and a bunch of other things).
                • Most of the management tools are still set up for managing a single machine. If you want to manage jails, you have to install all of the control-plane things inside. Even pkg, which is jail-aware, implements this by running the version of pkg that is inside the jail, rather than having a single copy of the pkg tool and having it manage the entire system. The init system is completely fine for managing one machine, but it sucks for managing a fleet of jails or for managing a machine that is part of a cluster.
                • Closely related, the configuration system is still fixated on static configuration. Libucl is a wonderful library, which allows lots of layering and default configs, but is still not widely used in spite of having been written by a FreeBSD developer. When you insert an optical disk or plug in a USB drive (for example), the kernel sends a message to a device that devd monitors. devd then runs a shell script based on a static configuration file (or, at least, set of files). If you want to do something in a DE dynamically based on the current user, you need to either reimplement the devd parsing logic (fortunately, devd can stream a copy of its raw kernel event stream) or provide a single static hook and implement stuff yourself. You can’t just do what most consumers of devd events want and dynamically register to receive a notification for a particular thing while your process runs. Things like WiFi configuration for multiple networks are all done via a pile of shell scripts dangled off a devd hook.
                • The container story sucks. For large-scale deployments (where FreeBSD used to be a serious contender) containers are the deployment and orchestration mechanism of choice. FreeBSD’s jail subsystem (particularly with VNET) is ideal for this, but the tooling doesn’t exist. Doing this well depends on packaging the base system into smaller components so that you can have a minimal base system install in each container.
                • Closely related, the packaged base system was initially prototyped over 5 years ago, but is still not finished. It basically works, but is unsupported.
                • There are structural issues in how security issues for ports are handled. The infrastructure is not good at incremental builds of package sets that have a single change (and there are no priority runs for security updates), so you wait 3-4 days from public disclosure until a package is released (if you build your own package sets, you can usually get that down to an hour or less). That’s totally unacceptable in a modern system.

                This is off the top of my head, and I’m probably missing some good and some bad. I still use FreeBSD a lot, but the project is increasingly becoming irrelevant and has structural resistance to improvement. I’d love to see a group of active developers fork the project. Unfortunately, TrueOS / TrueNAS was not this. Their approach to packaging the base system, for example, would have made things significantly worse for anyone wanting to implement a container solution on top of FreeBSD.

                1. 3

                  Yes, it is structural and endemic. For a long time, freebsd has seemed fully hopeless. I honestly just moved on. There’s no point fighting to get freebsd back on the right track, when Dragonfly does exist.

                  1. 5

                    ZFS and GELI are too important to me or I’d consider Dragonfly.

                    1. 3

                      Regarding GELI, Is LUKS/dm-crypt not good enough for you? Dragonfly implements that.

                      HAMMER2 isn’t ZFS, but there’s some overlap.

                      1. 2

                        I made the mistake of using ZFS recently only to discover I can’t shrink a pool. I accidentally added a disk without raid when I was trying to set up a mirror and now that machine needs to be rebuilt. ZFS feels really really unfinished.

                        1. 2

                          Actually, you can undo it thanks to bookmarks in recent ZFS versions, but I’ve never tried it.

                          ZFS is not unfinished, it’s just not meant for users who don’t architect their entire storage system before setting it up.

                          edit: zpool commands should come with an “ARE YOU SURE?” with detailed explanations of what the commands do. But like the unix we’ve all come to know and love, a single typo or forgotten word can destroy your entire system.

                      2. 3

                        How is dragonfly on laptops? I see there’s an install guid for an XPS 13 on the website, and for a chromebook… would I expect semi-modern hardware to generally work, and then have enough up to date packages that it’s not incredibly painful?

                      3. 3

                        Is there a better “freebsd defaults” link? I’m running FreeBSD as my home NAS (and a general workhorse for any service needed), but would like to learn more about ways to configure it better.

                        The reason I went with FreeBSD instead of any Linux is that in general I find FreeBSD nicer to use, as all the documentation is there, and ports are easily readable. Not to mention that at time I needed ZFS :)

                      4. 2

                        I currently use FreeBSD also as my desktop/laptop system. I have everything I need. Including suspend/resume, playing games using WINE and virtualization for Linux and Windows using VirtualBox (or Bhyve if needed).

                        I have checked DragonflyBSD documentation but it can be outdated so I have several questions if I may …

                        Is there VirtualBox for DragonflyBSD? … or Bhyve at least? (need virtualization solution for Windows and Linux)

                        What about suspend/resume? According to this page - https://www.dragonflybsd.org/docs/user/DragonFlyOnLaptops/ - it does not work for even as old laptops as ThinkPad T420 (9 years old).

                        Does HAMMER2 supports transparent compression (with lz4 or gzip for example)?

                        Can DragonflyBSD boot directly from HAMMER2 without other fat/ufs partitions?

                        Can DragonflyBSD run games using WINE (like Fallout or Colin McRae Rally 2.0 for example)?

                        Thanks in advance.

                        1. 1


                          YMMV. That page is seldom updated so I’d recommend testing it yourself.

                          Is there VirtualBox for DragonflyBSD?

                          vkernels only. Qemu without acceleration. Planned but not done.

                          Can DragonflyBSD boot directly from HAMMER2 without other fat/ufs partitions?

                          Yes, it’s been, for a few years, the default for /.

                          Can DragonflyBSD run games using WINE (like Fallout or Colin McRae Rally 2.0 for example)?

                          It used to work, before x86-32 was dropped entirely in dragonfly. Currently pending work on binary emulation wine-side.

                          Does HAMMER2 supports transparent compression (with lz4 or gzip for example)?

                          Yes, lz4, enabled by default.

                          1. 2

                            Thank You.

                  2. 2

                    When in doubt, just stick to well established alternatives as NomadBSD (for live) and GhostBSD (for installed).

                    1. 1

                      Wow, I had no idea FreeBSD was this fragmented. I guess that explains why OpenBSD has more mindshare nowadays.

                      1. 6

                        Its not fragmentation, its FreeBSD ecosystem.

                        Let me explain, NomadBSD and GhostBSD ARE NOT forks of FreeBSD. They just take FreeBSD RELEASE or STABLE, then they build desktop on top of that and ship it. They benefit from upstream FreeBSD changes when it comes to new drivers, new features and bug fixes. Its pointless for them to maintain separate operating system fork.

                        Not sure how long FuryBSD will live, its quite young and knowing GhostBSD and NomadBSD I do not see any point in creating FuryBSD. I would just join NomadBSD or GhostBSD team instead being in their place.

                        Hope that helps.

                        1. 2

                          I know a number of FreeBSD users, myself included, take their approach with their personal environments.

                          Mine is just vanilla FreeBSD, with a bunch of scripts to install and configure the packages I use regularly. The whole lot lives in Gitlab:


                          1. 3

                            I also use this approach, I described the process here:


                          2. 1

                            Thanks for clarifying.