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 me of the days before Windows 95 when I could just use DOS to save precious memory and CPU bandwidth.
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. Maybe it was just because it was running in a VM. Maybe it was because it's ARM. Not sure. I'd love to hear others experiences with FreeBSD on ARM.
I think I _may_ have done that before. What I thought was interesting is FreeBSD just did that without any extra steps. When I "apt-get install" a desktop environment in Ubuntu or Debian and reboot, the desktop environment loads by default. In FreeBSD, I guess there's some startup scripts I would need to edit to start X and the desktop manager...
> I think the BSDs are simpler, change less and are better documented
> Source: I ran OpenBSD on desktops in early 2000s.
From my experience witb BSDs on a SUN pizza box (also around 2000) : FreeBSD had the docs on the internet, not very helpful when you want to configure the network. OpenBSD was ok. Linux (my first choice) was slow as hell.
Exactly. I was on an M1 Mac, so trying to emulate x86/64 would have been painfully, unusably slow.
For simple console stuff on the terminal, it's ok. But when the GUI is involved, or anything with a lot of computation, having to translate all of the instructions from native ARM64 back to x86/64 and back takes a ton of resources and time.
I had the opposite experience with dwm. I don't like cycling through overlapping windows on the same "desktop", and I don't like taking the time to place windows correctly. With 2 screens, I have 18 "desktops", which is more than enough, and the automatic tiling is exactly what I want. On the other hand when I use GNOME/KDE/Windows I'm always losing lots of time navigating. Also I must have some kind of curse because even with high-end computers I've never had one of those run really smoothly. My current work laptop is on KDE, and when I use a shortcut to open a terminal it takes 200/300ms.
I think it also helps that I've never really tinkered with it. I took someone's build that had a few things I wanted, and I think that's it. In contrast, I spend more time on a regular desktop environment setting up shortcuts.
This, but cwm for floating instead of tiling, almost the same philosophy. Set keybindings, fire, forget. I use Wmaker because that was my first WM and I like it, but CWM it's my "failsafe" wm
when things break.
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 init scripts, I was quite fond of Solaris' SMF for example).
The absence of snap and whatever horrors Canonical keeps pushing is another plus, but I'm in not in a good position to judge its impact as I'm blissfully ignorant of how bad they are, I just stumble in the occasional horror story.
Biggest thing I'm missing and wish I had: Docker. Jails may be technically better, but the world went another way and they have no functional ecosystem.
For me, jails aren’t only technically better, but also have better ergonomics. With Docker:
- I always end up running out of disk space, because of Docker’s love of immutable layers for everything — my jails just live in a normal directory in the filesystem, no need to overthink it;
- I have no idea how to restrict /dev in Docker containers — I’m sure you can, but it’s a mystery to me;
- copying/moving files between host and container requires setting up volumes/ssh/whatever special ceremony; copying/moving files to/from jails is trivial, it’s the same as copying/moving files between any other directories;
- updating jails is easy; I use pkg and freebsd-update, just like with a normal system update, no need to update the host system one way, and the jails another way, like with Docker;
- jails don’t mess with my firewall rules, unlike Docker.
Overall, jails give me a much more cohesive experience.
I agree wholeheartedly. I like jails a lot (and jails+ZFS even more) and I'm not a fan of Docker at all. But the entire planet adopted it and isn't even aware jails exist.
You won't find a premade pihole jail, a downloadable HomeAssistant jail, etc. That's what I mean with ecosystem. Being the better solution is surprisingly unimportant when nobody knows you exist.
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."
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.
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 don't run it right now (and won't anytime soon) as a desktop. Once I switched to using laptops exclusively, the driver story became too bad to work comfortably. But, I used FreeBSD on a desktop for 5 years, from 2005 to 2010.
I really enjoyed using it. The reasons for that are what others already mentioned: simplicity, well-thought-out organization of the system vs. userland vs. 3rd party packages (man hier), excellent documentation always available locally, ports, jails, pf, etc. It was all nice, but the killer feature, for me, was stability. The system simply refused to die, no matter what I threw at it or how I misconfigured it. At the time, Linux was a lot less stable than it is today - it could hang forever, corrupt the filesystem, or restart in the middle of doing something. Especially with proprietary, binary blobs and apps, rare as they were, Linux had a hard time accumulating uptime. On the other hand, FreeBSD worked, always. Well, it had no other choice, given that ACPI wasn't fully implemented and it couldn't suspend/sleep - it was a desktop but also a server for some private stuff, so that was ok.
Linux got much better over the years, both in kernel and userland. I have been using Fedora for close to 15 years now, and it works. I won't be going back to FreeBSD on the desktop, unfortunately. However, I'm tempted to try it again on an older laptop that plays the role of a NAS: no GUI, always connected to the router with a cable, always connected to power. I have Fedora running there, but I already use ZFS - it's great - so the switch shouldn't be hard.
Same, I used to run it a lot, but I went back to it recently and have not really managed to make it work. I'm using sway, and I have hit a whole bunch of issues:
* Have to use 14-CURRENT to support my RDNA2 graphics card at all. This was not simple.
* Systemd sucks, but on Linux when I start a sway session it co-ordinates all the xdg-desktop-portal-wlr / pipewire / pipewire-media-session (I think). There doesn't seem to be a freebsd equivalent for user level services. Although dbus / consolekit seems to be doing something, I don't understand why or how.
* Sound is just broken. My usb headset gives constant loud feedback, by bluetooth dongle spams the dmesg until it eventually gives up and my hda card seems to work in all the mixers but no sound is forthcoming.
* Firefox with wayland on just loses the compositor connection almost instantly. Alacratty seems fine though, as is xwayland.
* My webcam doesn't work, in firefox it's blank, in chrome the video is corrupted.
* I have no idea how to configure XDG_RUNTIME_DIR to get created a login with the right permissions etc on tmpfs. I could leave it on zfs of course but apparently that's problematic.
Its simple and logical with lots of useful features that most people do not even know exist.
Also in may aspects it makes my life easier - like with ZFS Boot Environments or Rescue subsystem - Ports and Source infrastructure for custom system/packages building.
It is like linux if Canonical never happened, so like linux 20 years ago. The ports system is nice. FreeBSD is my fallback in case Patrick gives in to the changing linux world and I have to abandon Slackware or start learning OS stuff again. Biggest thing to know about it as a desktop, drivers get into the kernel much slower than with linux and some never get in, so like linux was 20 years ago.
OMG - this is so true. Home sweet home. A few additional points:
- The hard separation between the base OS and user-installed packages that go in /usr/local - you can wipe the /usr/local and get back to the pristine state. Things don't get mixed.
- Better documentation, better man pages.
Whenever I log in to a Linux distro it feels like things are all in the wrong places. Hardware support is bad though, I wish hardware vendors would open source their drivers.
Been using the webcam with my FreeBSD desktop for job interviews over the past couple of months. Unfortunately Zoom eats up a ton of CPU and then crashes when I open it in a browser tab, and there isn't a packaged binary that I've given a try yet. On Google Meet the browser also doesn't support blurring out the background. So, while it's not totally broken or anything, I don't rely on it for important video meetings.
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 prefer taking things slow and getting tested releases way less often. I have no need to be on the bleeding edge of everything.
In my experience doing the frequent small upgrade steps is better. It's valuable to know what the update actually does because the list of changes is so small. At the same time it's possible that small updates degrade the system stability so slowly that it's difficult to notice at first.
Right now I'm running Fedora on my old laptop and I was positively surprised in how many details it got better in terms of user-friendliness and predictable behaviour in general, I hope it'll break the curse of "stable" distros constantly falling apart on my PCs.
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.
I do this with Ubuntu. Snap is annoying yes. And I don’t like some of the changes, at least how they are implementing them (ie: systemd, netplan) during upgrades etc. but it’s serviceable.
I only use windows to play games. But frankly, my personal laptop is used mostly for that, if at all. I have a work laptop provided to me for work stuff.
I still tend to use Ubuntu for the occasional freelance, research or teaching work I do though.
I’m not an evangelist on OS. I’ve used centos, fedora, Debian, mint, elementaryos and even for a time was swapping out DEs for window manager things like awesomeWM.
But at this stage in the game I’m too lazy to tinker with making the OS work. And Ubuntu tends to do well with mixed hardware such as having iris xe and nvidia chips on a single board. So I went with that.
The only sane Linux setup for a workstation is an immutable distro like Silverblue/Kinoite, and an Arch Linux toolbox (or any distro you prefer).
I will die on this hill, and whoever disagrees has never tried what honestly feels like the future. My Linux PC is as stable and reproducible as my iPhone.
One day I will finish my Fedora Silverblue master guide that has been a draft for months...
I can't figure out a decent workflow for Kinoite. It's probably a little bit too much work for me to change my habits right here right now. But I agree that this is a great setup and ultimately, what I want to aim to. Complete separation of user and OS, containerized apps everywhere, and so forth. But my quick trial of a few hours was too short to adapt. Also I love excel too much unfortunately.
NixOS is "better" in the sense that you can get pretty close to something like Silverblue with it if you tinker around.
But I agree with you that for the average user Silverblue surely is the the better platform, NixOS is for people how like to hack around and customize their environment.
The changes have largely been the two of them warring for control of key projects, such that other distros are forced to fall in line and become second-class to theirs (why risk the knock-off when you can go straight to the source?). Red Hat's won every one of these battles so far.
Really? from what I read BSD complaints they hate RedHat related stuff like systemd and GNOME code was Linux only for w hile, not sure if this was fixed in GJPME or downstream.
Canonical adopting systemd is what made it a standard, community went from being very divided on systemd to resigned and accepting it almost overnight after Canonical announced they were going systemd. This is a fairly common trend, they have a fair amount of influence although that seems to be waning after their push for snap.
No, the parent you are replying to meant that Canonical only gave up on upstart and accepted defeat (and thus went with systemd) when Debian made that decision.
Dude, that is historical true, Upstart was there before systemd , Redhat used upstart too. Then an RH dev created systemd and Arch,Fedora,Debian moved to systemd , Ubuntu followed Debian decision since Ubuntu is based on Debian and they share maintainers/developers.
I do yes. It's my daily driver. I love it on the desktop. I use it with KDE.
What I love is the excellent documentation, stable OS + rolling packages, ZFS on root (snapshots!), the ports collection so you can recompile packages easily with your own settings if needed.
Also no attempts to include their own IP like canonical does with snap. The low level of commercial interest is great. There's nothing being replaced just for the sake of it.
The biggest problem seems to be wifi drivers with their closed source blob skullduggery making things difficult, but I have no need for wifi on my desktop anyway.
Linux feels clunky like a bunch of third party cogs all mashed together. Some with teeth missing some with too many. If it's not SystemMd taking over the whole startup of system services and needing its own DHCP server, it's then down to package manager's. Apt being replaced with snap, snap replaced by flat images.
Its divided and with no formality. Someone will create some new thing, I'll get popular, get introduced in to some distro, command others to use it and then end up being abandoned.
Linux is now in bed with corporate. The original idea was having a free alternative of unix and/or sort of fight against Microsoft. That's gone.
These are not all bad things, but turns the experience of Linux in to a mess.
For FreeBSD:
It just works, its solid, it bounces back. It has ZFS. Its Unix.
The kernel is as whole, its solid. Rock battle tested solid. Packages feel meshed correctly. Documentation is a single source.
Its just lovely to use and when you replace Linux for FreeBSD you'll feel a weight off your shoulders as your system will shutdown rather than systemmd displaying "Waiting 5minutes for X to shutdown". Have a great community which isn't divided by distributions.
When I first starting out using Linux, Slackware was my saving grace. A Linux distribution that was well organized, consistent, and just worked. It saved me from the disillusionment caused by RedHat and RPM hell.
Know the system better but as for preference - Linux is better suited for some tasks and I use both - FreeBSD as host with Linux VMs. Switched after 10+ years of using Apple products exclusively.
I've recently posted[1] my thoughts on commercial vs. FOSS-driven workstations.
One huge downside to FreeBSD on a workstation is the lack of modern WiFi support. Impatiently waiting for WiFi drivers emulated via LinuxKPI[2].
I do. The main reason is that I know it better and I feel it is easier to know it well thanks to good documentation and relative simplicity (compare to Linux). First class ZFS support is another reason. While ZFS is available on Linux in distros I would use (OpenSuse or Fedora) it is not available by default and needs to be installed separately. Also use i3 WM and install only apps I use - a typical Linux distro which brings Gnome/KDE/Unity and lots of apps I don't need is a waste of space (on my small SSD).
Though I admit that FreeBSD desktop is less user and especially novice user friendly than Linux. Another big reason to prefer Linux is closed source software. Sometimes closed source apps have Linux versions but practically never FreeBSD ones. Linux emulation works for simple apps but setting up something like Skype or Zoom (which requires camera/mic access) is too much of a work even for an experienced FreeBSD user (if possible at all).
I would use FreeBSD myself if it weren't for Void Linux. You get all the extra tools and quality of life from Linux without any bloat, and it has a minimal init system.
It's also very convenient to use if you need up to date software since it is a rolling release, but there are some things in FreeBSD which is better like reproducible builds.
Kind of like Arch Linux but without the chaos, and the community appears to be growing!
I use exclusively Linux now because of work, but in the past I ran FreeBSD on the desktop because I like tinkering and taking things apart to see how they work, and this is much easier with FreeBSD than any Linux distro I know of. Same reason I prefer emacs to other editors.
Want to see how the “grep” command works? Just go to /usr/src/usr.bin/grep and read the source. Modify and reinstall it if you like. On Ubuntu this would be a huge chore of figuring out what package the command comes from, wrestling with apt-get source and dpkg-buildpackage, tweaking your apt settings to not immediately replace your custom-built one with the upstream version, etc.
Ran it for a long time, mostly I liked the simplicity of it over linux, which with systemd + udev etc has become much harder to configure easily just by reading through the files in /etc. The way you configure FreeBSD has been basically the same since 1998, so I haven't had to learn new magic with whatever trend is taking over the linux world. On modern linux, without a browser open to google shit constantly it's a real challenge to make even little quality of life changes. And Linux binary compat on FreeBSD was (maybe still is?) very good. Lately I'm on linux though since I need docker for my job workflow.
The last time I did was around the time PC-BSD became TrueOS, forcing me to reinstall. Running X11 gave me some kind of trouble afterwards, so installed vanilla FreeBSD, which gave me trouble, too. So I installed Debian and haven't looked back.
That was on a ThinkPad x220, which supposedly is supported well by the BSD systems, and it did run well with PC-BSD. But I figured I was getting too old for fiddling around all weekend to get it to work, and Debian just worked(tm).
Before that, I used FreeBSD on my desktop roughly from 2003 to 2005, mostly because I liked its simplicity and it did feel snappier than GNU/Linux at the time.
> The mergemaster(8) utility has been deprecated and will be removed in FreeBSD 14.0
This is a bit of a bummer, though.
I did just try to use etcupdate for the 13.2-RELEASE upgrade and it hung forever trying to grep for something in /etc/default/devfs.rules, so I had to fall back on mergemaster again...
Oh well, maybe a clean install when 14 is out and it'll behave better.
I 100% agree that the move to etcupdate should have been documented better. I also ended up in situations when I had to manually fix systems after upgrading.
Haven't had issues with etcupdate(8) on 14-CURRENT recently. Earlier each time I'd get "Conflicts remain from previous update, aborting" or some warning about inability to remove non-empty directory followed by "Old directories removed".
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?! :-/
There's already a `vendor/openssl-3.0` branch in their git repo, but those changes look like way too big to release in just a security patch for 13.2.
FreeBSD 14.0 is scheduled for July (2 months before OpenSSL 1.1.1 EOL), so maybe we'll get OpenSSL 3.0 in that release, and then a backport with the OpenSSL upgrade.
But the timelines seem too tight, so I'm not too optimistic.
> That doesn't get us full CUDA support, but we can run OpenCL apps at least (with x11/nvidia-driver, x11/linux-nvidia-libs and the nv-sglrun script from emulators/libc6-shim). And NVENC if you bother to compile it.
Why would you want to limit yourself to the operating system that cannot train, say, a pytorch model on your nvidia GPU?
We had some success running inference on CPU, which works for as long as the model isn't that large. But that doesn't scale for larger models, where you also want to batch requests and run them all at once on GPU.
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 me of the days before Windows 95 when I could just use DOS to save precious memory and CPU bandwidth.
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. Maybe it was just because it was running in a VM. Maybe it was because it's ARM. Not sure. I'd love to hear others experiences with FreeBSD on ARM.