My home server has been running FreeBSD for ten years now, and it has never let me down. Except for one time I got fresh with /dev/speaker and triggered a spontaneous reboot (I don't know if it's FreeBSD's fault or the hardware, though).
I delayed upgrading to 15.0 after it was released, but last weekend I finally did it, and it left me wondering why I hadn't done it sooner, because it went quickly and smoothly.
Is there anything FreeBSD can do that, say, Debian cannot? Probably not (at least I cannot think of anything). When I set up the server, ZFS was a huge selling point, but I heard that it works quite well on Linux, these days. But I appreciate the reliability, the good documentation, the community (when I need help).
There are various niche applications where Debian or any Linux are worse than FreeBSD.
For example the support for magnetic tapes and for a few other SCSI peripherals is better in FreeBSD. The Linux utility for controlling a LTO tape drive lacks some important options that the corresponding FreeBSD utility has.
I have a tape drive, and to be able to use it like I want I had to move it to a FreeBSD server.
Some years ago I was using a surveillance camera that was much easier to use in FreeBSD than in Linux, if you wanted to record good quality video and audio. I have not tried more recently to use such cameras in Linux, to see if now the recording quality is better.
So while there are more hardware devices that have better support in Linux than in FreeBSD, there are also devices with better support in FreeBSD than in Linux.
However the main reason why I use FreeBSD on many of my servers is that I need much less time for their administration than for Linux servers. In my experience, Linux servers need much less time for administration than Windows servers, and FreeBSD compares to Linux like Linux to Windows.
I have FreeBSD servers that I have not touched for years, and they have worked 24/7 with no downtime and no rebooting, and this includes servers connected directly to the Internet, which implement firewalls, routers and various services, like NTP, DNS servers and proxies, e-mail servers, web servers and proxies etc.
> I have FreeBSD servers that I have not touched for years, and they have worked 24/7 with no downtime and no rebooting, and this includes servers connected directly to the Internet, which implement firewalls, routers and various services, like NTP, DNS servers and proxies, e-mail servers, web servers and proxies etc.
Same. We've got qmail config files with 2006 as the mtime
Well, my experience on the stable release branches is that there aren't all that many kernel updates, so if you keep your services patched then you really only need to reboot about every 6 months.
The longest without rebooting two prod FreeBSD servers I was once responsible for, including applying userland patches, was roughly 3000 days (just over 8 years).
Fair, but to my point none of those security patches for 14.2 or 14.3 that required a reboot were critical for our use case. I'm more worried about people's crappy Wordpress blogs getting hacked.
My approach to IT security starts from: There is very little security. That stands regardless of OS.
I patch everything I can think of, as regularly as I can think of. It is rare that a patch is delivered along with a changelog along the lines of "meh, lol, soz" I'm old enough to remember when the notion of a patch was the only term in play, well before "service packs".
I'm jolly boring and run host based firewalls and router, switch, edge etc firewalls, mostly with point to point rules. Its a bit of a faff and so is completely random and different passwords and targeted MFA on each host. I'm fairly sure it is quite hard to pivot across my land.
The best approach to security is to start with: "Mine is a bit shite" and "I'm probably already compromised" and work from there. In the real world: start with a threat model and work on out. For most people that is avoiding scams and becoming part of a bitcoin farm.
Cameras? I suppose the world still has some weird cameras that need proprietary/weird drivers, but for all intents and purposes: USB cameras are UVC and work with a generic driver, and IP cameras are OnVIF and work with ffmpeg. I can't imagine the latter having any OS dependencies as far as Linux/BSD/Mac/Windows is concerned. Quality is fine - I have a bunch recording 24/7 with high quality audio and video.
> Some years ago I was using a surveillance camera that was much easier to use in FreeBSD than in Linux, if you wanted to record good quality video and audio. I have not tried more recently to use such cameras in Linux, to see if now the recording quality is better.
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.
I am sorry, I have a hard time accepting this level of detail, acknowledging it was half a decade ago.
In a nutshell, you content that FreeBSD running on the same hardware as "a linux" performed better with camera operations. However, you did not specify even a specific camera model, or the interface(s) used to interact with the camera.
I have zero issue accepting that a BSD is better than a linux at things, pretending otherwise is foolish. However, this specific example isn't tracking.
I have already said that it was an USB camera, using the UVC protocol, and that it had FullHD resolution. Nothing else really matters about the interface.
FreeBSD has a dedicated service for USB cameras, webcamd, and it worked very well for capturing video and audio at maximum resolution, and without interference from any other programs that were running concurrently on the server. As I have said, in Linux not only the required configuration was more complex, but I tried several programs and all had stutter problems at FullHD resolution (while other programs were also running on the computer). That was the status at that time. Now, many kernel versions later, I assume that such problems no longer exist, at least not with old cameras.
I do not see what is not tracking for you in this example. It is not an isolated example, for many years FreeBSD was known to have less problems than Linux in handling video streams and audio streams with low latency and constant throughput. More recently, Linux has also improved, but in the past unreliable performance with certain video/audio devices was not unusual (i.e. where other programs running concurrently caused video/audio drops or delays).
That’s fair. I’m struggling to understand how Linux had a harder time interfacing with a USB byte stream than a bsd would. A model for the camera would be great!
I think that it was the Logitech C920, which is still available.
But like I have said, I do not think that the model mattered much. IIRC the camera had an internal video encoder, because otherwise uncompressed FullHD video would not pass through USB 2.0.
The differences between FreeBSD and Linux at that time were at 2 levels. Regarding the user interface, FreeBSD happened to include in the base system programs dedicated for using such a camera, so their use was very simple. On Linux I had to search and install a suitable package, and those that were available were more general video applications and because of that their configuration to do the specific thing that I needed was more complex.
Besides the simpler interface, there was the stuttering problem on Linux, which was caused by the scheduling policies of the kernel. Perhaps it would have been possible on Linux to find a way to ensure a higher priority for the video and audio handling, to not be preempted by the concurrent programs running on the server, but since on FreeBSD everything worked fine out of the box there was no reason for me to investigate how that could be done on Linux.
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.
> Is there anything FreeBSD can do that, say, Debian cannot?
If you asked the opposite (what can Debian do that FreeBSD cannot) I would have more to say and it would mostly be preceded by "I know FreeBSD is not Linux but ...". Whenever I need to do any sort of maintenance or inspection I have to look up the equivalent commands for things like `lsblk` and something nested in `/usr/etc/...` when I'm used to finding it in `/etc/` over every other system.
This is a consequence of both FreeBSD's reliability in needing very infrequent attention and my limited use-cases to use it. As a NAS it is great but I can't touch it without full-text search of all my notes on the side! Either way, no regrets about learning and relying on it after ~18 months so far.
Lack of good NFS support? When we benchmarked it last it was 10x+ slower than running on linux (ubuntu).
Also lack of collective mindshare. 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. Yes, as a comment in this sub-thread stated, jails exist but everyone knows docker, not jails. So even with jails apparently being better than containers, it doesn't really matter, there isn't the ecosystem there.
FreeBSD might be as good as this blog author makes it out to be, and maybe I'm "holding it wrong" (always a strong possibility) but I can't help but feel it causes more friction than I'd like, it's just "slightly" harder to do anything. In the age of LLMs I have to tell it (or put it in my system prompt) "I'm using FreeBSD" or it will be give me Linux advice. It just feels like death by a thousand papercuts.
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.
It is though. Had the same experience, dog slow transfers in FreeBSD on brandnew servers with 10/25G+ cards, hovering at 1-2G speeds. Only switching to Linux helped, and now easily saturates the links.
> speed limit imposed by a 1 Gb/s Ethernet link
FreeBSD might be slow, but its not that slow that it cant saturate a 1G link ;)
All this would be true if Linux and FreeBSD had similar exposition. But there's obviously less users and less hardware in the BSD world, so we must expect a higher variance.
For instance, searching in recent FreeBSD issues, some hardware is compatible but 3× slower, as in "NFS is much too slow at 10GbaseT"[^1].
Or a FreeBSD upgrade to v14 could sink the NFS performance, as in "Write performance to NFS share is ~4x slower than on 13.2".
Of course, these bugs happen with Linux, but there are vastly more resources to detect and fix these problems in the Linux world.
> 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]
Not to mention that the FreeBSD man pages are quite complete. Granted, I am biased as I have used FreeBSD in various efforts for quite some time and am a fan of it. Still and all, the project's documentation is a gold standard IMHO.
> Documentation certainly is not gold standard. I'm a former doc tree committer, familiar with many of the bugs …
As "a former doc tree committer", I am sure you are aware that no set of documentation artifacts are without error of some sort. To be exact, you provided two examples of your identifying what you believe to be same.
I stand by my statement that the cited FreeBSD resources are "a gold standard" while acknowledging they are not perfect. What they are, again in my humble opinion, is vastly superior to what I have found to exist in the Linux world. Perhaps your experience contradicts this position; if so, I respect that.
Arch Wiki can't never cover a userland+kernel documentation by design. FreeBSD does. Arch it's utterly lacking in tons of areas. Forget proper sysctl documentation. Say goodbye to tons of device settings' documentation. Forget iptables/NFT's documentatiton on par of PF.
I don't agree about that ZFS issue. Using whole disk isn't inheritantly wrong. When you have data pool separated from boot disks, using whole disks is better. No need to create partition table, when replacing disk. No worring over block alignment.
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).
Better isolation, better security, but far fewer gists and shared config-files shared ok the Internet for common tasks. Docker comprehensively wkn thr popularity contest, and is often the more convenient solution because of it, in a worse is better way.
People comparing Docker and Jails don't really understand that Docker is 99% about packaging and composing software. From that perspective Jails are nothing like Docker containers. No versioning, no standard, no registry, no compose, no healthchcks, no tree of containers, etc. etc. etc.
If you want to compare Jails to something on Linux then I think LXD is probably much closer to what Jails are.
ZFS on FreeBSD is first class. I had an old FreeNAS raid z5 array on 5x 500GB disks that I wanted to check 4 years after decommissioning the system. I put together a temporary machine with all the disks plugged in and without doing anything the live FreeBSD image found and configured the array. I was instantly able to look through the file system and even dump it to my current FreeBSD server with almost 0 effort. I was sold after that. These days I prefer to run small systems and basic services. I don't want webguis or docker images anymore.
Just so you know: the zfs in freebsd and in linux are the same codebase. Literally. It’s OpenZFS.
Also, a few years ago the FreeBSD people decided to throw away their own ZFS implementation and import the linux one (OpenZFS) because they couldn’t keep up with the development pace.
Nowadays ZFS development is collaborative but in each major freebsd release it’s clearly marked which OpenZFS releases they imported in the FreeBSD codebase.
Right. On my development workstation I use Arch and I'm always worried a kernel upgrade is going to break the ZFS module. For those that aren't familiar, ZFS isn't part of mainline Linux because of licensing incompatibility (and general distrust of Oracle).
>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.
>Is there anything FreeBSD can do that, say, Debian cannot?
ZFS boot environments.
One could install Debian's root on ZFS by following the OpenZFS documentation guide, combine it with ZFSBootMenu (or similar), but there won't be any upstream support from the Debian project itself.
The Nitrux Linux distribution is based on Debian and provides an immutable feature similar to boot environments, but you can't treat your immutable boot images the same way you can treat your mutable data like how you can with ZFS datasets on FreeBSD.
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.
Last I heard (~8 years ago), the RAID-like functionality in btrfs was very unstable and crash-prone. The impression I got was that there was not a lot of interest in fixing this. Then bcachefs came and ... appears to have gone nowhere AFAICT.
The non-RAID part of btrfs appears to be stable. It's the default filesystem on openSUSE and SLES. But I don't think it's ever going to reach feature parity with ZFS.
And to the grandparent post's point, since the split with the kernel there've been two big new feature releases: reconcile, which puts our data and drive management head and shoulders above other filesystems - and erasure coding was just released, 1.37 came out a few days ago.
btrfs is suffering from a lot of old bad publicity and some poor design decisions around RAID.
But by now it is a great file system if you don't go near RAID5/6. btrfs has its flaws (ZFS has its own flaws!). However:
- It's used a lot, especially by facebook and Redhat (on fedora)
- Gets a lot of testing
- Sees a lot of bug fixes
- Has a lot of features
I haven't read btrfs code but given that it is a popular file system and Linux code quality tends to be good in popular subsystems I would hesitate to say its code quality is worse than ZFS in any way.
> but real life workload are not "Geometric Mean".
A good benchmark suite consists of good benchmarks chosen carefully. These benchmarks are not chosen randomly. They represent diverse ways to "stress" or exercise the system. Real life workloads are indeed closer to "Geometric Mean" of various benchmarks by definition because real life workloads are diverse. Not everything would be like sqlite3 which is single pattern of file system usage.
Geekbench, Cinebench, 3DMark etc. are all averages or geometric means of various benchmarks also.
> When I use firefox, sqlite performance matter more than any random benchmark.
You've selected a single benchmark (sqlite) and said it's so important to you that it overrides everything else when you are comparing ZFS vs btrfs.
If you feel that a single benchmark like sqlite is good enough then that is fine -- your decision. I am hesitant to do the same and prefer geometric mean.
Be specific. Why do you need LVM? What for, what do you do with it?
Secondly: are you aware that ZFS includes what LVM does on Linux, and so you don't need a separate tool for it? This makes the comparison tricky but it's important to consider.
FreeBSD is an amazing beast. I'm currently using it as my workstation, and because I need to use Linux, bhyve came to the rescue and is easy to use it through the `vm` wrapper tool. It works like a charm and it is built in.
Being that said, on FreeBSD 15, I believe I've found a serious bug: when I disconnect a USB optical mouse on the "Lenovo 16 G7 ARP" the system completes freezes and reboots, I guess it reaches a kernel panic. It took me a few disconnections of the power, ethernet and finally the mouse to detect this condition.
Surprinsingly this does not happen if the device is wireless (I tried to remove the receiver of a Trackball and the system keeps working just fine). I find this really weird and don't know if actually report it in the FreeBSD forums, maybe is just a glitch on this particular laptop or it has something to do with the touchpad, just guessing here.
Putting this particular issue aside, I'm extremely happy that almost everything works with little or no effort on a recent/modern laptop.
What documentation does a distro even publish? I only ask because freebsd has the most solid documentation I've used of any OS I've ever encountered. I seriously doubt Debian has documented the linux kernel that well (which, tbf, would be an insane project to even attempt)
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.
I wonder if this is a curse of popularity. Presumably the documentation is stable and good because the software is also stable, and well-specified with one way to do each thing rather than five competing projects.
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.
Indeed, ideally we could get docker on FreeBSD using the same approach as is used on macOS — automatically run (one or more) Linux VMs under bhyve.
I wonder if FreeBSD ought to consider a WSL2-style approach to Linux binary compatibility, too.
Keeping the Linux syscall compatibility layer up-to-date has always been a resource problem, especially when syscalls depend on large, complex Linux kernel subsystems that just don’t map cleanly to FreeBSD kernel facilities.
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).
Sure they're different. They all download blobs and can then execute them. Exactly how, when and why is completely different but they still get you blobs.
In the same way s3 is different to a dropbox, and a car being different to a bike.
Can't tell if you're ragebaiting here, but I'm very confused by this question because they support an entirely different set of features, and if you use both it's painfully obvious how they're different.
Docker is built for running services, distribution is part of that, but it's core is that you can pull an image and run random service on your machine packaged with all the right libraries, network them into your machine in the way you like so it can access the right things, constrain it's resources, and create our own image based on it.
Snap/Flatpak is built to distribute applications, sandboxing being a core part of it, with applications wanting to integrate into distribution mechanics such as audio, URL handling, taking screenshots, ...
For me, the difference is in do I get to compile this from sources myself or do I get someone elses compiler output?
IOW it's not comparing vastly different vehicles, but rather a vehicle with its blueprint.
Also, a long time ago it was commonly accepted that spaghetti code is awful. Docker replaces all that with spaghetti services and debugging gets much worse.
In pkgsrc, building packages isn't done by default and 100% optional. I'm not sure what logic you're ascertaining here.
There were operating systems before package managers and AFAICT IIRC the first package manager "repository" was a stack of floppies.
But yes, there's always a choice to be made. Docker could separate out the image repository elsewhere. It could integrate buildroot. It could use a suitable initramfs generator. I'm not sure why present day devs like to create a hodgepodge of different distros mashed together and even do it all from CI, while the same CI could also run gmake on a source tree.
For a sysadmin, docker would be fine. For a programmer, dealing with binary blobs all day, that's IMNSHO not what programming should be about.
> But I appreciate the reliability, the good documentation, the community
These were big reasons for me. Cannot overstate the documentation angle.
> Ports. Packages. > DEB/APT/RPM (particularily for a C programmer.
> Licensing more friendly to integrating into your appliances (I did this) or code
Before ZFS it was still better for the afformentioned reasons but ZFS was a game changer.
I started Linux with Slackware and writing my own ppp up/down scripts while dual booting from windows, which took 2 weeks to get online the first time, then I went to redhat/debian/mandrake for a few years... then I found FreeBSD at it was like a breath of 'clear' air.
Started using it for my daily desktop in 2002 and I still use it on several converted Macs at home and my main 'office' server which is a VPS these days.
Production wise I would always have to reboot my fbsd servers for EOL never any issues and many uptimes north of 1000 days over the years. That builds trust.
I trust FreeBSD project to be conservative and consistent for the most part -- THE PRINCIPLE OF LEAST SURPRISE -- another thing I have not seen enough of with Linux distros.
That is not really accurate? Linux traffic control (tc, [0]) exists since Kernel 2.2. It can introduce traffic latency and a few other network conditions, like packet loss.
Hmm kind of... I was referring to the fact that dummynet models pipes with a fixed bandwidth and centralized scheduler. Packets are released according to very high precision transmission timing. This means that serialization delay, queue buildup, and link behavior are simulated in a way that resembles real network conditions. Dummynet can provide a highly deterministic timing and queue behavior, which made it popular in networking research and WAN emulation experiments. TC cannot do that with the same accuracy.
I think much like other tools, think SELinux vs OpenBSD (unveil, etc) TC is more flexible (does more things) but there are _some things_ that can't do, and even for things both can do *BSD solutions are much simpler.
AFAIK the most common is ARC but there are other areas as well.
On Linux, ARC memory is reclaimed using the kernel shrinker API which has historically been a problem. There has been several bugs leading to OOMs or system freeze due to high memory usage on systems that use ARC heavily.
On FreeBSD ARC is integrated directly with the VM subsystem. The stack is simpler, less bug-prone.
Now this is not a ZFS algo/whatever problem. It's an implementation/subsystem issue but it's still something to keep an eye on for the ZFS admin.
ps. I'm using ZFS on Linux for 15 years on a self-hosted, home backup server and only once I've had mem issues leading to crashes when I misconfigured the ARC. So it's fairly _stable_ but still not FreeBSD-level stable.
> … the kernel shrinker API which has historically been a problem. …
Is that still a problem?
A few weeks ago I noted a change in ARC-related documentation for OpenZFS on Linux. I can't remember the details (I can find them, if necessary) but I do remember that it was a significant improvement for Linux users.
There are narrow things for which FreeBSD is just lovely but it hasn’t been as powerful as Linux for decades. It was one of the best server OS back in the 1990s though. Just a very clean implementation. I used it a lot back in the day and am very fond of it. But I can no longer recommend it.
Linux added differentiated support for high-scale and high-performance systems pretty early on. Good support for very high core counts, kernel bypass mechanisms, XFS, and more recently things like io_uring. This opened Linux up to a class of high-end applications that FreeBSD wasn't designed for.
FreeBSD was excellent for ordinary UNIX-y server things. If you were designing a high-end database engine though, where you mostly just need the OS to get out of the way, it was much easier to target Linux.
I started out running FreeBSD on my home servers, then moved to Alpine Linux because all server software that I wanted to run was provided in Docker docker containers and with docker compose examples, so it was just easier. Moving the ZFS pools over to Linux was effortlessly.
And now I am looking at moving over to k3s (still on Alpine) because everyone is providing Helm charts, so it seems easier.
I really like FreeBSD, but it's just easier to go with the flow.
> I delayed upgrading to 15.0 after it was released, but last weekend I finally did it, and it left me wondering why I hadn't done it sooner, because it went quickly and smoothly.
I haven't done that yet because I think I'd want to switch to pkgbase but that makes me nervous. Did you go with that option or continued to use the sets?
Why not create a boot environment and try out FreeBSD 15 with pkgbase ? If the experiment is successful just make the boot environment the default otherwise throw it away...
With such powerful tools I find it fascinating that FreeBSD users are not more willing to experiment !
I haven't switched to pkgbase. Yet. I don't intend to for the time being. I set up a VM to test it, but I haven't gotten around to actually testing it.
FreeBSD is actually really nice as an OS, but Linux gets pretty much all of the application support. For example compare XigmaNAS with OMV, I'd really prefer to run my NAS on FreeBSD but Xigma has more or less stalled while OMV is being actively worked on.
That’s all it came down to with me.. FreeBSD doing WiFi circa 2002 was a remote dream. Shit even Linux you had to use ndiswrapper and it still prob wouldn’t work
I'm using Linux since the Slackware-on-a-CDRom days and systemd is a lost cause: it only got worse and worse and only kept meddling more and more into the Linux ecosystem.
The XZ "I only work on systemd distro" backdoor was the final straw (people are going to say it's unrelated but the fact is there: non-systemd Linux distro weren't affected).
I've been gradually switching my workflow to VMs and containers and my idea is to, eventually, run the VMs under FreeBSD's bhyve instead of running them from a systemd Linux distro (Proxmox in my case).
At long last I should soon be, once again, totally free of systemd (last time it was before it existed).
> this is possible via snapper on Linux + btrfs but needs complex installation and is not so integrated
FWIW, openSUSE defaults to btrfs on the root filesystem and uses snapper in a very similar manner to zfs boot environments on FreeBSD. I don't have a lot of experience with the latter, but I have been running openSUSE Tumbleweed on my desktop and primary laptop for about 10 years now, and the btrfs+snapper arrangement has worked pretty well for me.
(I also run FreeBSD on my home server and just did the upgrade to 15.0 this weekend, which left me wondering why I had procrastinated this upgrade for so long. It went perfectly fine.)
You mean people still log into a virtual terminal and call startx? (blushing emoji)
I mean, if that's the way they like it, that's fine. It feels a bit quaint, though, at least to me. If a graphical desktop is what I want anyway, why not make it automatic? I'm not judging, just trying to understand.
I know a lot of arch users that do that, especially if they just use simple window managers like i3 or window maker. Though, on a wayland system startx doesn't work, each compositor has its own command
Huh. If you go through the hazing of installing arch without that new installation script, it is consistent, I suppose. One thing in favor of this approach, is that it is very straightforward.
Not what I'd choose, but I think that is the beauty of the whole free software movement - one thing you get in utter abundance is choice.
I only use it for shell access to machines in my home network, so I cannot remark on performance, but it is also by far the easiest to use VPN solution I've had contact with. Not that I'm an expert in this matter, but setting up Wireguard access was dead simple and it has never given me any trouble since.
They also forced us to waste relatively valuable vertical screen space on the task bar, taking away our ability to move it to the left or right screen edges.
When I started using Linux, I didn't do so because I disliked Windows so much, I just was an insatiably curious nerd.
But since then, each new version of Windows has made me more and more grateful for not having to deal with that dumpster fire on my personal devices.
The saddest part to me is that I have the strong impression it wouldn't take that much work to turn Windows into a much better system. But for whatever reason, Microsoft is not interested in making that happen. Maybe they are incapable of doing so. But the system itself not the reason.
I delayed upgrading to 15.0 after it was released, but last weekend I finally did it, and it left me wondering why I hadn't done it sooner, because it went quickly and smoothly.
Is there anything FreeBSD can do that, say, Debian cannot? Probably not (at least I cannot think of anything). When I set up the server, ZFS was a huge selling point, but I heard that it works quite well on Linux, these days. But I appreciate the reliability, the good documentation, the community (when I need help).
reply