[krylon]

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).

[adrian_b]

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.

[adiabatichottub]

> 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

[gerdesj]

"with no downtime and no rebooting"

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

[adiabatichottub]

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.

[grahamjperrin]

> … stable … about every 6 months.

Maybe slightly optimistic.

https://bokut.in/freebsd-patch-level-table/#stable/13

https://bokut.in/freebsd-patch-level-table/#stable/14

https://bokut.in/freebsd-patch-level-table/#stable/15

[AdieuToLogic]

>> … stable … about every 6 months.

> Maybe slightly optimistic.

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).

[adiabatichottub]

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.

[MarkusWandel]

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.

[guenthert]

> For example the support for magnetic tapes and for a few other SCSI peripherals is better in FreeBSD.

Could you give us another hint?

> The Linux utility for controlling a LTO tape drive lacks some important options that the corresponding FreeBSD utility has.

That should be easy to list, no? It's been a while since I used a LTO drive, but I don't know what I missed.

> I have FreeBSD servers that I have not touched for years

Are you sure, they are still "yours"?

[irishcoffee]

> 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.

This example seems very hand-wavy. What camera?

[adrian_b]

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.

[irishcoffee]

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.

[adrian_b]

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).

[irishcoffee]

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!

[george916a]

Magnetic tapes? Super cool! What are you using them for if one may ask? Very curious.

[Fnoord]

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

[zenoprax]

> 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.

[joshstrange]

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.

[adrian_b]

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.

[throwaway270925]

> but 10x slower is too weird to be correct.

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 ;)

[idoubtit]

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.

[^1]: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277197

[^2]: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276299

[AdieuToLogic]

> 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.

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...

[grahamjperrin]

> Regarding guides specifically, FreeBSD has exceptional resources: FreeBSD Handbook …

Ahem.

<https://www.reddit.com/r/freebsd/comments/1rpnd05/comment/o9...> for the ZFS chapter "… telling people to do the WRONG thing, …"

<https://www.reddit.com/r/freebsd/comments/1ru0k9u/comment/oa...> for the ports chapter "… misleading, it was wrongly updated: …"

– and so on.

> … 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 …

[AdieuToLogic]

> 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.

[andxor]

Arch Linux wiki is the gold standard and better than FreeBSD.

[ZWoz]

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.

[grahamjperrin]

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

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

> Would anyone like to say something? > > …

[assimpleaspossi]

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

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

[irishcoffee]

A tool that is non-obvious in how to use it is a tool problem, not a user problem.

[atmosx]

Lack of docker support? Docker is available on macOS through emulation yes but bhyve is a thing… so why not? :-)

[assimpleaspossi]

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

[burner420042]

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.

[atmosx]

That’s very good to know. Thanks!

[HackerThemAll]

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).

[overfeed]

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.

[st3fan]

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.

[MisterTea]

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.

[znpy]

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.

[adiabatichottub]

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).

On FreeBSD I know its always going to work.

[akimbostrawman]

>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...

[grahamjperrin]

> … 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.

[adiabatichottub]

I was mainly referring to statements made by Linus Torvalds that got a lot of press. Canonical seems undeterred by any such arguments.

[evanjrowley]

>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.

[sidkshatriya]

you can use snapper + btrfs and the end result is like `bectl`. However it not as simple/integrated as ZFS Boot environments on FreeBSD

[krylon]

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.

[shrubble]

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

[krylon]

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.

[gzread]

> Then bcachefs came and ... appears to have gone nowhere AFAICT.

I heard the developer got sidetracked into writing himself an AI girlfriend. (Not sarcasm)

[PhilipRoman]

hah, you weren't joking... https://poc.bcachefs.org/ https://www.theregister.com/2026/02/25/bcachefs_creator_ai/

[koverstreet]

People love to imagine all sorts of salacious things.

[sidkshatriya]

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.

[HackerThemAll]

btrfs is pathetic when it comes to performance. So no, thanks.

https://www.phoronix.com/review/linux-70-filesystems

[sidkshatriya]

ZFS is worse than btrfs in performance.

Check out https://www.phoronix.com/review/linux-617-filesystems/5 "Geometric Mean of all test results". You will find that OpenZFS is ~35% slower than btrfs.

I love ZFS but I am aware about the performance it delivers.

[Numerlor]

Last I tried zfs was far far worse on reads arc couldn't satisfy, and all writes

[GuestFAUniverse]

In real world scenarios, where file based backups fail, one needs to add at least lvm.

And only than those benchmarks would be more interesting to me.

[liendolucas]

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.

BSDs in general are fantastic OSes.

[rootnod3]

Instead of the forums, report it also here https://bugs.freebsd.org/bugzilla/

[toast0]

> Is there anything FreeBSD can do that, say, Debian cannot? Probably not (at least I cannot think of anything).

Stability of user interface and documentation.

[throwaway27448]

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)

[toast0]

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/

[grahamjperrin]

> … Stable documentation allows time for it to be edited and revised to become better documentation,

https://news.ycombinator.com/item?id=47407895

Part of the problem is, too few committers. https://cgit.freebsd.org/doc/log/access?h=refs/internal/admi...

> as well as developing quality translations. …

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=267274

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284875#c8

For Russian, things are better: https://freshbsd.org/freebsd/doc?committer[]=Vladlen+Popolit... – see https://cgit.freebsd.org/doc/commit/access?h=refs/internal/a...

[gzread]

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.

[adiabatichottub]

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.

[grahamjperrin]

> … ZFS was a huge selling point, but I heard that it works quite well on Linux, these days. …

True.

I have OpenZFS-native encrypted root-on-ZFS for Kubuntu 25.10, made ultra-simple by the installer for Ubuntu (25.04 at the time).

FreeBSD can not yet do this. Please see, for example, https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263171

> 263171 – add loader(8) and boot loader menu support for boot with OpenZFS-encrypted ROOT

[whizzter]

My current home server passed 10 years in the autnum, but I've been running FreeBSD on servers since around 2000.

The main gripe is probably Docker and/or software depending on Linux-isms that can't be run natively without resorting to bhyve or smth alike that.

[BirAdam]

You could just use podman.

[whizzter]

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.

[frumplestlatz]

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.

[akdev1l]

I’m confused because can already do this on MacOS, Windows and Linux

Does `podman machine init` not work in FreeBSD? In those other platforms it will spin a small Linux VM to run containers on.

[krylon]

I have not thus far had anything to do with containers, so docker is unknown territory for me.

I run audiobookshelf in a Debian VM via bhyve, but I was gonna run a Debian VM anyway.

[jbverschoor]

Exactly the reason why I switched from FreeBSD to Debian, 25 years ago

[TacticalCoder]

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.

[endsandmeans]

> 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.

[atmosx]

> Is there anything FreeBSD can do that, say, Debian cannot?

Yes. Emulate traffic latency using IPFW and dummynet[^1]. There is no Linux (or OpenBSD, NetBSD) counterpart.

The ZFS implementation is less buggy.

[^1]: https://man.freebsd.org/cgi/man.cgi?dummynet

[c0balt]

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.

[0]: https://www.man7.org/linux/man-pages/man8/tc.8.html

[atmosx]

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.

[allreduce]

You can emulate latency, packet errors, etc using netem tc [0] on Linux.

[0]: https://man.archlinux.org/man/tc-netem.8.en

[favorited]

> The ZFS implementation is less buggy.

FreeBSD and Linux have been using the same implementation of ZFS for years.

[atmosx]

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.

[grahamjperrin]

> … 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.

[atmosx]

Historically yes, is it still today? I am not sure.

[gsich]

What I really want is the Windows tool for that. Can't call it equivalent, because clunsy is way superior.

https://jagt.github.io/clumsy/index.html

[jandrewrogers]

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.

[lproven]

> as powerful as Linux

Can you explain what you mean by that? Can you give some examples?

[jandrewrogers]

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.

[chillfox]

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.

[jmmv]

> 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?

[grahamjperrin]

> … I think I'd want to switch to pkgbase but that makes me nervous. …

There has been a disproportionate amount of negative noise from people who know too little about pkgbase.

pkgbase is a good thing. A very good thing. A huge game-changer, in terms of testing STABLE and CURRENT.

[sidkshatriya]

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 !

[jmmv]

To be honest I've never tried boot environments. I know they are a thing, and I have my whole setup on ZFS, so maybe that's the perfect use case.

[krylon]

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.

[pseudohadamard]

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.

[passthejoe]

Having ZFS baked into the installer and fully supported by the project is a huge motivator for using FreeBSD.

I know that Linux distros can accommodate ZFS, but it's a fair-weather situation due to licensing and most distros' preference for BTRFS.

[fluoridation]

Licensing is totally irrelevant for the end user. It just means you can't distribute the fully configured system.

[johng]

I think the main difference is that Linux simply has more hardware support than FreeBSD.

[jdefr89]

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

[antihero]

How is it at running something like microk8s? Also do you have to build your own binaries for anything not in the distro?

[debian3]

> Is there anything FreeBSD can do that, say, Debian cannot?

Docker containers is a big one.

[anthk]

Docker it's a solution for a big Linux problem. FreeBSD would just resort to compatNx libraries (to run older binaries) and/or a jail.

[righthand]

FreeBsd is Systemd free.

[TacticalCoder]

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).

[grahamjperrin]

> FreeBsd is Systemd free.

https://www.reddit.com/r/freebsd/comments/96pm7w/benno_rice_...

> Benno Rice: The Tragedy of systemd – BSDCan 2018 : r/freebsd

Don't be misled by the title. I thoroughly recommend listening to the whole thing.