I tried FreeBSD on ARM64. I couldn't get the browsers, like Firefox or Epiphany, to load without crashing. I'm not sure if it was something I was doing wrong or if the ARM ecosystem just isn't well supported yet. I was also running in a VM with QEMU. On the surface, FreeBSD sounds cool. I liked that I could boot directly to a console and then run the GUI only if I wanted to. Everything felt more modular. It reminded…
> I liked that I could boot directly to a console and then run the GUI only if I wanted to.
You can do that in Linux...
> Only I'm not sure I'd be able to use it as a daily driver. I felt like I'd be spending my time administering the machine and nothing else.
Not really? I think the BSDs are simpler, change less and are better documented.
A coherent userland (not without occasional warts, but without stuff being deliberately, maliciously ignored, broken or replaced to foster someone's agenda). ZFS as a first class citizen, without wondering if Oracle will show up and take the ball away. Jails, although that's not super relevant to the desktop experience. I won't mention systemd, although I truly dislike it (though I have no particular attachment to in…
> ZFS as a first class citizen, without wondering if Oracle will show up and take the ball away. Is this still true now that FreeBSD is using the ZoL/OpenZFS tree?
The FreeBSD installer provides out of the box options to put the root filesystem on an encrypted ZFS partition. The last I looked into doing root-on-encrypted-ZFS on Linux it was a lot more involved.
> ZFS as a first class citizen, without wondering if Oracle will show up and take the ball away. Is this still true now that FreeBSD is using the ZoL/OpenZFS tree?
The FreeBSD installer provides out of the box options to put the root filesystem on an encrypted ZFS partition. The last I looked into doing root-on-encrypted-ZFS on Linux it was a lot more involved.
I guess my point was the Oracle could still show up and take the ball away -- Linux and FreeBSD are using the same ZFS code base now.
A coherent userland (not without occasional warts, but without stuff being deliberately, maliciously ignored, broken or replaced to foster someone's agenda). ZFS as a first class citizen, without wondering if Oracle will show up and take the ball away. Jails, although that's not super relevant to the desktop experience. I won't mention systemd, although I truly dislike it (though I have no particular attachment to in…
> The absence of snap and whatever horrors Canonical keeps pushing is another plus Amen, brother.. Ubuntu 22 was my breaking point.
The absurdity of snap has gone too far.
Even Certbot for Let's Encrypt instructs you to install certbot from a _snap_.
Yes, let me load this additional package manager/software channel on a server install, that will go super well/s.
A coherent userland (not without occasional warts, but without stuff being deliberately, maliciously ignored, broken or replaced to foster someone's agenda). ZFS as a first class citizen, without wondering if Oracle will show up and take the ball away. Jails, although that's not super relevant to the desktop experience. I won't mention systemd, although I truly dislike it (though I have no particular attachment to in…
> ZFS as a first class citizen, without wondering if Oracle will show up and take the ball away. Is this still true now that FreeBSD is using the ZoL/OpenZFS tree?
If I understand correctly, the licensing issue is around mixing GPL software and CDDL software. I don't think that happens in the ZoL tree, but may happen in distributions that ship the kernel and ZoL together.
Using the ZoL tree with FreeBSD doesn't have the same licensing conflict; BSD and CDDL software can mix.
I used Arch for a number of years before switching to a Mac when I went back to school. At some point I may go back to Linux or FreeBSD (I've used both!) but I'll never go back to rolling releases. The whole reason I switched to Mac was that I got tired of things breaking constantly due to the never-ending updates. And if you put things off then you end up getting a whole lot of breakage all at once. No, I would pref…
Similarly I found Arch particularly badly suited for multiboot systems where one might spend extended periods of time not booted into Arch. Too often I'd reboot into Arch and run updates which would break the install somehow.
Fedora has been a decent in-between in my experience. Packages are reasonably up to date and updates are frequent, but I've never had a few weeks of accumulated updates break things which is nice.
> ZFS as a first class citizen, without wondering if Oracle will show up and take the ball away. Is this still true now that FreeBSD is using the ZoL/OpenZFS tree?
If I understand correctly, the licensing issue is around mixing GPL software and CDDL software. I don't think that happens in the ZoL tree, but may happen in distributions that ship the kernel and ZoL together. Using the ZoL tree with FreeBSD doesn't have the same licensing conflict; BSD and CDDL software can mix.
I think ubuntu has a good argument[1] that it can still be shipped as a separate kernel module and satisfy both licenses.
"The CDDL applies to all files under the CDDL, while the GPLv2 applies to derivative works. The CDDL cannot apply to the Linux kernel because zfs.ko is a self-contained file system module — the kernel itself is quite obviously not a derivative work of this new file system."
A coherent userland (not without occasional warts, but without stuff being deliberately, maliciously ignored, broken or replaced to foster someone's agenda). ZFS as a first class citizen, without wondering if Oracle will show up and take the ball away. Jails, although that's not super relevant to the desktop experience. I won't mention systemd, although I truly dislike it (though I have no particular attachment to in…
That seems to be the one advantage separating kernel from user space has provided. At least in my experience, jails may break when the host OS gets updated and the jail isn’t upgraded in lock step. That means having 1+n upgrades for every minor version update. Requiring a docker container to have a user space which matches the kernel kind of defeats the purpose.
This shouldn't normally happen, generally you can run a new kernel with an older userland (the documented upgrade process for the main root is upgrade kernel, reboot, upgrade userland, so at least part of userland needs to still work), and a chroot jail is mostly an independent userland. You may need to ensure the kernel is compiled with backwards compatability if your userland is very far off, and sometimes you see problems with syscall details: 13.0 released with a bug that some ifconfig arguments wouldn't work with a 12.x binary; and I've run into problems with the cpu pinning syscall when the bitmask size increased (this was recently fixed upstream, although I ran into it years ago), etc, so it's not unheard of, but it's fairly rare, in my experience.
I didn’t get much confidence to trust it with my data if something as basic as the system load counter is broken for 10 years and engineers think it’s not worth fixing.
(Note that the bug is closed as fixed, but it’s not fixed and the problem is still there)
Edit: who downvotes this for just linking to a bug in FreeBSD?! :-/