FreeBSD is such an excellent operating system, I applaud all developers and users that have kept it going all these years.
I've been toying around with it in a virtual machine since 13.0-RC2, in many ways it can feel like a foreign system (compared to my Linux background), but there are a lot of nice things that also make it feel "greener" on the FreeBSD side. It's honestly hard to understate the value of boot environments and the boot loader's capability to swap between them or even roll back to a spool checkpoint. It makes almost all upgrades and system changes risk-free.
It has been 15 years since i last used freebsd in a commercial setting. Linux since then. In many ways linux feels alien to me. I still default to “pkg add” in my mind before “apt get”. A shame it didnt gain more traction, as i really loved this OS.
Take a look at https://github.com/zbm-dev/zfsbootmenu/ . Full boot environment support for Linux, along with the ability to create a new environment from a snapshot in your bootloader, live-diff snapshots to see _when_ something changed, and even chroot into a boot environment to fix things.
As someone who’s done the same (although I’m still using FreeBSD on my NAS) I missed decent documentation the most. I felt most at home on Arch because the wiki is pretty decent.
The Arch Wiki is alright if you run Arch, but I definitely prefer well-written and fully up-to-date manpages from the offset. For starters, it doesn't require me to open a web browser first; it also doesn't depend on me having network connectivity at any particular time.
My take is definitely different from GP: I find FreeBSD to have a much better documentation story compared to Linux (even Arch).
No, it's pretty broadly useful; I've used it on at least Ubuntu, Fedora, and centos. It helps that Arch is pretty close to upstream, so docs are usually pretty generic.
I can't disagree about offline docs and the extraordinary quality of BSD manpages, though:)
I've even used the arch wiki when setting up stuff on FreeBSD, because it covers a whole lot of 3rd party software - some of which runs on FreeBSD as well.
I'm sure you understood what I meant, but if you want to be literal, then yes: you can also install packages with pacman while offline, if you have downloaded the packages first.
This command downloads the packages without installing them:
A lot better than other BSDs as well (although I much prefer reading the NetBSD code).
Admittedly, I can’t speak to how it compares to OpenBSD docs as I’ve never really bothered with OpenBSD
DragonflyBSD is cool, but documentation is rough and a lot of it seems to be from old FreeBSD components modified for its speciality. I will say the primary developer is an exceptionally nice person who’s helped me a time or two on the irc.
It has some features that zfs lacks such as a dedup story that is actually usable, plus more flexibility in reshaping. Other than its native raid 5/6 story what major features is it lacking in comparison to zfs? I agree the tooling is trash compared to zfs (zfs command line is a delight by comparison). Also stability wise i haven’t noted problems in years. Not to take anything away from zfs which has proven itself in its particular use cases, but btrfs is alright.
> Also stability wise i haven’t noted problems in years.
Counter anecdote: I have a laptop (single disk) running opensuse tumbleweed with root on btrfs, and it's managed to completely break its root filesystem twice. One of those times I tried to recover it, but in the end I just reinstalled.
Not that I know the exact hardware and circumstances, but in my experience that sounds like a hardware issue, either a buggy controller or a failing disk.
Zfs -with it's similar checksumming and integrity features- would likely have faced similar issues.
It happened months apart and I never saw it report data errors. It could still be hardware, of course (I haven't tried to run ZFS on the same hardware), but even if it was a hardware fault this isn't an impressive failure mode. Like... what are the odds that a random hardware bug breaks BTRFS metadata in such a way that I can't even mount the filesystem, and never just breaks random files such that I get an isolated read error?
Agreed, btrfs has been stable for a long time, aside from RAID5/6, which are going to be uncommon on a laptop or desktop computer. Unfortunately, 10 years ago this was definitely not the case, and btrfs hasnt been able to shake off that reputation among some people since then.
> Other than its native raid 5/6 story what major features is it lacking in comparison to zfs?
For example, native at-rest encryption. dm-crypt/luks is adequate, but has significant performance problems[0] on many-core hardware with highly concurrent storage (NVMe) due to excessive queuing and serialization. You can work around these things by editing /etc/crypttab and maybe sysctls.conf, but the default is pretty broken.
Per-dataset properties, including different compression policies, exec/noexec, setuid/nosetuid, case-sensitivity, volumes, and snapshots that actually make sense.
It does have one huge advantage, you can have a deduped btrfs filesystem without using any extra RAM - and you can run the dedupe process "offline" when the system isn't busy, instead of having it run all the time in real time. For many uses, that is an absolute killer feature.
Ubuntu Desktop has zfs rollback in GRUB for several releases now for root on zfs installs. The only problem is the boot pool will eventually be full after several upgrades :(
Needs to much maintenance imho. Are there distributions that do this better out of the box? I’ve read Manjaro does something similar?
We use openSuSE Leap in production. It's not traditional in the sense of Ubuntu/Debian but somehow the configuration structure is more sane actually. No more /etc/nginx/modules|sites-available and a plethora of symlinks and conf.d directories spread around all over the place for instace.
For what it is worth... you can buy industrial PC/PLC from Beckhoff with FreeBSD installed. PLC= programmable logic controller. Run control system logic on the PLC hard-realtime runtime and run your sophisticated logic and numerical stuff on the FreeBSD OS... soft-realtime communication between FreeBSD and the PLC runtime is pretty straight forward.
https://www.beckhoff.comhttps://www.beckhoff.com/en-us/products/ipc/software-and-too...
Maybe we are arguing semantics here... but read up about the Beckhoff TwinCAT system and how it works. I would say Beckhoff systems are both an IPC and a PLC in one.
Beckhoff system run two OS'es... the PLC runtime is hard real-time and runs at the chipset level (so even if the windows or freeBSD crashes the PLC still runs). You program the PLC using IEC-61131 languages (structured text which sort of between BASIC and Pascal, ladder logic, sequential function chart, cyclical function chart, etc.) and also have the option to run C/C++ code (with no dynamic memory allocation).
For what it is worth, newer Omron PLC's run PLC code on top of QNX, B&R automation uses a very similar approach to Beckhoff.
Overall, the B&R and Beckhoff PLC's are, I think, under-appreciated.
The Embedded Windows version didn't have that web console. Also, ZFS copy-on-write snapshots could be quite useful for quick backup/restorement when working on-site.
I hope that ARM[1] can become a real challenger to the x86-dominated server/desktop/laptop space, maybe even give us a bit of that vibrant environment of multiple competing platforms that existed in the 80s and 90s.
Perhaps it's just my nostalgia speaking, but I always found it neat how there were x86 daughterboards for Macs and Amigas, and various other similar setups. A full Ryzen APU-powered PC with good graphics performance can easily fit on a PCIe card, which could slot neatly into a hypothetical ARM-powered PC, with access to the mainboard's resources.
Use the ARM main PC for desktop and other less intensive tasks, and fire up the full-fat x86 daughterboard for gaming and number-crunching.
Or maybe it would be a lot more elegant to just have good power management on an already powerful ARM CPU and GPU and handle what x86 stuff you need via emulation, but full-computer daughterboards are just so neat!
Since Linux became unstable on one oft my Intel Laptops (only this one system) (crashes, multi monitor problems,...) I wanted to try FreeBSD in it (Linux compatibility, zfs, ...) but the recent wireguard nearly merge and the following reaction [0] made me pause in actually trying it.
I hope the developer and merge polcies aren't as headless as they seem.
My Thinkpad E15 Gen 2 with AMD Ryzen 4500U (Radeon Renoir Graphics) hangs on boot when I enable the amdgpu driver and disable syscon (framebuffer). Hardware support is one of the big things that holds FreeBSD back.
Renoir is a bit too new for us since the official drm version is 5.4, you currently have to build the 5.5-wip branch of drm-kmod for it to work.
Also, I've fixed the framebuffer thing, you no longer have to disable it!!
(Not everybody even had to ever do it. The issue was that we did not disable our simple framebuffer when the driver expected it (our Linux compat layer would only try to kill other Linux framebuffers) so our framebuffer would literally just overwrite device memory that the driver was using to initialize all the GPU firmware. On my Vega card, this would only happen at 1440p/4K. With smaller EFI framebuffer resolution, the memory would luckily not overlap :D)
Thanks for the response, it's great to have developers respond to the community. I have made another attempt today using 5.5-wip and experimental hardware support enabled through loader.conf, to no avail. I think I will wait some time for things to become more mature. Right now I have a Macbook M1 machine so I can cope by saying I have BSD under the hood :)
It's anything but the largest projects really. Even mainstream linux support for a lot of laptops is still iffy. Too much work for too few people and fewer willing to pay to make it happen.
It will be interesting to see if further ARM penetration into what was historically Windows-or-Mac only portions of the laptop market helps with that.
It might not be that bad; there's a BLT api in the boot services that you could use as a UEFI application, but OSes can't use after calling ExitBootServices. UEFI has a network api too (which I've seen people disparage, but might be usable enough).
I have other crazy ideas though, so I won't steal yours. :)
Just got this up and running. No issues so far except wireguard keepalive is broken for me for some reason. Very exciting to see Linux and FreeBSD pulling ZFS from the same upstream - I needed this to properly deal with encryption etc.
I've been toying around with it in a virtual machine since 13.0-RC2, in many ways it can feel like a foreign system (compared to my Linux background), but there are a lot of nice things that also make it feel "greener" on the FreeBSD side. It's honestly hard to understate the value of boot environments and the boot loader's capability to swap between them or even roll back to a spool checkpoint. It makes almost all upgrades and system changes risk-free.