2024: The year of desktop FreeBSD?

Yeah, I went there with the title, but don't worry, the reference is both deliberate and self-aware.

I'm actually about to write an article about this very subject to a Finnish computer culture magazine, from the viewpoint of a newbie-ish, enthusiast, non-sysadmin, desktop user. When I got my new used laptop, I wanted too test it out as a lark, thinking that my double-boot to Linux would be my daily driver and FreeBSD would be a testing playground.

However, the opposite happened. Linux has faded into the tail end of my bootloader and I daily drive FreeBSD 14 with i3wm for all my general computing needs. I've found the experience extremely smooth and the performance snappy. And FreeBSD uses way fewer resources as well. I am naturally lucky in that all the requisite drivers came with the kernel so everything on the laptop worked out of the box.

Despite this, I've noticed that a lot of folks don't bother with FreeBSD as a general desktop OS. I would be very interested in hearing of your reasons why people do or don't daily drive FreeBSD. This question is both out of general curiosity and as background for the article. Are you double booting with something else, for example?

Full disclosure, I still do run Linux on my desktop since I do a bit of gaming and I do media production as my line of work, so the added hardware support comes in clutch.
Yeah, I went there with the title, but don't worry, the reference is both deliberate and self-aware.

I'm actually about to write an article about this very subject to a Finnish computer culture magazine, from the viewpoint of a newbie-ish, enthusiast, non-sysadmin, desktop user. When I got my new used laptop, I wanted too test it out as a lark, thinking that my double-boot to Linux would be my daily driver and FreeBSD would be a testing playground.

However, the opposite happened. Linux has faded into the tail end of my bootloader and I daily drive FreeBSD 14 with i3wm for all my general computing needs. I've found the experience extremely smooth and the performance snappy. And FreeBSD uses way fewer resources as well. I am naturally lucky in that all the requisite drivers came with the kernel so everything on the laptop worked out of the box.

Despite this, I've noticed that a lot of folks don't bother with FreeBSD as a general desktop OS. I would be very interested in hearing of your reasons why people do or don't daily drive FreeBSD. This question is both out of general curiosity and as background for the article. Are you double booting with something else, for example?

Full disclosure, I still do run Linux on my desktop since I do a bit of gaming and I do media production as my line of work, so the added hardware support comes in clutch.

Unix systems were originally, and still are, primarily designed for multi-user network environments. A graphical interface was not a top priority. Ultimately, it's all about the code. One could certainly experiment with porting desktop environments (DEs) like Xfce onto real-time operating systems (RTOSs) and consider it done, but that's not the ideal approach. A general-purpose consumer-focused operating system should have a kernel and system structure specifically tailored for general computing and workstation-like use cases from the outset. BSD and Linux distributions are specialized operating systems, not primarily designed for desktop use, although they can be configured to function as such
 
Unix systems were originally, and still are, primarily designed for multi-user network environments. A graphical interface was not a top priority. Ultimately, it's all about the code. One could certainly experiment with porting desktop environments (DEs) like Xfce onto real-time operating systems (RTOSs) and consider it done, but that's not the ideal approach. A general-purpose consumer-focused operating system should have a kernel and system structure specifically tailored for general computing and workstation-like use cases from the outset. BSD and Linux distributions are specialized operating systems, not primarily designed for desktop use, although they can be configured to function as such
"Windows are for desktops and unixies are for servers. People who use windows in servers are idiots, and people who use unixies in desktops are geeks."
IDK who sad it, but I like it.
 
"Windows are for desktops and unixies are for servers. People who use windows in servers are idiots, and people who use unixies in desktops are geeks."
IDK who sad it, but I like it.
It seems there are a lot of geeks in these forums, myself included. While it's true that Windows dominates on the desktop and Unix-like systems mostly on servers today, it's worth remembering that Unix-based workstations were once famous. Just to name few, workstations from Sun Microsystems, Silicon Graphics, and others were powerhouses in their time. And, of course, macOS is built on NeXTSTEP, which in turn was based on the BSD. Unix has a rich history, not just in servers, but in professional workstations too.
 
"Windows are for desktops and unixies are for servers. People who use windows in servers are idiots, and people who use unixies in desktops are geeks."
IDK who sad it, but I like it.
We have both Linux and Windows servers in our company, I lost control of how many of them but I would say a few thousands of each. Both serve their purpose and I don't think my windows colleagues are idiots because they run 2019 or 2022 on their HV hosts and VMs.

Moreover, there are many specialized software applications there run only on Windows server.

With that said, I'm happy that I don't have to manage them, I am a Unix guy and I hope to never change.

I guess I'm also a Geek as my personal machines in the past few years ran under Solaris, Linux and now FreeBSD.
 
Rather the opposite, they are general purpose operating systems, which you can use in a myriad of different contexts. An OS meant for desktop computing only would be a specialised one.
That's a fair point but damn FreeBSD needs to work on device drivers urgently, specially with WiFi and Bluetooth and also on Linuxemulator too. Linux distributions are breaking compatibility with linuxemulator bit by bit here and there. Something like

linuxemulator create archlinux -i archiso.iso -native -h vmdrive.img -tty1 && chroot - would be awesome.
 
That's a fair point but damn FreeBSD needs to work on device drivers urgently, specially with WiFi and Bluetooth and also on Linuxemulator too. Linux distributions are breaking compatibility with linuxemulator bit by bit here and there. Something like

linuxemulator create archlinux -i archiso.iso -native -h vmdrive.img -tty1 && chroot - would be awesome.

Ubuntu just needs to stop doing crazy things.
 
Ubuntu just needs to stop doing crazy things.
So does Red Hat, Mageia, and everybody else - everybody just goes off and does their own thing because hey, it's Open Source, what's there to stop me from rolling my own stuff instead of being standards-compliant and predictable enough to be useful? ?
 
It seems there are a lot of geeks in these forums, myself included. While it's true that Windows dominates on the desktop and Unix-like systems mostly on servers today, it's worth remembering that Unix-based workstations were once famous. Just to name few, workstations from Sun Microsystems, Silicon Graphics, and others were powerhouses in their time. And, of course, macOS is built on NeXTSTEP, which in turn was based on the BSD. Unix has a rich history, not just in servers, but in professional workstations too.
Never used any real server for FreeBSD. What's the differencce?
I personally don't need to have any graphical screen as system built-in, but a community-driven universal hardware detection/configuation script for common PC's to reduce system-wide configuration time would be an improvement. A good start might be to not rely on rc.d since it's anti-transparent. It has to show every executed CLI command and retain the results to determine the situation in detail, including not-running/processing/fault/ready status.
 
Never used any real server for FreeBSD. What's the differencce?
I personally don't need to have any graphical screen as system built-in, but a community-driven universal hardware detection/configuation script for common PC's to reduce system-wide configuration time would be an improvement. A good start might be to not rely on rc.d since it's anti-transparent. It has to show every executed CLI command and retain the results to determine the situation in detail, including not-running/processing/fault/ready status.

This ^

I think GhostBSD and NomadBSD project is doing something similar. But issues always comes from lack of driver support of Laptops and various other peripherals like M Audio sound cards, various consumer grade headphones, multi channel audio routing for studio recording setup and latency reduction generic driver such as ASIO4ALL etc
 
Ubuntu just made Linux usable for normies. The most of the "Linux only" modifications come from Red Hat

They made progress for normies, but they also go crazy with systemd dependencies, starting from their recent reliance on Snaps. We had a user here on the forum run into systemd related errors when trying to run Ubuntu in a chroot after debootstrap.

I prefer Mint, which keeps Ubuntu's normie support but takes back some of the crazyness.
 
They made progress for normies, but they also go crazy with systemd dependencies, starting from their recent reliance on Snaps. We had a user here on the forum run into systemd related errors when trying to run Ubuntu in a chroot after debootstrap.

I prefer Mint, which keeps Ubuntu's normie support but takes back some of the crazyness.

FreeBSD should consider using Void Linux or Alpine Linux for Linuxulator instead of Debian and Ubuntu. Mainstream Linux distributions like Ubuntu have embraced systemd for good reasons, especially given their focus on enterprise solutions, where systemd's capabilities align with their goals. Unlike sysvinit, which has its drawbacks, BSD's init system, particularly mewburn rc, provides a more straightforward and reliable framework for managing services. Most people think Slackware is Unix like Umm, nope. It's nothing close to NetBSD level Unix. I can use FreeBSD easily, OpenBSD easily, Slackware? Nope. It doesn't have the cohesion nature of BSDs, doesn't have ZFS like snapshot and rollback capabilities out of the box, doesn't have /usr/local, doesn't have sysrc, doesn't have ports or pkg, doesn't have dtrace, pf.. alot missing

Linux distributions face significant fragmentation, making software distribution complex. Snaps and Flatpaks emerged to unify the ecosystem,. FreeBSD and other BSDs don't share this fragmentation problem, thanks to the unified Ports system, so there's no need for snaps or Flatpaks. FreeBSD now requires more port maintainers and device driver contributors as its user base grows, especially on desktops and laptops. FreeBSD is no longer as niche or obscure as it once was with its increased adoption after systemd adoption in Linux.

Personally I disliked systemd for "startjobs". Systemd doesn't like hotplugged USB tethering devices managed via dhcpcd. It runs systemd startjobs for 90sec or so during each boot and that sucked ass. I created a bug report back in 2016 and systemd developers said that it's not a bug, but a feature. Yeah, feature! I could able to change it to 0sec but then kernel panicked. That day was my last day with Linux on laptop. I now use Debian Stable in FreeBSD and daily drive it
 
FreeBSD and other BSDs don't share this fragmentation problem, thanks to the unified Ports system
Now this is inaccurate. The 3 major BSD's (FreeBSD, OpenBSD and NetBSD) the do have ports, true, but the master trees/repos are still separate. There's a good wikipedia page that explains the differences: https://en.m.wikipedia.org/wiki/Ports_collection (Yeah, it's a few years old, but I don't think the overall situation changed that much since then).
 
latency reduction generic driver such as ASIO4ALL
This is called JACK on FreeBSD and works very well.

FreeBSD should consider using Void Linux or Alpine Linux for Linuxulator instead of Debian and Ubuntu.
Alpine Linux would be a bad idea. You want a compatibility layer to be able to run the most possible software, meanwhile Alpine uses musl instead of glibc, which means all pre-compiled Linux software won't run on it because it is build for glibc systems. Void doesn't have this issue (available in both glibc and musl variants) but then it is a rolling release, which is not ideal in this context.
 
It seems there are a lot of geeks in these forums, myself included. While it's true that Windows dominates on the desktop and Unix-like systems mostly on servers today, it's worth remembering that Unix-based workstations were once famous. Just to name few, workstations from Sun Microsystems, Silicon Graphics, and others were powerhouses in their time. And, of course, macOS is built on NeXTSTEP, which in turn was based on the BSD. Unix has a rich history, not just in servers, but in professional workstations too.
Never got console time on a SiliG machine, but I remember getting on the Web using a Sun pizza box connected to to a T-1 line in the mid '90s. I felt the power crackling through my fingers.
 
Never got console time on a SiliG machine, but I remember getting on the Web using a Sun pizza box connected to to a T-1 line in the mid '90s. I felt the power crackling through my fingers.
I had SiliconGraphics Indigo 2 of my own :). Second hand machine. When the hard drive broke, I donated this to the local computer museum (without keyboard). Just now, typing this reply on the original SiliconGraphics keyboard - very good keyboard with excellent touch and feel, connected to this FreeBSD machine. The keyboard is still working perfectly. Want to connect to my next FreeBSD box, but need to buy a PS2 - USB adapter first.
IMG_SG.jpg


... and I peeked into Ebay - working machine is still pretty expensive - approximately US $1,500.
 
Now this is inaccurate. The 3 major BSD's (FreeBSD, OpenBSD and NetBSD) the do have ports, true, but the master trees/repos are still separate. There's a good wikipedia page that explains the differences: https://en.m.wikipedia.org/wiki/Ports_collection (Yeah, it's a few years old, but I don't think the overall situation changed that much since then).

I believe there was a misunderstanding. I meant that FreeBSD has a distinct abstraction layer, /usr/local, specifically for package management. HaikuOS also employs a similar approach. This means that software developers can distribute their applications to FreeBSD without needing to worry about the complexities of five different package management systems.

This simplifies the process for FreeBSD, but distributing to other BSDs or non BSDs like OpenBSD, NetBSD, Windows, RedoxOS and HaikuOS would require additional considerations due to their unique packaging systems. But this is a separate issue from the fragmentation within same ecosystem that arises within the Linux distributions. There's three different sed, grep and ls implementation in mainstream Linux distributions and that's just starting point of fragmentation.
 
I believe there was a misunderstanding. I meant that FreeBSD has a distinct abstraction layer, /usr/local, specifically for package management. HaikuOS also employs a similar approach. This means that software developers can distribute their applications to FreeBSD without needing to worry about the complexities of five different package management systems.

This simplifies the process for FreeBSD, but distributing to other BSDs or non BSDs like OpenBSD, NetBSD, Windows, RedoxOS and HaikuOS would require additional considerations due to their unique packaging systems. But this is a separate issue from the fragmentation within same ecosystem that arises within the Linux distributions. There's three different sed, grep and ls implementation in mainstream Linux distributions and that's just starting point of fragmentation.
The BSD's have their separate implementations of sed/grep/ls, as well.

KDE is developed on Linux, but runs on FreeBSD (and just about any Linux distro) virtually unmodified. Compiling the source code, however, is highly dependent on the project, be it a BSD or a Linux distro. Packages compiled for FreeBSD won't run on OpenBSD, even though they were compiled from the same source code.

Fragmentation in Linux starts when there's 5 different filesystems, filepaths are not standardized, and package versions (plus compilation policies) differ.
 
fr0xk : BTW, according to https://repology.org/repository/openbsd, there's only just under 12,000 ports in OpenBSD repo, and about a third of those are outdated due to lack of maintenance.

Maintaining a packaging infrastructure is generally responsibility of the project, but piggybacking on somebody else's successful implementation of packaging is not unheard of - Ubuntu piggybacked on Debian's repos for awhile, Manjaro piggybacked off AUR repos... even the original RPM repos piggybacked off RedHat's stuff back in the day.

Snaps and Flatpaks are an attempt at standardizing the packaging format and infrastructure. And, FreeBSD's Ports have been an inspiration for Gentoo's Portage (even Gentoo says as much).

Upstream projects like like KDE/GNOME/LibreOffice/GCC don't bother making OS-specific packages for other OSes. If a distro (or a BSD) user wants to maintain a package for their favorite OS, it's on that user to patch the code, make sure it compiles, package it appropriately, and submit to the package repo. Very different from, say, Photoshop. In case of Photoshop, porting to Windows or Mac is done by Adobe, not MS or Apple.
 
fr0xk : BTW, according to https://repology.org/repository/openbsd, there's only just under 12,000 ports in OpenBSD repo, and about a third of those are outdated due to lack of maintenance.

Maintaining a packaging infrastructure is generally responsibility of the project, but piggybacking on somebody else's successful implementation of packaging is not unheard of - Ubuntu piggybacked on Debian's repos for awhile, Manjaro piggybacked off AUR repos... even the original RPM repos piggybacked off RedHat's stuff back in the day.

Snaps and Flatpaks are an attempt at standardizing the packaging format and infrastructure. And, FreeBSD's Ports have been an inspiration for Gentoo's Portage (even Gentoo says as much).

Upstream projects like like KDE/GNOME/LibreOffice/GCC don't bother making OS-specific packages for other OSes. If a distro (or a BSD) user wants to maintain a package for their favorite OS, it's on that user to patch the code, make sure it compiles, package it appropriately, and submit to the package repo. Very different from, say, Photoshop. In case of Photoshop, porting to Windows or Mac is done by Adobe, not MS or Apple.
I think OpenBSD has a better selection of games in the repo though. I really like that they have UrbanTerror43 and a few others that I still haven't tried. I tried building UrbanTerror43 on FreeBSD 14.0 but it fails now. :(
 
The BSD's have their separate implementations of sed/grep/ls, as well.
FreeBSD, OpenBSD, and NetBSD, have diverse implementations due to their distinct design philosophies and development goals. Their codebases sharing a common ancestry, have evolved independently with variations in features, performance, and security.
Linux distributions share a core kernel but exhibit fragmentation in user-space components. This fragmentation arise from differing package management systems (e.g., RPM, DEB), system libraries (e.g., glibc, musl), and system services (e.g., systemd, init). FreeBSD and HaikuOS, both Unix-like too, and have distinct origins and development trajectories but that's not what fragmentation means
 
fr0xk : BTW, according to https://repology.org/repository/openbsd, there's only just under 12,000 ports in OpenBSD repo, and about a third of those are outdated due to lack of maintenance.

Maintaining a packaging infrastructure is generally responsibility of the project, but piggybacking on somebody else's successful implementation of packaging is not unheard of - Ubuntu piggybacked on Debian's repos for awhile, Manjaro piggybacked off AUR repos... even the original RPM repos piggybacked off RedHat's stuff back in the day.

Snaps and Flatpaks are an attempt at standardizing the packaging format and infrastructure. And, FreeBSD's Ports have been an inspiration for Gentoo's Portage (even Gentoo says as much).

Upstream projects like like KDE/GNOME/LibreOffice/GCC don't bother making OS-specific packages for other OSes. If a distro (or a BSD) user wants to maintain a package for their favorite OS, it's on that user to patch the code, make sure it compiles, package it appropriately, and submit to the package repo. Very different from, say, Photoshop. In case of Photoshop, porting to Windows or Mac is done by Adobe, not MS or Apple.
Nope. Linux needs Flatpak, Snap, and Nix to combat its userland fragmentation. A lot of Linux distributions are used by casual desktop users (intermediate skills, who do more than listening to music and browsing the web, know a bit about few command line tools like adding or removing packages, but not to the level of Unix-bearded sed -i bunch of /([^.*]\ #// ) piped to other ${var@} piped to grep then piped to another tool with 7 parameters like -uAdgcrs) level too. These users never have to go down the rabbit hole of the command line to do advanced tasks like setting a static address, installing drivers, remote desktop, setting up VMs, running the latest version of GNOME/KDE, and playing the Call of Duty edition that just released 2 hours ago. These tools offer a unified way to package and run software across distributions, cutting through the chaos. BSDs don't need this because they control their entire stack and explicitly target server users (according to the handbook), unlike Linux distributions. Without them, Linux remains a fragmented mess for distributing software.

I also don't see anything bad about being able to run corporate software on open-source operating systems. I'm not a free software extremist by any means, but pragmatic.
 
Traditionally, in open-source, users handle packaging for their operating system, unlike commercial software where the company does it. Now with flatpak or snaps, both Linux users and companies can package based on the same package manager. Stable distributions can run these package managers on top of a package manager that handles and upgrades core system components separately. The core system components like the kernel, init, loaders, network stacks, and tools are responsible for being maintained by distro maintainers, and other desktop packages can be shipped via container formats such as flatpak or snap. That way, even more open-source developers will not have to deal with the fragmentation of different file systems, or other missing/incompatible components or libraries of Linux.

Personally, I propose that Linux distributions need these tools (systemd, flatpak, snaps and nix package managers ) in order to unify their massive fragmentation (even if we discount all derivative distributions and only consider parent distributions). What I don't like is enforcement of these tools

BSDs can't have this because neither it's necessary nor its possible to have a universal binary package manager for all Unix like systems unless we can translate every syscalls into native os syscalls dynamically. Running a containerised applications still needs a common kernel. BSDs being different is not equivalent to Linux distributions being different. Linux distributions still runs on definitive Linux kernel, even a highly patched Linux kernel would have very much similarities between them. The fragmentation is in userland
 
Back
Top