The FreeBSD Foundation is pleased to announce that it has completed work to build FreeBSD without requiring root privilege. We have implemented support for all source release builds to use no-root infrastructure, eliminating the need for root privileges across the FreeBSD release pipeline. This work was completed as part of the program commissioned by the Sovereign Tech Agency.
↫ FreeBSD Foundation blog
This is great news in and of itself, but there’s more: FreeBSD has also improved build reproducability. This means that given the same source input, you should end up with the same binary output, which is an important part of building a verifiable chain of trust. These two improvements combined further add to making FreeBSD a trustworthy, secure option – something it already is anyway.
In case you haven’t noticed, the FreeBSD project and its countless contributors are making a ton of tangible progress lately on a wide variety of topics, from improving desktop use, to solidifying Wi-Fi support, to improving the chain of trust. I think the time is quite right for FreeBSD to make some inroads in the desktop UNIX-y space, especially for people to whom desktop Linux has strayed too far from the traditional UNIX philosphy (whatever that means).
I think their main selling point still is the BSD license.
PlayStation (4 and 5 at least, maybe even 3), Nintendo Switch, Juniper, NetApp, pfSense (and now OPNSense), FreeNAS and many other appliances prefer BSD because they can customize or even fork to their hearts’ content, without needing to worry about major distribution or LKML politics.
No need to convince Linus or any other person to have their code in the kernel. (Their kernel which they can keep to themselves).
The “one true source” is of course another great benefit, and I am surprised they were not reproducible in the past. (Another step in being an alternative to CoreOS)
(Those who would say “jails”, “cgroups” have been battle proven long ago. Even before “docker” was a thing, Google’s entire fleet used cgroups for containerized Linux at planet scale)
Sadly they still don’t have a graphical installer. And for some reason I can’t seem to install FreeBSD on my Dell and HP desktops with NVidia video cards.
It’s possible but GPU support can be … finicky.
My Dell T7400 has both an NVidia card and an ATI card, all running under FreeBSD.
Yeah, it’s quite an old setup — credit to Dell hardware — and it ran for 2 solid years over lockdown without having to be rebooted.
Visit “https://wiki.freebsd.org/Graphics”
Or…
You can go the other opposite, and install everything over a serial console.
(USB->Serial if a physical port does not exist)
I know it is not ideal to say “in order to try this OS, you need another working machine”.
Yes.
Virtual serial consoles are what we use to install FreeBSD on our server VMs.
“Linux has strayed too far from the traditional UNIX philosphy (whatever that means)”
That means do one thing and do it well. Which anyone who has been around these things for any amount of time knows. The current GNU/Linux approach is to subvert this by bundling everything and the kitchen sink into basic tools. Like the abomination that systemd is, an init system that extends its tentacles into every GD thing under the sun. With no end in sight for its “feature” creep continuing into even more areas. Forcing its implementation into every area of the system soon it will be impossible to boot without that trash involved if they have their way. And more than a few distributions are part of the problem going out of their way to ensure this happens.
RedGreen925,
You are right, I agree this is what’s happening. Linux is leaving behind simple tools that do simple things in favor of more monolithic designs, it’s becoming more windows-like. For example not having text logs and needing a program to read them.
Yeah, system developers have been under pressure to conform with systemd dependencies as alternatives get pushed out.
Alfman,
I would say Windows is becoming more Unix like with powershell preferring simple commands over combined ones, and having vms and containers almost as first class citizens.
Even new Microsoft tools like vscode are multi-platform, and are more generic than what ubuntu or systemd bring to the plate.
For me, personally, the worst change from “do one thing and do it well” to monolithic programs was the migration from ifconfig, arp, netstat, route, and similar utilities to the horrid ip monstrosity.
How anyone can think “ip neigh show dev vlan1” is better than “arp -an|grep vlan1” is beyond me. I have to read the man page every time I want to do any network configuration on Linux servers. Sure, “ip” is less to type than “ifconfig” , but you need to type a lot more after “ip” to get any useful information out. And the output of “ip addr” is just nasty compared to “ifconfig”.
ifconfig on FreeBSD is more monolithic than ifconfig on Linux as it handles all interface configuration (vlan, bridge, tap, epair, carp, etc), but the syntax and commands make sense and the output is very readable. And there’s still netstat, route, arp, and the like as separate utils that do one thing only.
phoenix,
Having monolithic tools is an extension of DBUS being the de factor “user space API” for Linux desktop.
Higher levels tools, both from GUIs like GNOME, or remote management like aws / docker pushed things away from “the UNIX way”.
Now, not only these simpler programs are no longer the primary way people change things, many of them are broken, lacking functionality, or outright removed from newer distributions.
Some of this cannot be easily avoided, though. A modern Linux desktop will have Wifi and Ethernet and switch between different ones during the day. It will go to standby, and then have to resume an entire user session. It will switch between printers and other devices based on current location. And finally it would have to do this while competing with Windows for performance.
Can this be solved “the UNIX way”?
Yes of course
But it won’t be as “sexy”, and it will take longer. The younger generation of hackers just do not have the same patience.
That’s only one part of it. The Unix philosophy is often summarized as three rules: “Write programs that do one thing and do it well, that work together, and that handle text streams because that is a universal interface”.
systemd fails in all three. As you mentioned, it doesn’t do one thing (and does it even do its things well?). Work together? systemd wants you to use systemd’s tools. Text streams? Nope, binary logs.