Why I love FreeBSD

"with no downtime and no rebooting"

So, no patching. I used to boast about my NetWare server uptimes but that is so noughties 8)

A Logitech FullHD camera on USB, but I doubt that the problem was camera-specific. I believe that I would have seen the same behavior on any high-resolution USB camera.

In FreeBSD, the command required for recording was very simple and it worked flawlessly. In Linux, it was more complex and there were various stuttering problems at maximum resolution. I am still using those cameras, but I have not tried them again in Linux. In Linux they worked worse than in FreeBSD around 5 years ago, perhaps nowadays there is no longer any problem in Linux.

This was intended to be an example that you cannot know a priori whether a given device will work better on FreeBSD or on Linux. In general, there is a greater probability for Linux to have good support than for FreeBSD, but there are also counterexamples, so you cannot be certain which is better until you try both.

Standardization [1] for backups. A tape with 2.5 TB (uncompressed) goes for 30 EUR. The LTO-6 (affordable current iteration) drive itself goes for 300-500 EUR if you buy it second hand. Cheaper if you grab one without casing and FC, but you'd need a FC switch and a FC HBA. I went for a SAS HBA instead, although since I already for fiber through the whole house, FC would've been suffice.

[1] https://github.com/LinearTapeFileSystem/ltfs

I would not be surprised if FreeBSD NFS is slower than Linux NFS, but 10x slower is too weird to be correct. Have you used the same NFS version, e.g. NFSv4, on both FreeBSD and Linux?

I have used for many years file servers on FreeBSD, servicing a great number of users and they certainly were not slower than Linux and they had perfect reliability. It is true however, that I have used Samba, not NFS.

I have also used NFS in a few cases, but I have not run benchmarks. I mean that I have not tested intensive random accesses, but I have just copied entire disks through NFS and that worked at the speed limit imposed by a 1 Gb/s Ethernet link, so at least for sequential transfers NFS did not seem to have any speed problems.

The speed of NFS also depends on the speed of the file system used on the server. If you have tested a FreeBSD with ZFS versus a Linux with XFS or EXT4, than your benchmark might not reflect anything about FreeBSD vs. Linux, but only about ZFS. ZFS is significantly slower than XFS or EXT4, regardless if it is used by FreeBSD or by Linux.

Nobody uses ZFS for speed, but only when the extra features provided by ZFS are desired. ZFS is still faster than BTRFS, but not by so much as XFS/EXT4 are faster than ZFS.

On FreeBSD, its older file system, UFS, is faster than ZFS, though not as fast as XFS/EXT4. But if you use NVMe SSDs on the file server, the speed of NFS should be mostly limited by Ethernet, not by the file system of the server.

> I use FreeBSD at work every since day and while I don't hate it, I do wish we just used Linux. There are more guides, tools, etc for Linux than for FreeBSD.

Regarding guides specifically, FreeBSD has exceptional resources:

  FreeBSD Handbook[0]
  FreeBSD Porter's Handbook[1]
  FreeBSD Developers' Handbook[2]
  The Design and Implementation of the FreeBSD Operating System[3]

0 - https://docs.freebsd.org/en/books/handbook/

1 - https://docs.freebsd.org/en/books/porters-handbook/

2 - https://docs.freebsd.org/en/books/developers-handbook/

3 - https://books.google.com/books/about/The_Design_and_Implemen...

> … Yes, as a comment in this sub-thread stated, jails exist …

https://mastodon.bsd.cafe/@grahamperrin/116168374700889783

> Would anyone like to say something? > > …

>>maybe I'm "holding it wrong" (always a strong possibility)

Yes. You are holding it wrong. And it's obvious from your comment.

That's why I don't use Linux. It lacks Jail support.

Podman is a viable option. I'm not sure how it works but I was able to run Alpine and Debian containers by setting a few system flags.

Docker is a concept resembling FreeBSD's jails that were introduced in year 2000, having much better isolation, much better security than Docker has had for a long time (perhaps even now jails are still superior to Docker).

>I use Arch and I'm always worried a kernel upgrade is going to break the ZFS modulet

That can only happen if you use the unreliable DKMS way of installing it. If you use zfs-linux provided by archzfs it will only allow updating if it's compatible with the kernel, which in linux-lts case is within couple hours of a kernel update.

https://github.com/archzfs/archzfs https://wiki.archlinux.org/title/ZFS#Kernel-specific_package...

> … For those that aren't familiar, ZFS isn't part of mainline Linux because of licensing incompatibility (and general distrust of Oracle). …

It's probably fair to say that trust in Oracle is irrelevant to OpenZFS.

Where Linux does use ZFS: to the best of my knowledge, it's typically OpenZFS – https://news.ycombinator.com/item?id=47407937 is my own use case.

On openSUSE Tumbleweed, it is. Each Upgrade creates two snapshots, one before, one after, and if anything goes wrong, I can boot into a snapshot where the world was still in order.

I have a higher opinion of ZFS than I do of btrfs, but FWIW snapper+btrfs has worked well for me on openSUSE Tumbleweed for ten years now, too.

The btrfs code quality seems less than ZFS, based on the reports I have read.

Debian has an installation guide[1]. I'd imagine all the major distributions do.

But it probably has to change a lot for every major release, because so many things change. FreeBSD major releases have changes too, but a lot of the user interfaces are very stable and so the documentation can be too. Stable documentation allows time for it to be edited and revised to become better documentation, as well as developing quality translations.

[1] https://www.debian.org/releases/stable/amd64/

I've been surprised at times by what's missing. There are are some strange omissions, from most recent memory around the Bourne shell builtin commands and make(1). I've had to go hunting in other BSD distribution manuals at times to find what I need. I'd say the GNU core utilities sometimes have better docs for their equivalent commands.

That said, for non-core utilities on Linux it's pretty hit-or-miss. The BSDs are generally pretty consistent in what they do offer, and that's what I love about them. Of course it's a different development model and it shows.

Theoretically yes, however still limited by how well the FreeBSD Linux layer handles syscalls. A year or so back I tried running .NET (just binaries, not via a container) since the port wasn't as far along as today and it crashed due to what I suspect was slight differences in signal handling defaults.

And this is part of the situation that's going to get worse, io_uring will become more popular in language runtimes and iirc it's not trivial to emulate via existing FreeBSD mechanisms (kqueue).

Iirc Mac docker uses xhyve (bhyve port/inspired) to run containers via Linux emulation, MS went for pv-Linux for WSL2, while FreeBSD has been "good enough" so far.

But I think that for containers it's either time to shape up Linux emulation well (It's ironic that WSL1 ironed out their worst quirks just as WSL2 was introduced, although that was without io_uring) or just add an option for Podman to have a minimal pv-Linux kernel via bhyve to get better compatibility.

The difference compared to a quarter of a century ago is that hardware virtualization is an ubiquitous thing now and that machines go so much faster that you don't even realize you're running in a VM anymore: it's pretty much transparent. I run Docker on my Linux servers inside a VM. There's no way I let Docker touch the bare metal, not with a ten foot pole.

If people want or need to run Docker on FreeBSD, they can run a Linux VM under bhyve.

Docker's what lets me spend more time using the software on my server than fiddling with it. I got the fiddling out of my system years ago, I just want shit to work now.

I don't really care about it per se but having a cross-distro unified daemon config & supervisor, package manager, and ability to cram every single important file into a file tree (again, using the same interface to achieve this with every daemon) that has only those files in it (making backups and restores trivial) and then easily verify that I got all the important files (destroy image -> re-create, does it still look good? Then I got everything) makes everything so easy. I no longer put off trying a new service until the weekend because it'll take an unknown amount of time that could end up being hours. Odds are I can have anything available in the official Docker registry (which is approximately everything, these days) up in five minutes flat to try it out, and may not even need any further modifications for it to be ready for (personal) "production".

I use Debian but don't even care, I haven't had to touch systemd once (thank god) and the only Debian-parts I even use are its ZFS, SSH, and Docker, with my ten or so actual user-facing services all just pulled and managed via Docker, ready to transfer to any other distro seamlessly, should I ever care to. Even Samba is under Docker (oh my god it is so much easier to configure for common use-cases this way).

(I would definitely be using FreeBSD on my server if I cared about anything other than Docker, though—I haven't actually liked Linux for about fifteen years now)

I've fixed too many linux-isms in code manually over the years, pkg/ports does what it should but since *nix tradition relies on hardcoded paths I often wanted out-of-tree builds for various software.

And that's the thing, as I grow older I feel more and more that I just want the parts of computing that I don't want to _care_ about to be stupid simple.

If I'm doing a program needing a recent version of some language that doesn't have a FreeBSD port yet and some database behind it, I don't really want to configure it all manually because I don't particularly care for porting the runtime or managing the database (that isn't exposed to the outside world anyhow).

This is stuff where I don't want a large CI pipe or other management (or needing to remember to upgrade the packages if I upgrade the hosting OS).

Stuff like this is why "the clouds are winning", friction should be linear depending on the effort I want to put into managing something.

But going for real HW or even VPS a places an "upgrade tax" on me because I can't just let non-public services like an isolated DB just ride-along over major versions (maybe Jails with isolated userlands could be an option, but that becomes painful instead when needing newer versions of the application behind the veil).

docker and flatpak/snap are _extremely_ different tools with very different purposes.

What exactly do you think pkg(1) is for? [1]

[1]: https://docs-archive.freebsd.org/doc/10.3-RELEASE/usr/local/...

Stock FreeBSD is about 1.5GB. If you really strip it down to a barebones OS it's about 300MB.

It is widely known that Linux has "better" hardware support for many peripheral devices, but few know what "better" means, i.e. that a lot of devices that you can buy have various bugs and in most cases their vendors do not document the bugs in any way, because they provide Windows drivers that contain workarounds for the bugs, and they do not care about other operating systems.

The users of other operating systems must discover the bugs and how to handle them by reverse engineering, and here Linux has the advantage of a much greater user base than any alternative, so in most cases the bugs will be identified by some Linux user, and then either the user or the maintainers of the corresponding Linux subsystem will implement a workaround for the bug.

While you are right that it would be better to never need tweaking the number of buffers, all your links show such a problem caused by the same application, the firewall pf.

I assume that for some reason pf consumes more buffers than other applications, so it is likely to cause such problems. So pf users should preemptively change the default configuration.

I have never used pf, because I prefer the native FreeBSD firewall, both to pf and to the Linux firewall.

With the native firewall and with the many other networking applications that I have run, I have never seen buffer exhaustion, and like I have said, the mean time between reboots was well above a year.

FreeBSD and the other *BSDs have always been famous for not needing reboots, even after years of continuous operation. For this goal, avoiding memory fragmentation caused by dynamic allocation is essential. Thus static allocation for various kinds of resources might be necessary.

> all hail u/cperciva

Colin Percival (FreeBSD Primary Release Engineering Team Lead) longer uses that ID in Reddit.

Instead: /u/perciva

Most recently, in /r/freebsd https://www.reddit.com/r/freebsd/comments/1rphd7t/freebsd_14...

All hail.

> Doesn't linuxulator + podman suffice?

No it is not reliable enough. Some syscalls not implemented, there are edge case issues with procfs etc. Best to execute in a Linux VM.

Unfortunately podman on freebsd is pretty early stage. I was only able to get very simple containers to run.

What you say is true only when you define "desktop use" in a certain way, which corresponds to what an Apple PC is good for.

I define "desktop use" in another way, and for my definition any Apple PC is completely non-competitive, by having a much lower performance and a much higher price than a desktop PC using an AMD Ryzen CPU.

Apple PCs have exceptional single-thread performance, but that is irrelevant for me. I care about multi-threaded performance and especially about floating-point FP64 and big integer computational throughput, for which the Apple CPUs are weak, one could say years behind their competition, except that Apple does not make any attempt to compete in this domain.

An Apple PC may be the optimum PC for your needs and that is fine, but you should not believe that any computer user has the same needs as you.

A consequence of the license, which allows Apple and Sony to do exactly that.

do you remember opendarwin? i was also at puredarwin but the project seams death