Live data from Hacker News

Why I run FreeBSD for my home servers (2024)

aumont.fr

211–220 of 251 posts

Re: Why I run FreeBSD for my home servers (2024)

#211
post #163

Earlier quoted context omitted.

Sounds like maybe you were holding it wrong? This is year 20 for ZFS in production. Though Linux support a decade ago with ZFS was pretty rough around the edges. That's not true anymore for many distros of Linux.

I didn't run it. But several times a year there were multi-day outages for "rebuilds" and at one point Oracle consultants were involved to get it back on its feet.

If that's Oracle's ZFS then it's not really comparable, it's essentially a very old closed fork. So on top of using a languishing outdated version you have another reliability problem (Oracle). It's a little bit like comparing OracleDB to MariaDB.

Most people use Open ZFS which is from the Illumos project, which was basically the escape hatch that the engineers who wrote ZFS used when Oracle tried to close source Solaris after the Sun acquisition. There are decades of improvements in all of the OSS versions that comprise Illumos (which Oracle has denied themselves by attempting to close source it, since they cannot feed off of downstream OSS code). i.e most of the people who wrote ZFS immediately left Oracle and worked on Open ZFS.

Open ZFS is for both FreeBSD and Linux, and is what most people are referring to when discussing ZFS. I've never used Oracle ZFS and never will.

Re: Why I run FreeBSD for my home servers (2024)

#212
post #115
post #12

If systemd is the reason, there are several good distros without systemd (I run Void Linux in particular). If "kubesomething" is the reason, there's no requirement to use it. I think most people don't run it on their home servers. If containers are the reason, then again, they are not a requirement. But they are pretty similar to BSD's jails. I don't think they are particularly complex. FreeBSD has a number of strong…

To me arch linux is the middle ground between a too-much-complexity "fat" distribution like ubuntu or debian and a-minimal-but-eclectic-freebsd. the arch wiki is VERY comprehensive, linux has a huge community, and arch forced you to understand much just by stepping through the installation process.

I understand what you mean re: Arch wiki (I'm a fan of it even though not an arch user) but I genuinely suggest you go over and read some of the FreeBSD Handbook. Just look through the ToC (itself a nice thing) and pick something.

It is a cohesive whole which can be read from start to finish (it is an actual book). This is also how the whole system feels as well (as others have commented). Things are integrated and coherent. Example: freebsd has its own libc[0], and the kernel and libc do feel (from old experience) like a consistent unit, so to speak.

So IMO in terms of system cohesiveness (and its documentation which is a marvel unto itself but also represents the thing it covers), it's on a whole other level.

[not even using FreeBSD for any servers right now[1], but I have deep respect and admiration for the project and its team]

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

[0] that's the thing, as others have commented, Linux is really two parts (GNU+Linux) whereas e.g. FreeBSD is for most intents and purposes "one" internally cohesive part.

[1] though about to get a large old refurbished Dell server with 2xXeon for personal tinkering (you can find them cheap; beware of power usage tho...) and will likely set up FreeBSD as host, with ZFS, etc...

Re: Why I run FreeBSD for my home servers (2024)

#213
post #54

Earlier quoted context omitted.

> There were some very annoying teething issues with a lot of these components Currently, I don't have any issue at all, and I'm not aware of any either. I like how it's very reliable and integrated: the "kitchen sink mentality" can have positive effects > It didn't help that the systemd head (Lennart Poettering) was extremely intransigent with any complaints, often outright refusing to deal with various historical e…

> I like how it's very reliable and integrated: the "kitchen sink mentality" can have positive effects. Many people don't. When something more complex and integrated works it can seem perfectly fine. When something more complex and integrated fails, it often has more cascading effects that would otherwise be desired. > In retrospect, given how well it all works, maybe he was right to refuse to compromise. systemd's t…

You make very good points, but I think they come from a difference in expectations.

For time sync, what you do depends on what you need: there's a long list of option: rdate, sntp, ntp, ptp and I have used all of them.

Even if rdate is technically obsolete, for embedded systems it's sufficient that the time is not grossly wrong (and it's faster to write a rdate client and server)

However, when I'm doing high precision sampling data with multiple computers and I have to reorder the observations, sub microsecond accuracy is not enough: then I use PTP with a GPS and PPS (or chrony with special NICs if I can't get a GPS signal)

Both of these are very far from the normal needs of linux installs: there is no one size fits all, there are even interesting inbetween (chrony doing hardware timestamping with ntp is very clever) but when you design a system, you have to make choices.

> But now one is going to do it for dozens of services and not appreciate or handle the nuances that come with such a responsibility? It's literally pure arrogance - hence the hate.

I'm very happy systemd exists, because I like the well thought out design it has created: I can feel how it's lacking in the BSD.

I understand systemd success was not a given, and choices had to made. I just don't think it was arrogance, but compromises needed to achieve a vision.

> it's because they refuse to deal with more than one legit way of doing things. Either way, what is a service/process manager doing in this fight?

It's making choices.

Maybe systemd could have used ntp or better (maybe it will? or maybe there's a reason it's a bad idea?) but it does most things extremely well: if I have very specific needs (ex: ptp) far outside the norm, I can concentrate on that and let systemd do everything else far better than I would.

> these problems are because of long-established practices that technically violate an RFC

For DHCP, you should suggest an update, and if it gets adopted, a patch to make systemd follow the updated RFC.

That would show some love, and it might be better (and more productive) than the hate

Re: Why I run FreeBSD for my home servers (2024)

#214

Earlier quoted context omitted.

> without any of the "jank" you'd get running ZFS on Linux. What jank? Compile it in the kernel of load the module, install the zfs utils, then it's done. Very simple, no complications, where is the jank?

I certainly would qualify having to compile it for your kernel as jank.

It's not a different step to have to compile it for my kernel. I patch it in and after that it's a transparent part of compiling a kernel in total.

Re: Why I run FreeBSD for my home servers (2024)

#215

Earlier quoted context omitted.

> without any of the "jank" you'd get running ZFS on Linux. What jank? Compile it in the kernel of load the module, install the zfs utils, then it's done. Very simple, no complications, where is the jank?

Ostensibly DKMS can be interpreted as jank, for situations where you upgrade your kernel, zfs integration fails or blocks that, and now you are in limbo. At least, I can imagine this being a complaint from someone.

I can see that. I compile ZFS directly into the kernel so I've never really dealt with DKMS issues.

Re: Why I run FreeBSD for my home servers (2024)

#216
post #106

Earlier quoted context omitted.

Used ZFS on Debian in production for 8 years, yet to experience rough edges but always interested to learn.

I have never had a good experience with out of tree kernel modules on linux, so I am skeptical of this report. Usually for Linux Debian is my distro of choice.

I have little experience with kernel modules. ZFS is the only one I have long term experience with on Debian.

The only issue I've had with the kernel module aspect is VPS configuration, I use Linode and they used to automatically set everything to use the hypervisor kernel, but the kernel module is obviously built against the versions installed on your OS and these will probably be different.

All you have to do is make sure the boot configuration is set to use GRUB if using a VPS. Linode seem to have switched to this by default for Debian now.

Re: Why I run FreeBSD for my home servers (2024)

#217

Earlier quoted context omitted.

It is not sensible to base critical technical choices upon the whims of others.

It's not but it still happens. Network effects and social proof are powerful, even amongst Linux users who consider themselves "technical".

I don't get your point, at all. I tried.

Re: Why I run FreeBSD for my home servers (2024)

#218
post #12

If systemd is the reason, there are several good distros without systemd (I run Void Linux in particular). If "kubesomething" is the reason, there's no requirement to use it. I think most people don't run it on their home servers. If containers are the reason, then again, they are not a requirement. But they are pretty similar to BSD's jails. I don't think they are particularly complex. FreeBSD has a number of strong…

Linux has ZFS too. FreeBSD actually switched over to using the Linux implementation a few years ago.

It is more like the ZFS started supporting Linux, not FreeBSD uses Linux implementation.

Re: Why I run FreeBSD for my home servers (2024)

#219
post #211

Earlier quoted context omitted.

I didn't run it. But several times a year there were multi-day outages for "rebuilds" and at one point Oracle consultants were involved to get it back on its feet.

If that's Oracle's ZFS then it's not really comparable, it's essentially a very old closed fork. So on top of using a languishing outdated version you have another reliability problem (Oracle). It's a little bit like comparing OracleDB to MariaDB. Most people use Open ZFS which is from the Illumos project, which was basically the escape hatch that the engineers who wrote ZFS used when Oracle tried to close source Sol…

Agreed on the larger picture. Oracle ZFS is calcified ZFS. Their last stable release it looks like was in January of 2023.

OpenZFS released 2.3.1 a few weeks ago: https://github.com/openzfs/zfs/releases It has direct support for FreeBSD and Linux.

macOS, Windows and other ports work great, but are not (yet) upstream: https://openzfs.org/wiki/Distributions

Re: Why I run FreeBSD for my home servers (2024)

#220

Earlier quoted context omitted.

> actual man pages What is wrong with Linux man pages?

Let's start with: there is no such thing as "Linux" man pages. There's https://docs.kernel.org > but that only concerns the kernel itself. How does a particular distribution handle its man pages is up to that distribution. You can browse what is generally considered to be the "standard" set of man pages online: https://man7.org/linux/man-pages/ > or https://linux.die.net/man/ >, but this is a third-party community ef…

> Let's start with: there is no such thing as "Linux" man pages. There's https://docs.kernel.org> but that only concerns the kernel itself.

Actually, there is.

https://web.git.kernel.org/pub/scm/docs/man-pages/man-pages....

It's included with many default distro installs.

Post reply on HN