Why I run FreeBSD for my home servers (2024)(aumont.fr)
aumont.fr
Why I run FreeBSD for my home servers (2024)
https://aumont.fr/posts/FreeBSD-Home-Server/
250 comments
> But the usual Linux hobgoblins listed above are a red herring here, to my mind.
Absolutely
> 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.
The only point I agree with the author is that many things are shipped to be used with docker when they don't need to be, which creates a needless dependency.
Absolutely
> 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.
The only point I agree with the author is that many things are shipped to be used with docker when they don't need to be, which creates a needless dependency.
I have "reversed engineered" dockerfiles in order to avoid containers. Any software should be installable without docker, it just takes more knowledge and time. Also sometimes it doesn't, there is a binary (like with go and rust and .net) or other times the long route is pip or apt and some conf fiddling. Databases are the worse part maybe but once you get it is more control for you and what you want to do with your setup. Moving database server to other dir o server? no prob.
Sometimes dockerfile deploys postgresql when you can configure it for home a simple sqlite.
If you end up modifying the dockerfile you understand what are the application requirements are and you can install raw.
Well, containers have some other uses cases. Running old software not supported by latest Linux distros is one of them. MySQL 5.7 series cannot be installed on latest Linuxes cleanly for quite a while now. Containers are godsend for situations like this.
that is absolutely fascinating. why do you want to avoid containers?
I'm not the parent poster, but I also like to avoid containers when I can. For instance, if there is a bug in some library or common dependency (think libssl or bash) it's easy to update it in one place rather then make sure a whole bunch of containers get updated. Also, when writing software I find that targeting a container keeps you from thinking about portability (by intrinsically avoiding the "it works on my machine" problem) and results in a more fragile end product.
If you aren't getting the binary from your repo's package manager the "update in one place for bugfixes" thing often no longer applies. At least with a container management system the various not-distro-managed things have something akin to a standard way to version bump them vs "go download this from that ftp, go pull this from that repo, etc."
As someone who does use containers: It depends™ on how you do things, but lots of containers are used as a way to consume mystery meat easily. Who made that image? What's in it? Do you trust the binaries in it? How often does it get updates? Are you keeping up with updates that are available? All of these are solvable, of course, but a lot of containers are "just docker run randomsource/whatever:latest and never think about it again".
Most straitforward reason is not having multiple database server and reuse one Pgsql or Mariadb for several instances of same app.
One reason could be bringing in auto-upgradable dependencies: much less to rebuild when a security patch release is issued.
This is doable with containers, too, if you agree to maintain and build them yourself.
This is doable with containers, too, if you agree to maintain and build them yourself.
I used to run FreeBSD on my home server and switched it over to Alpine Linux (with ZFS) because everything I wanted to run came as a docker containers and it was just easier to use docker compose to manage all the apps.
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.
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.
FreeBSD and ArchLinux do not need to be compared in this context.
FreeBSD is an extremely simple and stable system. All packages/ports for which are tailored to integrate well with the networking stack, logging etc of FreeBSD. FreeBSD has daily/weekly/monthly cronjobs per default that runs a number of cleanup tasks and security updates and emails the result. It also has email setup correctly per default.
And FreeBSD only gets a few patch updates a year and a new major release every two years. The security patches it will download for you and then inform you over email.
ArchLinux needs constant maintenance to be updated, often requiring manual intervention. The packages are unchanged from upstream and thus do not integrate that well will the system at all, often requiring much more configuration. ArchLinux can be run as a server, and I have an do for years now, but it isn't made for it and it does require attention. ArchLinux is about getting bleeding edge software packaged as-is from upstream, and it's about allowing the user to tinker and customize. In that sense FreeBSD and ArchLinux can be considered opposites.
FreeBSD is an extremely simple and stable system. All packages/ports for which are tailored to integrate well with the networking stack, logging etc of FreeBSD. FreeBSD has daily/weekly/monthly cronjobs per default that runs a number of cleanup tasks and security updates and emails the result. It also has email setup correctly per default.
And FreeBSD only gets a few patch updates a year and a new major release every two years. The security patches it will download for you and then inform you over email.
ArchLinux needs constant maintenance to be updated, often requiring manual intervention. The packages are unchanged from upstream and thus do not integrate that well will the system at all, often requiring much more configuration. ArchLinux can be run as a server, and I have an do for years now, but it isn't made for it and it does require attention. ArchLinux is about getting bleeding edge software packaged as-is from upstream, and it's about allowing the user to tinker and customize. In that sense FreeBSD and ArchLinux can be considered opposites.
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...
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...
Debian is fat?? I always thought it was a nice, minimalist server distro.
You should try either reading through the installation instruction, or better yet try an install:
https://wiki.archlinux.org/title/Installation_guide
https://wiki.archlinux.org/title/Installation_guide
arch (or any rolling release) on a home server doesn't sound like a good idea?
if you actually run updates regularly (which you should anyways) it's fine. I did it for years until I switched to NixOS.
yeah, this was my main annoyance with it, i don't log into my server for months at a time so i wanted something without constant updates but other than that it was fine.
I know at least one other person who runs Arch on all their servers, they do an update monthly unless there's some critical CVE that needs to be addressed ASAP. The sibling comment says 1 year, but I can't honestly suggest going that long for any distro. I've had Ubuntu LTS break very, very badly because of a missed patch in GRUB when updating over too long of a timescale (somewhere around a year, maybe a bit less)
I update one of my servers once a year or even longer, and it’s still doing fine with Arch.
[deleted]
Pacman has always been kind to me. Portage, on the other hand, crippled my beloved X60 after a full system upgrade even though I was only a few weeks behind. I don't recall the precise issue but if memory serves it was some sort of circular version dependency that I was unable to resolve. I was a 19-year-old l00nix nublet so I'm sure it was my fault but I've never had so much trouble with a distro package manager as I did with Gentoo's.
Once you try a rolling-release distro you realize it's actually a very good idea
It's not though, few server usecases allow/require your environment to change every day.
OpenSUSE Tumbleweed is a lot more stable than ArchLinux for that kind of stuff though. It stages updates in tested snapshots. ArchLinux updates just error if you time them right.
OpenSUSE Tumbleweed is a lot more stable than ArchLinux for that kind of stuff though. It stages updates in tested snapshots. ArchLinux updates just error if you time them right.
Anecdotal, but I never had an Arch install fail after updating (maybe the one time my EFI partition was full, but not specific to Arch). While I have a laptop running OpenSUSE Tumbleweed that failed to start after the third update I did on it.
> While I have a laptop running OpenSUSE Tumbleweed that failed to start after the third update
Very possible, Tumbleweed has had some embarrassing failures.
But when it comes to rolling release on servers I'd still prefer OpenSUSE.
OpenSUSE has whole distributions (MicroOS & Aeon) dedicated to performing automatic updates. ArchLinux is not really made with automatic updates in mind.
Big part of that is possible because OpenSUSE releases Tumbleweed in "snapshots". This means that updated packages are basically staged and tested together before release. This happens a few times a week. If you then experience a failure you can always use an older tumbleweed snapshot. In theory that should provide more stability, but there has recently been a lot of instability especially with SELinux being enabled by default.
Very possible, Tumbleweed has had some embarrassing failures.
But when it comes to rolling release on servers I'd still prefer OpenSUSE.
OpenSUSE has whole distributions (MicroOS & Aeon) dedicated to performing automatic updates. ArchLinux is not really made with automatic updates in mind.
Big part of that is possible because OpenSUSE releases Tumbleweed in "snapshots". This means that updated packages are basically staged and tested together before release. This happens a few times a week. If you then experience a failure you can always use an older tumbleweed snapshot. In theory that should provide more stability, but there has recently been a lot of instability especially with SELinux being enabled by default.
[deleted]
> If systemd is the reason, there are several good distros without systemd
I totally get avoiding systemd, I don't myself, but I get it. The author on the other hand talks about the problems doing this in a professional setting. This I do not get. As far as management of large fleets of servers goes, systemd is quite nice. Yeah, it's odd for some things but as far as automation is concerned it's the way to go.
With systemd the same file syntax and management works for services, timers, mount points, networking, name resolution, lightweight containers, virtual machines. You literally have to write one parser and serialize to ini. Then you get distribution generic management. Upgrades? No problem? Moving to CentOS to Debian? Ubuntu? arch? Whatever? No problem. It. Just. Works.
Yeah, if you're in the know you can do better for specific circumstances, but in this day and age OS's are throw away and automation you don't have to refactor is paramount. For professional work, this flame war is over.
I totally get avoiding systemd, I don't myself, but I get it. The author on the other hand talks about the problems doing this in a professional setting. This I do not get. As far as management of large fleets of servers goes, systemd is quite nice. Yeah, it's odd for some things but as far as automation is concerned it's the way to go.
With systemd the same file syntax and management works for services, timers, mount points, networking, name resolution, lightweight containers, virtual machines. You literally have to write one parser and serialize to ini. Then you get distribution generic management. Upgrades? No problem? Moving to CentOS to Debian? Ubuntu? arch? Whatever? No problem. It. Just. Works.
Yeah, if you're in the know you can do better for specific circumstances, but in this day and age OS's are throw away and automation you don't have to refactor is paramount. For professional work, this flame war is over.
>With systemd the same file syntax and management works for services, timers, mount points, networking, name resolution, lightweight containers, virtual machines. You literally have to write one parser and serialize to ini.
There is no "syntax", it's all just key=value pairs, and all the subsystems have their own set of keys/directives, and the values have their own mini-DSLs. Things that end in "Sec" (for "seconds") take duration labels. The only directives that are shared is the inter-unit dependency directives. Some keys/directives can be specified multiple times.
I don't know why you'd be parsing unit files or serializing something else to unit files. Just drop them into place. The hard part is knowing all the details of how the directives interact and what their values can be.
There is no "syntax", it's all just key=value pairs, and all the subsystems have their own set of keys/directives, and the values have their own mini-DSLs. Things that end in "Sec" (for "seconds") take duration labels. The only directives that are shared is the inter-unit dependency directives. Some keys/directives can be specified multiple times.
I don't know why you'd be parsing unit files or serializing something else to unit files. Just drop them into place. The hard part is knowing all the details of how the directives interact and what their values can be.
> There is no "syntax", it's all just key=value pairs,
This, with the sections, is INI. Duplicate keys included. Loosely defined spec, but INI none the less
> I don't know why you'd be parsing unit files or serializing something else to unit files. Just drop them into place
It's common to store information in a DB, or some other format that is easy to merge/override programmatically. Even configuration management tools like puppet, salt, ansible do this with JSON/YAML
This, with the sections, is INI. Duplicate keys included. Loosely defined spec, but INI none the less
> I don't know why you'd be parsing unit files or serializing something else to unit files. Just drop them into place
It's common to store information in a DB, or some other format that is easy to merge/override programmatically. Even configuration management tools like puppet, salt, ansible do this with JSON/YAML
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.
>The switch to [ZFS on Linux] as upstream
https://papers.freebsd.org/2019/eurobsdcon/jude-the_future_o...
https://papers.freebsd.org/2019/eurobsdcon/jude-the_future_o...
Oh I missed remember OpenZFS started on FreeBSD. Thank you for the correction.
> If systemd is the reason, there are several good distros without systemd (I run Void Linux in particular).
There are people in the FreeBSD camp that actually do advocate for something like systemd in FreeBSD. See "The Tragedy of systemd": https://www.youtube.com/watch?v=o_AIw9bGogo
There are people in the FreeBSD camp that actually do advocate for something like systemd in FreeBSD. See "The Tragedy of systemd": https://www.youtube.com/watch?v=o_AIw9bGogo
Something like systemd might be useful. There are some aspects of systemd that make sense and are useful.
There's other stuff like eliminating boot interactivity, so you can't hit ctrl-c or any other keys to cancel waiting for dhcp on network ports that aren't plugged in, that really bother me.
I also don't think a FreeBSD init/system supervision system would go and re-implement dns, ntp, and whatever else, including redoing security mistakes from decades ago.
There's other stuff like eliminating boot interactivity, so you can't hit ctrl-c or any other keys to cancel waiting for dhcp on network ports that aren't plugged in, that really bother me.
I also don't think a FreeBSD init/system supervision system would go and re-implement dns, ntp, and whatever else, including redoing security mistakes from decades ago.
Is there a text version of that?
no, but here's the sum up: "systemd is actually good, the current init system in freebsd is severely lacking under many aspects, systemd is more of a system manager rather than just an init system, that's actually a good thing and actually we'd need something like systemd in freebsd".
I use FreeBSD for my home server and I have for years. For me, the biggest reason is just the stability from a user perspective. I don't mean system stability, although it has been rock solid, I mean the stability in terms of administration - the tools don't change frequently.
`ifconfig` just works, like it has worked for 20 years. On my linux servers, it's all swallowed into `ip addr` now. I don't mind that, I certainly understand why these things change, but when I update an Ubuntu server I always worry that next time I log in a tool I am used to will be broken or removed.
I simply don't have those concerns on FreeBSD.
`ifconfig` just works, like it has worked for 20 years. On my linux servers, it's all swallowed into `ip addr` now. I don't mind that, I certainly understand why these things change, but when I update an Ubuntu server I always worry that next time I log in a tool I am used to will be broken or removed.
I simply don't have those concerns on FreeBSD.
This is one of the reasons I run FreeBSD as well, I wanted to get away from the ever-changing Docker, docker-compose, docker compose and all that stuff.
The jail system has it's warts and at times can seem a little unpolished, but alt least I know that the workarounds and automation I have set up for my home server is mostly "done".
The jail system has it's warts and at times can seem a little unpolished, but alt least I know that the workarounds and automation I have set up for my home server is mostly "done".
Linux still has ifconfig, it doesn't support all the new features but maybe this use case doesn't need them.
(Also the "ip" command from iproute2 came around in the last millenium, no?)
(Also the "ip" command from iproute2 came around in the last millenium, no?)
It "still has" ifconfig in the sense that you can install the 'net-tools' package which contains it and then use it, yes. However ifconfig is not included in base ubuntu installs and hasn't been since 18.04. It's marked as deprecated now.
There isn't anything specific that ifconfig can do that "ip" doesn't -- except I have 20 years of muscle memory for ifconfig and zero for "ip". That's my frustration. When I'm at home, just trying to set up Plex or debug a networking issue, and all I need to do is get my current IP address, the last thing I want to do is spend time learning a new interface that isn't necessary.
Again, this isn't really a complaint about the tools - I'm sure that "ip" is great and has more features and etc. But hosting on Linux feels like this about everything. Logs, services, networking, user configuration - the management tools for all these things have been changing quite fast, and in ways that can be hard to follow.
I'm not on the Kernel or Debian mailing lists and I don't think I should need to be to understand how to configure the network on ubuntu 20.04 vs 18.04. When I need to look up user management on BSD, I just look at the handbook. It's up-to-date and informative. Meanwhile in the Linux world these things change so fast that wiki articles from 2 years ago are often useless.
There isn't anything specific that ifconfig can do that "ip" doesn't -- except I have 20 years of muscle memory for ifconfig and zero for "ip". That's my frustration. When I'm at home, just trying to set up Plex or debug a networking issue, and all I need to do is get my current IP address, the last thing I want to do is spend time learning a new interface that isn't necessary.
Again, this isn't really a complaint about the tools - I'm sure that "ip" is great and has more features and etc. But hosting on Linux feels like this about everything. Logs, services, networking, user configuration - the management tools for all these things have been changing quite fast, and in ways that can be hard to follow.
I'm not on the Kernel or Debian mailing lists and I don't think I should need to be to understand how to configure the network on ubuntu 20.04 vs 18.04. When I need to look up user management on BSD, I just look at the handbook. It's up-to-date and informative. Meanwhile in the Linux world these things change so fast that wiki articles from 2 years ago are often useless.
> like it has worked for 20 years
.. almost forty years
.. almost forty years
man you're making me feel old. those kids on my lawn are pissing me off tho...
The main complain of the author seems to be that linux use systemd.
In my experience, systemd is far better and more reliable than anything else, especially if you need complex logic (ex: when this and that happen, start doing this, except when such and such are present)
Most of the problems I've seen come from trying to duplicate systemd functions: in the author example, why bother with rsyslog or network-manager?
I have also seen many people refusing to learn modern tools, instead trying to make it work with the tools they know, by disabling what works better, often with poor results.
It's like trying to keep using ifconfig and route instead of ip: you can make it work, but for say managing multiple ip on the same interface forces you to go with eth0:0 eth0:1 etc (and let's not even talk about network namespaces).
I like the various BSD and distributions like postmarket OS, but I wish they had access to modern tools instead of having to "roll my own" with scripts or make do with what they depend on
In my experience, systemd is far better and more reliable than anything else, especially if you need complex logic (ex: when this and that happen, start doing this, except when such and such are present)
Most of the problems I've seen come from trying to duplicate systemd functions: in the author example, why bother with rsyslog or network-manager?
I have also seen many people refusing to learn modern tools, instead trying to make it work with the tools they know, by disabling what works better, often with poor results.
It's like trying to keep using ifconfig and route instead of ip: you can make it work, but for say managing multiple ip on the same interface forces you to go with eth0:0 eth0:1 etc (and let's not even talk about network namespaces).
I like the various BSD and distributions like postmarket OS, but I wish they had access to modern tools instead of having to "roll my own" with scripts or make do with what they depend on
99% of my issues with systemd are that it is a kitchen sink mentality. If it just dealt with process and service management, it'd mostly be minor quibbles - it was time to replace init with something.
But instead it also does NTP, DHCP/networking, logging, etc. There were some very annoying teething issues with a lot of these components. It became more difficult to isolate problems buried within the systemd stack. It also became a pain to do some common, basic tasks. When the first distros starting supporting it, getting the systemd/journald logs for all the services into a central logging service was extremely painful. With (r)syslog it is just one line in a config. Heck, even the config files for systemd are littered all over the place.
It didn't help that the systemd head (Lennart Poettering) was extremely intransigent with any complaints, often outright refusing to deal with various historical edge cases for long-established norms.
And yes, by doing all this it the broke the long-held UNIX philosophy of "do one thing really well" and that continues to ruffle a lot of feathers. I've mainly accepted the fact that it won out, but it's helped by the fact that I'm now mostly using it to start a docker orchestrator and that all the networking is now handled by cloud-computing resources.
But instead it also does NTP, DHCP/networking, logging, etc. There were some very annoying teething issues with a lot of these components. It became more difficult to isolate problems buried within the systemd stack. It also became a pain to do some common, basic tasks. When the first distros starting supporting it, getting the systemd/journald logs for all the services into a central logging service was extremely painful. With (r)syslog it is just one line in a config. Heck, even the config files for systemd are littered all over the place.
It didn't help that the systemd head (Lennart Poettering) was extremely intransigent with any complaints, often outright refusing to deal with various historical edge cases for long-established norms.
And yes, by doing all this it the broke the long-held UNIX philosophy of "do one thing really well" and that continues to ruffle a lot of feathers. I've mainly accepted the fact that it won out, but it's helped by the fact that I'm now mostly using it to start a docker orchestrator and that all the networking is now handled by cloud-computing resources.
> 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 edge cases for long-established norms.
In retrospect, given how well it all works, maybe he was right to refuse to compromise.
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 edge cases for long-established norms.
In retrospect, given how well it all works, maybe he was right to refuse to compromise.
> 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 timesyncd is less accurate than ntpd and is terrible at dealing with drift; it is mostly only suitable for desktop timesyncing. As soon as you need to deal with synchronous timing with multiple machines, it's usually the number one problem. Even worse is that it doesn't tend to use less memory or cpu than alternatives.
systemd's DHCP client continues to be a nightmare for people using it with many ISPs or corporate networks due to the creators deciding to only handle one format of optional headers (in particular option 43, but also many others) resulting in networking issues in many situations. These issues are long-historical and can even be due to ancient endian issues. Every other DHCP client implementation deals with this - except systemd's. I have to cleanup my ec2 instances because systemd's dhcp client adds 032 instead of a space to resolv.conf's search field because we have more than one domain there.
In some cases these problems are because of long-established practices that technically violate an RFC. In others 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?
When you replace something that's been around for decades (init), you're going to ruffle feathers for good and bad reasons. It's had decades of maturity. 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.
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 timesyncd is less accurate than ntpd and is terrible at dealing with drift; it is mostly only suitable for desktop timesyncing. As soon as you need to deal with synchronous timing with multiple machines, it's usually the number one problem. Even worse is that it doesn't tend to use less memory or cpu than alternatives.
systemd's DHCP client continues to be a nightmare for people using it with many ISPs or corporate networks due to the creators deciding to only handle one format of optional headers (in particular option 43, but also many others) resulting in networking issues in many situations. These issues are long-historical and can even be due to ancient endian issues. Every other DHCP client implementation deals with this - except systemd's. I have to cleanup my ec2 instances because systemd's dhcp client adds 032 instead of a space to resolv.conf's search field because we have more than one domain there.
In some cases these problems are because of long-established practices that technically violate an RFC. In others 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?
When you replace something that's been around for decades (init), you're going to ruffle feathers for good and bad reasons. It's had decades of maturity. 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.
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
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
> 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 time-stamping with ntp is very clever) but when you design a system, you have to make choices.
There were choices/options, some of which have existed for decades. Instead of replacing them, systemd could have provided optional or mandatory services (eg time, dhcp, etc) that could be passed into systemd. "NTP is enabled and provides time, so it gets started at this point in the dependency tree"...or "NTP with priority 1, chrony with priority 2 provide time, start NTP and if it fails, switch to chrony". This also means that systemd could lag if successor protocols for time syncing, etc take off.
Millisecond or less time syncing is not outside the norm for distributed tracing or other server-side tech stacks, especially if there's lots of traffic. I've been lucky in that AWS's modern underlying hardware seems to keep clock pretty well, meaning I've not had to personally fight with it (that and ubuntu already defaulted to chrony, doing the override work for me.), but I do know people doing on-prem kubernetes loads that have had to...
Swinging back to networking, the tight integration with systemd makes (made? I am only now starting to plan the upgrade of our ubuntu 20.04 fleet to 24.04, so maybe it is better now...) disabling components a huge pain in the ass. My initial fights with systemd's dependency management meant that disabling its internal DHCP had several cascading consequences with other things that expected networking to be "up". This is to say nothing of the tooling that expects a full-slate of systemd services.
> For DHCP, you should suggest an update, and if it gets adopted, a patch to make systemd follow the updated RFC.
It's not mainly an issue with strict adherence to RFCs. There's quite bluntly real-world usage and industry norms.
Firstly RFCs can be vague and unclear. IPSEC is a notorious example in that vendors treat the IP restriction headers differently because the spec is nebulous to how precisely it should work (some call it a proxy-id or proxy-header, others subnet range, etc). Due to a variety of reasons that can be summed up as the consequences of committee driven design, a lot of the spec was defined with great "flexibility" in mind. Some vendors will not bring up the tunnel unless both ends agree on the ranges exactly. Others will happily bring up the tunnel, but only allow traffic that overlaps within the local restrictions. Even more infuriatingly, some vendors (cisco in particular) tie it to the firewall rules, which could include other non-vpn traffic. Some (like checkpoint) dynamically supernet the configured entries. The result is every person who's setup IPSEC VPN tunnels with third parties maintains a "quirks" record to understand how best to bring up tunnels between vendors (eg juniper srx to cisco ASA, juniper srx to palo alto, etc). You just cannot be stubborn here. You need to work with the way the real world works.
Secondly, there can be competing standards or necessary migration paths between them. I'm not sure what the IPv6 status is on systemd so this is only an example, but IPv6's autoconfiguration didn't initially include DNS and other optionally useful fields, meaning DHCPv6 was a thing. This is now mostly deprecated by SLAAC, but DHCPv6 deployments will be needed for awhile as it's all that windows' IPv6 implementation supported until recently. You can't just say "RFC now supports SLAAC...don't whine to me that DHCPv6 doesn't work as it's not part of the RFC".
> That would show some love, and it might be better (and more productive) than the hate
People have tried, but the response can be TL;DR'd to "works on my machine/setup" or to go harass AWS, Microsoft (via AD), etc to make things work the way the systemd mainainers think is right. There's a reason Lennart Poettering has a "difficult" reputation.
There were choices/options, some of which have existed for decades. Instead of replacing them, systemd could have provided optional or mandatory services (eg time, dhcp, etc) that could be passed into systemd. "NTP is enabled and provides time, so it gets started at this point in the dependency tree"...or "NTP with priority 1, chrony with priority 2 provide time, start NTP and if it fails, switch to chrony". This also means that systemd could lag if successor protocols for time syncing, etc take off.
Millisecond or less time syncing is not outside the norm for distributed tracing or other server-side tech stacks, especially if there's lots of traffic. I've been lucky in that AWS's modern underlying hardware seems to keep clock pretty well, meaning I've not had to personally fight with it (that and ubuntu already defaulted to chrony, doing the override work for me.), but I do know people doing on-prem kubernetes loads that have had to...
Swinging back to networking, the tight integration with systemd makes (made? I am only now starting to plan the upgrade of our ubuntu 20.04 fleet to 24.04, so maybe it is better now...) disabling components a huge pain in the ass. My initial fights with systemd's dependency management meant that disabling its internal DHCP had several cascading consequences with other things that expected networking to be "up". This is to say nothing of the tooling that expects a full-slate of systemd services.
> For DHCP, you should suggest an update, and if it gets adopted, a patch to make systemd follow the updated RFC.
It's not mainly an issue with strict adherence to RFCs. There's quite bluntly real-world usage and industry norms.
Firstly RFCs can be vague and unclear. IPSEC is a notorious example in that vendors treat the IP restriction headers differently because the spec is nebulous to how precisely it should work (some call it a proxy-id or proxy-header, others subnet range, etc). Due to a variety of reasons that can be summed up as the consequences of committee driven design, a lot of the spec was defined with great "flexibility" in mind. Some vendors will not bring up the tunnel unless both ends agree on the ranges exactly. Others will happily bring up the tunnel, but only allow traffic that overlaps within the local restrictions. Even more infuriatingly, some vendors (cisco in particular) tie it to the firewall rules, which could include other non-vpn traffic. Some (like checkpoint) dynamically supernet the configured entries. The result is every person who's setup IPSEC VPN tunnels with third parties maintains a "quirks" record to understand how best to bring up tunnels between vendors (eg juniper srx to cisco ASA, juniper srx to palo alto, etc). You just cannot be stubborn here. You need to work with the way the real world works.
Secondly, there can be competing standards or necessary migration paths between them. I'm not sure what the IPv6 status is on systemd so this is only an example, but IPv6's autoconfiguration didn't initially include DNS and other optionally useful fields, meaning DHCPv6 was a thing. This is now mostly deprecated by SLAAC, but DHCPv6 deployments will be needed for awhile as it's all that windows' IPv6 implementation supported until recently. You can't just say "RFC now supports SLAAC...don't whine to me that DHCPv6 doesn't work as it's not part of the RFC".
> That would show some love, and it might be better (and more productive) than the hate
People have tried, but the response can be TL;DR'd to "works on my machine/setup" or to go harass AWS, Microsoft (via AD), etc to make things work the way the systemd mainainers think is right. There's a reason Lennart Poettering has a "difficult" reputation.
> Instead of replacing them, systemd could have provided optional or mandatory services (eg time, dhcp, etc) that could be passed into systemd
If sntp is not sufficient for your needs, just disable systemd own sntp solution (systemctl disable...) and use chrony (systemctl start / systemctl enable to make it persistent): then `systemctl status systemd-timesyncd.service` will show you it has been disabled
> but I do know people doing on-prem kubernetes loads that have had to...
What did they have to do? `systemctl disable systemd-timesyncd` is not very complicated. If they want to create a service, they can have it disable timesyncd iff chrony has started successfully (in an ExecStartPost), or doing a logic chain.
It's extremely practical: you can create very precise logic chains with systemd (if this and that, then...)
> My initial fights with systemd's dependency management meant that disabling its internal DHCP had several cascading consequences with other things that expected networking to be "up". This is to say nothing of the tooling that expects a full-slate of systemd services.
Maybe I can help you with that - I used to run a non systemd DHCP when I needed a rapid DHCP to reduce the TTFB for a specific configuration (read https://news.ycombinator.com/item?id=2755461 if you are not familiar with rapid DHCP)
It did not require much effort, just "inserting" my own service in the dependency chain.
Create a /etc/systemd/system/[email protected] with : (put the right option for your dhcp in execstart)
```
[Unit]
Description=dhcpcd on %I
Wants=network.target
Before=network.target
BindsTo=sys-subsystem-net-devices-%i.device
After=sys-subsystem-net-devices-%i.device
[Service]
Type=forking
ExecStart=/usr/bin/dhcpcd -q -w %I
ExecStop=/usr/bin/dhcpcd -x %I
ExecStop=/usr/sbin/ip addr flush dev %I
[Install]
WantedBy=multi-user.target
```
Using the @ syntax, you can create a dhcp just for the one interface you care about: then use systemctl daemon-reload, and start your custom service as my-dhcpd@eth1 : the %i will be replaced by eth1
If you are interested in rapid dhcp, I give more details on https://www.reddit.com/r/archlinux/comments/1392wrc/dhcpcd_1...
> I am only now starting to plan the upgrade of our ubuntu 20.04 fleet to 24.04, so maybe it is better now...
It shouldn't be very hard to fix, I had a similar setup working with a 18.04 and a 20.04
> My initial fights with systemd's dependency management meant that disabling its internal DHCP had several cascading consequences with other things that expected networking to be "up". This is to say nothing of the tooling that expects a full-slate of systemd services.
You need to insert yourself in the dependencies, but the example I gave above should be sufficient to do that
> This is now mostly deprecated by SLAAC, but DHCPv6 deployments will be needed for awhile as it's all that windows' IPv6 implementation supported until recently. You can't just say "RFC now supports SLAAC...don't whine to me that DHCPv6 doesn't work as it's not part of the RFC".
I have maintained such solutions and I had both SLAAC and DHCPv6: giving multiple IPv6 to an host is fine. On linux side, you can even use preferred_lft to change the priority (ex: use 0 to have an IPv6 address that will reply to connections, but that will not be used to initiate connections, for example if you don't want to expose "easy to remember" short addresses like yourprefix:subnet::1
In case you don't know, systemd-networkd IPv6AcceptRA is a separate option (and section) from DHCPv4 and DHCPv6 - you could decide to use either or both, and also do more advanced routing with RouteMetric to prefer one over the other if you have different gateways for redundancy
If what I've explained is not clear, try to read https://wiki.archlinux.org/title/Systemd-networkd it's a good starting guide.
If you have more advanced IPv6 needs, it's usually to request a /56: use PrefixDelegationHint
You can then chunk it out with systemd: check https://major.io/p/dhcpv6-prefix-delegation-with-systemd-net... for a nice guide
> People have tried, but the response can be TL;DR'd to "works on my machine/setup" or to go harass AWS, Microsoft (via AD), etc to make things work the way the systemd mainainers think is right.
Everything we talked about doesn't seem very complicated.
If with all the pointers I've provided you still can't make it work, or if you run into more complicated problems, send an email (username at outlook), I will see what I can do.
If sntp is not sufficient for your needs, just disable systemd own sntp solution (systemctl disable...) and use chrony (systemctl start / systemctl enable to make it persistent): then `systemctl status systemd-timesyncd.service` will show you it has been disabled
> but I do know people doing on-prem kubernetes loads that have had to...
What did they have to do? `systemctl disable systemd-timesyncd` is not very complicated. If they want to create a service, they can have it disable timesyncd iff chrony has started successfully (in an ExecStartPost), or doing a logic chain.
It's extremely practical: you can create very precise logic chains with systemd (if this and that, then...)
> My initial fights with systemd's dependency management meant that disabling its internal DHCP had several cascading consequences with other things that expected networking to be "up". This is to say nothing of the tooling that expects a full-slate of systemd services.
Maybe I can help you with that - I used to run a non systemd DHCP when I needed a rapid DHCP to reduce the TTFB for a specific configuration (read https://news.ycombinator.com/item?id=2755461 if you are not familiar with rapid DHCP)
It did not require much effort, just "inserting" my own service in the dependency chain.
Create a /etc/systemd/system/[email protected] with : (put the right option for your dhcp in execstart)
```
[Unit]
Description=dhcpcd on %I
Wants=network.target
Before=network.target
BindsTo=sys-subsystem-net-devices-%i.device
After=sys-subsystem-net-devices-%i.device
[Service]
Type=forking
ExecStart=/usr/bin/dhcpcd -q -w %I
ExecStop=/usr/bin/dhcpcd -x %I
ExecStop=/usr/sbin/ip addr flush dev %I
[Install]
WantedBy=multi-user.target
```
Using the @ syntax, you can create a dhcp just for the one interface you care about: then use systemctl daemon-reload, and start your custom service as my-dhcpd@eth1 : the %i will be replaced by eth1
If you are interested in rapid dhcp, I give more details on https://www.reddit.com/r/archlinux/comments/1392wrc/dhcpcd_1...
> I am only now starting to plan the upgrade of our ubuntu 20.04 fleet to 24.04, so maybe it is better now...
It shouldn't be very hard to fix, I had a similar setup working with a 18.04 and a 20.04
> My initial fights with systemd's dependency management meant that disabling its internal DHCP had several cascading consequences with other things that expected networking to be "up". This is to say nothing of the tooling that expects a full-slate of systemd services.
You need to insert yourself in the dependencies, but the example I gave above should be sufficient to do that
> This is now mostly deprecated by SLAAC, but DHCPv6 deployments will be needed for awhile as it's all that windows' IPv6 implementation supported until recently. You can't just say "RFC now supports SLAAC...don't whine to me that DHCPv6 doesn't work as it's not part of the RFC".
I have maintained such solutions and I had both SLAAC and DHCPv6: giving multiple IPv6 to an host is fine. On linux side, you can even use preferred_lft to change the priority (ex: use 0 to have an IPv6 address that will reply to connections, but that will not be used to initiate connections, for example if you don't want to expose "easy to remember" short addresses like yourprefix:subnet::1
In case you don't know, systemd-networkd IPv6AcceptRA is a separate option (and section) from DHCPv4 and DHCPv6 - you could decide to use either or both, and also do more advanced routing with RouteMetric to prefer one over the other if you have different gateways for redundancy
If what I've explained is not clear, try to read https://wiki.archlinux.org/title/Systemd-networkd it's a good starting guide.
If you have more advanced IPv6 needs, it's usually to request a /56: use PrefixDelegationHint
You can then chunk it out with systemd: check https://major.io/p/dhcpv6-prefix-delegation-with-systemd-net... for a nice guide
> People have tried, but the response can be TL;DR'd to "works on my machine/setup" or to go harass AWS, Microsoft (via AD), etc to make things work the way the systemd mainainers think is right.
Everything we talked about doesn't seem very complicated.
If with all the pointers I've provided you still can't make it work, or if you run into more complicated problems, send an email (username at outlook), I will see what I can do.
> What did they have to do? `systemctl disable systemd-timesyncd` is not very complicated. If they want to create a service, they can have it disable timesyncd iff chrony has started successfully (in an ExecStartPost), or doing a logic chain.
This was over 5 years ago so I don't recall the details, but it did involve an issue/bug with systemd's handling of the way its internal services were disabled - it MAY have been unique to RHEL. Their fix was ultimately to upgrade RHEL that by then defaulted to chrony, but they were planning on that upgrade anyways. At the time I was making fun of my friend for using Kubernetes, which IMO is another overly complicated solution. :-P
> Maybe I can help you with that - I used to run a non systemd DHCP
Thanks, but I did solve most of the problems; it was a pain as both documentation and other issues (that again may be resolved) at the time made it a much larger hassle and we were an ubuntu shop moving from upstart to systemd that ubuntu 16.04 moved to. Now that systemd has "won out" (and I have accepted that it has), there's more clear and concise examples in documentation and stack overflow. I still dislike that it bloated out what IMO should be just a service and process management framework, though.
> RE IPv6
As I said, IPv6 (and IPSec) was used as an example of how flexibility is required when supporting services or protocols (and I'm a bit pleasantly surprised that systemd-networkd does), not an issue I was actually fighting. Also, enough consumer ISPs hand out /64's that flexibility isn't easy.
I'm also a strong believer that network configurations shouldn't be "chunked" out into multiple files, as it makes it harder to get a holistic configuration view. Fortunately that's a rare experience I need to deal with in today's world and I don't use linux as a router.
This was over 5 years ago so I don't recall the details, but it did involve an issue/bug with systemd's handling of the way its internal services were disabled - it MAY have been unique to RHEL. Their fix was ultimately to upgrade RHEL that by then defaulted to chrony, but they were planning on that upgrade anyways. At the time I was making fun of my friend for using Kubernetes, which IMO is another overly complicated solution. :-P
> Maybe I can help you with that - I used to run a non systemd DHCP
Thanks, but I did solve most of the problems; it was a pain as both documentation and other issues (that again may be resolved) at the time made it a much larger hassle and we were an ubuntu shop moving from upstart to systemd that ubuntu 16.04 moved to. Now that systemd has "won out" (and I have accepted that it has), there's more clear and concise examples in documentation and stack overflow. I still dislike that it bloated out what IMO should be just a service and process management framework, though.
> RE IPv6
As I said, IPv6 (and IPSec) was used as an example of how flexibility is required when supporting services or protocols (and I'm a bit pleasantly surprised that systemd-networkd does), not an issue I was actually fighting. Also, enough consumer ISPs hand out /64's that flexibility isn't easy.
I'm also a strong believer that network configurations shouldn't be "chunked" out into multiple files, as it makes it harder to get a holistic configuration view. Fortunately that's a rare experience I need to deal with in today's world and I don't use linux as a router.
> At the time I was making fun of my friend for using Kubernetes, which IMO is another overly complicated solution. :-P
Using Kubernetes is rarely justified because most companies are NOT at google scale :)
> I'm a bit pleasantly surprised that systemd-networkd does
There are many very pleasant surprises with it. I only wish it integrated better with intel iwctl
I'd also be happy if it duplicated iwctl functions so I could get rid of it, and it would be even better if it could also replace bluez: wireless is getting more integrated, with the new WIFI protocols giving a role to BLE (ex: Wifi-Aware 4.0 Instant Communication)
Read about Wifi Aware 4.0 and you will see why having systemd-network work with iwctl and bluez would be much harder than integrating them
> I'm also a strong believer that network configurations shouldn't be "chunked" out into multiple files
Oh no it's about chunking out your /56 prefix to multiple /64 subsets within that prefix. In that specific case, I agree with the article that systemd also made that simpler compared to what needs to be done when not using systemd
> Thanks, but I did solve most of the problems
Great! Should you run into problems during your 24.04 migration, my offer still stands: I think systemd is a nice tool, and I'll be happy to show you how to use it for advanced usecases
Don't hesitate to ping me on ycombinator if I don't reply to your email (the spam filter is not optimal)
Using Kubernetes is rarely justified because most companies are NOT at google scale :)
> I'm a bit pleasantly surprised that systemd-networkd does
There are many very pleasant surprises with it. I only wish it integrated better with intel iwctl
I'd also be happy if it duplicated iwctl functions so I could get rid of it, and it would be even better if it could also replace bluez: wireless is getting more integrated, with the new WIFI protocols giving a role to BLE (ex: Wifi-Aware 4.0 Instant Communication)
Read about Wifi Aware 4.0 and you will see why having systemd-network work with iwctl and bluez would be much harder than integrating them
> I'm also a strong believer that network configurations shouldn't be "chunked" out into multiple files
Oh no it's about chunking out your /56 prefix to multiple /64 subsets within that prefix. In that specific case, I agree with the article that systemd also made that simpler compared to what needs to be done when not using systemd
> Thanks, but I did solve most of the problems
Great! Should you run into problems during your 24.04 migration, my offer still stands: I think systemd is a nice tool, and I'll be happy to show you how to use it for advanced usecases
Don't hesitate to ping me on ycombinator if I don't reply to your email (the spam filter is not optimal)
> I have also seen many people refusing to learn modern tools
One of the reasons I prefer NetBSD (and the BSDs in general) is that they don't change gratuitously. The ifconfig / ip example you use is good: Why? If we look at the reasoning given, it was that they didn't want to make big changes to ifconfig, so they made a whole new set of commands, even though the BSDs have extended ifconfig many times.
So that ends up meaning that how-tos just don't work any more. Imagine if you want to write a how-to these days where you're telling people how to do something using standard ifconfig and now also need to add ip. This is how you do DNS on standard Unix(like) systems, and now you have to explain multiple iterations of systemd. This is how you add software, but now you need to have separate instructions for apt, yum, dpkg.
Having administered Ubuntu for others, even going from version 18 to 20 or 22 means that how-tos no longer work, scripts need to be modified, systemd handling has to be updated, et cetera.
This is why I will always choose a BSD if given a chance. Pointing to a less messy Linux (like Void because it doesn't use systemd) isn't good enough when clean, well thought out systems already exist.
One of the reasons I prefer NetBSD (and the BSDs in general) is that they don't change gratuitously. The ifconfig / ip example you use is good: Why? If we look at the reasoning given, it was that they didn't want to make big changes to ifconfig, so they made a whole new set of commands, even though the BSDs have extended ifconfig many times.
So that ends up meaning that how-tos just don't work any more. Imagine if you want to write a how-to these days where you're telling people how to do something using standard ifconfig and now also need to add ip. This is how you do DNS on standard Unix(like) systems, and now you have to explain multiple iterations of systemd. This is how you add software, but now you need to have separate instructions for apt, yum, dpkg.
Having administered Ubuntu for others, even going from version 18 to 20 or 22 means that how-tos no longer work, scripts need to be modified, systemd handling has to be updated, et cetera.
This is why I will always choose a BSD if given a chance. Pointing to a less messy Linux (like Void because it doesn't use systemd) isn't good enough when clean, well thought out systems already exist.
> One of the reasons I prefer NetBSD (and the BSDs in general) is that they don't change gratuitously.
I like BSDs for the integration and the performance.
> So that ends up meaning that how-tos just don't work any more
Complexity (or change) doesn't come out of nowhere: sometimes, new tools must be learned.
> isn't good enough when clean, well thought out systems already exist.
I also love well thought out systems, but I think systemd is one of these "well thought out" systems.
I like BSDs for the integration and the performance.
> So that ends up meaning that how-tos just don't work any more
Complexity (or change) doesn't come out of nowhere: sometimes, new tools must be learned.
> isn't good enough when clean, well thought out systems already exist.
I also love well thought out systems, but I think systemd is one of these "well thought out" systems.
Regarding ifconfig, one could use Jonathan de Boyne Pollard's http://jdebp.info/Softwares/nosh/guide/ifconfig.html which comes with his http://jdebp.info/Softwares/nosh/
> I like the various BSD and distributions like postmarket OS, but I wish they had access to modern tools instead of having to "roll my own" with scripts or make do with what they depend on
It sounds like you wish they used systemd. "Modern" is rarely a good description, and at 15 years old I don't think systemd qualifies as such anyways.
It sounds like you wish they used systemd. "Modern" is rarely a good description, and at 15 years old I don't think systemd qualifies as such anyways.
> It sounds like you wish they used systemd
I do.
> "Modern" is rarely a good description
Then call it reliable and dependable.
Modern doesn't always win for me: I prefer vim to neovim, or bash to zsh. Having a solid set of features and a good integration does.
If you are curious, see https://marcelofern.com/posts/linux/goodbye_zsh/index.html which mirrors my reasons to prefer bash
I do.
> "Modern" is rarely a good description
Then call it reliable and dependable.
Modern doesn't always win for me: I prefer vim to neovim, or bash to zsh. Having a solid set of features and a good integration does.
If you are curious, see https://marcelofern.com/posts/linux/goodbye_zsh/index.html which mirrors my reasons to prefer bash
> Modern doesn't always win for me: I prefer [...] bash to zsh
Bash and zsh are approximately to same age. I think bash is older by only a few months.
Bash and zsh are approximately to same age. I think bash is older by only a few months.
Yes, I think this confuses modern Linux users because bash is the default on most Linux server and desktop installs. So they end up thinking zsh is "new" because it's an additional package.
Postmarket actually wound up porting systemd somewhat recently.
https://postmarketos.org/blog/2024/03/05/adding-systemd/
https://postmarketos.org/blog/2024/03/05/adding-systemd/
Not by choice.
> This is of course not an easy task, one of the main blockers we found as we collaborate more closely with KDE and GNOME developers is that they have a hard time with our OpenRC-based stack. In order to get KDE Plasma and GNOME working at all, we use a lot of systemd polyfills on top of OpenRC.
> This is of course not an easy task, one of the main blockers we found as we collaborate more closely with KDE and GNOME developers is that they have a hard time with our OpenRC-based stack. In order to get KDE Plasma and GNOME working at all, we use a lot of systemd polyfills on top of OpenRC.
I don't particularly care about those details. I was mostly pointing out to the parent commenter that it does exist there now.
postmarket OS with systemd is far from ready at least for the device I'm working with. I even have to prepare a serial cable to figure what's happening.
But I know that once it's fixed, it will work well, so it's motivating me to give a hand
But I know that once it's fixed, it will work well, so it's motivating me to give a hand
I went back to Devuan and sysvinit for a peace of mind. Systemd works until it does not.
The final straw for me were randomly missing NFS mounts after booting to multiuser.
I was not able to find the fix, and the good folks on debian forums, while acknowledging the problem, could not help either.
> It's like trying to keep using ifconfig and route instead of ip: you can make it work, but for say managing multiple ip on the same interface forces you to go with eth0:0 eth0:1 etc (and let's not even talk about network namespaces).
On FreeBSD, ifconfig works fine for having multiple addresses on the same interface (and has since like forever?? I had multiple addresses on the same interface in 2004, and it's documented in the FreeBSD 1.0 man page) and it also manages configuration for wireless interfaces too. There's no need for new tools when there is already an appropriate tool that can be updated to do the job. Keeping the existing tools working means you don't need to retrain users and you don't need to update documentation that doesn't touch the new use cases.
On FreeBSD, ifconfig works fine for having multiple addresses on the same interface (and has since like forever?? I had multiple addresses on the same interface in 2004, and it's documented in the FreeBSD 1.0 man page) and it also manages configuration for wireless interfaces too. There's no need for new tools when there is already an appropriate tool that can be updated to do the job. Keeping the existing tools working means you don't need to retrain users and you don't need to update documentation that doesn't touch the new use cases.
> In my experience, systemd is far better and more reliable than anything else, especially if you need complex logic
The author is talking about home servers that do not need the complex logic.
The author is talking about home servers that do not need the complex logic.
Basic systemd is really not that complex.
I think the author's point is that systemd by itself is complex, and it doesn't matter if you use it in a simple configuration, or in a more complex one.
And I'm saying that's a somewhat ridiculous premise, because a simple systemd configuration will "just work" 99% of the time. That complexity is not something the generic case needs to care about.
My point is that the need for complex logic (see the parent comment I quoted) is not a reason to use Systemd for a home server.
What tools are missing from FreeBSD?
Regarding your example with "eth0:0" Is not how you do things in FreeBSD. There is no "eth0" at all.
You use ifconfig xy0 alias. https://man.freebsd.org/cgi/man.cgi?query=ifconfig&apropos=0...
Regarding your example with "eth0:0" Is not how you do things in FreeBSD. There is no "eth0" at all.
You use ifconfig xy0 alias. https://man.freebsd.org/cgi/man.cgi?query=ifconfig&apropos=0...
I notice FreeBSD admins tend to follow a 'pets not cattle' approach, carefully nurturing individual systems. Linux admins like myself typically prefer the 'cattle not pets' mindset—using infrastructure-as-code where if a server dies, no problem, just spin up another one. Leverage containers. Statelessness.
I don't want to spend time meticulously configuring things beyond the core infrastructure my services run on. I should probably explore FreeBSD more, but honestly, with containers being everywhere now, I'm not seeing a compelling reason to bother. I realize jails are a valid analogue, but broadly speaking the UX is not the same.
All this being said, I have this romantic draw to FreeBSD and want to play around with it more. But every time I set up a basic box I feel teleported back to 2007.
Are there any fun lab projects, posts, educational series targeted at FreeBSD?
I don't want to spend time meticulously configuring things beyond the core infrastructure my services run on. I should probably explore FreeBSD more, but honestly, with containers being everywhere now, I'm not seeing a compelling reason to bother. I realize jails are a valid analogue, but broadly speaking the UX is not the same.
All this being said, I have this romantic draw to FreeBSD and want to play around with it more. But every time I set up a basic box I feel teleported back to 2007.
Are there any fun lab projects, posts, educational series targeted at FreeBSD?
> I notice FreeBSD admins tend to follow a 'pets not cattle' approach, carefully nurturing individual systems. Linux admins like myself typically prefer the 'cattle not pets' mindset—using infrastructure-as-code where if a server dies, no problem, just spin up another one.
I've worked at 'pets not cattle' and 'cattle not pets', and I vastly prefer pets. Yes, you should be able to easily bring up a new pet when you need to; yes, it must be ok if pet1 goes away, never to be seen again. But no, it's not really ok when your servers have an average lifetime of 30 days. It's very hard to offer a stable service on an unstable substrate. Automatic recovery makes sense in some cases, but if the system stops working, there's a problem that needs to be addressed when possible.
> All this being said, I have this romantic draw to FreeBSD and want to play around with it more. But every time I set up a basic box I feel teleported back to 2007.
Like another poster mentioned; this is actually a good thing. FreeBSD respects your investment in knowledge; everything you learned in 2007 still works, and most likely will continue to work. You won't need to learn a new firewall tool every decade, whichever of the three firewalls you like will keep working. You don't need to learn a new tool to configure interfaces, ifconfig will keep working. You don't need to learn a new tool to get network statistics, netstat will keep working. Etc.
I've worked at 'pets not cattle' and 'cattle not pets', and I vastly prefer pets. Yes, you should be able to easily bring up a new pet when you need to; yes, it must be ok if pet1 goes away, never to be seen again. But no, it's not really ok when your servers have an average lifetime of 30 days. It's very hard to offer a stable service on an unstable substrate. Automatic recovery makes sense in some cases, but if the system stops working, there's a problem that needs to be addressed when possible.
> All this being said, I have this romantic draw to FreeBSD and want to play around with it more. But every time I set up a basic box I feel teleported back to 2007.
Like another poster mentioned; this is actually a good thing. FreeBSD respects your investment in knowledge; everything you learned in 2007 still works, and most likely will continue to work. You won't need to learn a new firewall tool every decade, whichever of the three firewalls you like will keep working. You don't need to learn a new tool to configure interfaces, ifconfig will keep working. You don't need to learn a new tool to get network statistics, netstat will keep working. Etc.
I agree on the "knowledge stability" front. I feel like I have to relearn Linux server networking config every three years because I switched distro or a distro switched their network management middleware.
But.
Having tried to move a machine from rhel 5 to rhel 7, where 12 people had used the server over the past 8 years for any scripting/log analysis/automation, for hosting a bespoke python web request site and a team-specific dokuwiki... The idea of having all that in source control and CICD is alluring.
But.
Having tried to move a machine from rhel 5 to rhel 7, where 12 people had used the server over the past 8 years for any scripting/log analysis/automation, for hosting a bespoke python web request site and a team-specific dokuwiki... The idea of having all that in source control and CICD is alluring.
You can certainly keep information on your pets and how to rebuild them in source control along with all the procedures used to update them. It's probably a good idea.
Nobody says you can't do CI/CD with pets too. You do have to keep the pets well groomed, of course.
Nobody says you can't do CI/CD with pets too. You do have to keep the pets well groomed, of course.
> But no, it's not really ok when your servers have an average lifetime of 30 days. It's very hard to offer a stable service on an unstable substrate.
The whole cattle mindset because at the end of the day everything is a "unstable substrate" your building a stable service on unstable blocks pets don't solve the issue that each pet is fundamentally unstable and your just pretending it's not.
The whole cattle mindset because at the end of the day everything is a "unstable substrate" your building a stable service on unstable blocks pets don't solve the issue that each pet is fundamentally unstable and your just pretending it's not.
> The whole cattle mindset because at the end of the day everything is a "unstable substrate" your building a stable service on unstable blocks pets don't solve the issue that each pet is fundamentally unstable and your just pretending it's not.
That's not the way the world has to be. You can have a network that is rock solid. You can have power that is rock solid. You can have hardware that is rock solid.
Sure, if you have a couple thousand machines, a few of them will have hardware problems every year. Yes, once in a while an automatic transfer switch will fail and you'll have a large data center outage. Backhoes exist. Urgent kernel fixes happen. You have to acknowledge failures happen and plan for them, but you should also work to minimize failures, which I honestly haven't seen at the 'cattle not pets' workplaces. Cattle take about two years to get to market [1] (1.5 years before these people receive them, then 180 days before sending them to market); I'd be fine with expecting my servers to run for two years before replacement (and you know, rotating in new servers throughout, maybe swapping out 1/8th of the servers every quarter, etc), but after running for 30 days at 'cattle not pets', I started getting complaints that my systems were running for too long.
[1] https://cultivateconnections.org/how-do-you-determine-when-t...
That's not the way the world has to be. You can have a network that is rock solid. You can have power that is rock solid. You can have hardware that is rock solid.
Sure, if you have a couple thousand machines, a few of them will have hardware problems every year. Yes, once in a while an automatic transfer switch will fail and you'll have a large data center outage. Backhoes exist. Urgent kernel fixes happen. You have to acknowledge failures happen and plan for them, but you should also work to minimize failures, which I honestly haven't seen at the 'cattle not pets' workplaces. Cattle take about two years to get to market [1] (1.5 years before these people receive them, then 180 days before sending them to market); I'd be fine with expecting my servers to run for two years before replacement (and you know, rotating in new servers throughout, maybe swapping out 1/8th of the servers every quarter, etc), but after running for 30 days at 'cattle not pets', I started getting complaints that my systems were running for too long.
[1] https://cultivateconnections.org/how-do-you-determine-when-t...
I’ve had Linux servers with > 1 year of uptime. I’ve seen much, much higher. It’s entirely possible to have a stable foundation; it’s modern software that’s hot garbage, and relies on ephemerality to stay running.
...right, yes, servers. I've certainly never accidentally forgotten to reboot a laptop on cheap commodity hardware for a few months. Slightly more than a few months. Look, it got rebooted eventually, okay?
> But every time I set up a basic box I feel teleported back to 2007.
You sat that as though its a bad thing! The author values simplicity.
> I notice FreeBSD admins tend to follow a 'pets not cattle' approach, carefully nurturing individual systems. Linux admins like myself typically prefer the 'cattle not pets' mindset—using infrastructure-as-code where if a server dies, no problem, just spin up another one. Leverage containers. Statelessness.
Is it less work to write that code and manage "pet"? Are there other advantages?
I think you probably are right about the preferred approach - but what are the advantages of each?
> Statelessness
What about data storage?
You sat that as though its a bad thing! The author values simplicity.
> I notice FreeBSD admins tend to follow a 'pets not cattle' approach, carefully nurturing individual systems. Linux admins like myself typically prefer the 'cattle not pets' mindset—using infrastructure-as-code where if a server dies, no problem, just spin up another one. Leverage containers. Statelessness.
Is it less work to write that code and manage "pet"? Are there other advantages?
I think you probably are right about the preferred approach - but what are the advantages of each?
> Statelessness
What about data storage?
The only thing I currently run on FreeBSD is my storage box. ZFS is absolutely amazing, and FreeBSD supports it fully and without any of the "jank" you'd get running ZFS on Linux. It Just Works (tm), bottom to top. Anything else, I want what I'm familiar with on Linux, like containers and systemd services. I know some people really love pf, but I've been using iptables for so long it would be annoying to switch at this point. So really, it comes down to what you're familiar and comfortable with, and using the right tool for the job.
> ZFS is absolutely amazing, and FreeBSD supports it fully and without any of the "jank" you'd get running ZFS on Linux.
This is why I use FreeBSD as well for my home server, first class ZFS support out of the box. Void Linux musl on my desktop.
I had an old 2TB ZFS array that was part of a trunas setup kicking around for years. I needed to recover some files from it so I hooked all the disks to a motherboard and booted FreeBSD live. I didn't have to do anything, the array was already up and running when I logged in. ezpz.
This is why I use FreeBSD as well for my home server, first class ZFS support out of the box. Void Linux musl on my desktop.
I had an old 2TB ZFS array that was part of a trunas setup kicking around for years. I needed to recover some files from it so I hooked all the disks to a motherboard and booted FreeBSD live. I didn't have to do anything, the array was already up and running when I logged in. ezpz.
ZFS is a first-class citizen on Void Linux, too. There's a lot of care and consideration put into the kernel packages to ensure compatibility with ZFS. ZFSBootMenu is 'native' to Void as well, and the features it provides are quite far ahead of what FreeBSD's bootloader has.
I prefer OS variety and have a mix of Plan 9, Linux, FreeBSD and OpenBSD running my personal stuff.
> 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?
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.
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.
ZFS works on Ubuntu top to the bottom too. It’s installed with a command.
> Are there any fun lab projects, posts, educational series targeted at FreeBSD?
Klara Systems [0], Vermaden [1] and IT Notes [2] seems to be the most active and popular.
- [0] https://klarasystems.com/articles/
- [1] https://vermaden.wordpress.com/posts/
- [2] https://it-notes.dragas.net/categories/freebsd/
Klara Systems [0], Vermaden [1] and IT Notes [2] seems to be the most active and popular.
- [0] https://klarasystems.com/articles/
- [1] https://vermaden.wordpress.com/posts/
- [2] https://it-notes.dragas.net/categories/freebsd/
> - [0] https://klarasystems.com/articles/
I personally wrote several of them :)
I personally wrote several of them :)
Cattle vs pets always seemed like a silly distinction to me. Fundamentally they're about abstraction levels.
If you treat a server as a "pet", then you typically run multiple services through a service runner (systemd, runit, openrc, etc.) and do only a moderate amount of communication between servers. Here you treat the server as your scheduling substrate upon which your units of compute, services, run. In a "cattle" system, each server is interchangable and you run some isolated service, usually a container, on each of your servers. Here the unit of compute is a container and the compute substrate is the cluster, multiple servers.
In a "pets" system managing many servers is fraught and in a "cattle" system managing many clusters is fraught. So it's simply the abstraction level you want to work at. If you're at the level where your workload fits easily on a single server, or maybe a couple servers, then a pets-like system works fine. If you see the need to horizontally scale then a cattle-like system is what you need. There's a practical problem right now in that containerization ecosystems are usually heavy enough that it takes advanced tools (like bubblewrap or firejail) to isolate your services on a single service which offers the edge to cattle-like systems.
In my experience, many smaller services with non-critical uptime requirements can run just fine on a single server, maybe just moving the data store externally so that failure of the service and failure of the data store are independent.
If you treat a server as a "pet", then you typically run multiple services through a service runner (systemd, runit, openrc, etc.) and do only a moderate amount of communication between servers. Here you treat the server as your scheduling substrate upon which your units of compute, services, run. In a "cattle" system, each server is interchangable and you run some isolated service, usually a container, on each of your servers. Here the unit of compute is a container and the compute substrate is the cluster, multiple servers.
In a "pets" system managing many servers is fraught and in a "cattle" system managing many clusters is fraught. So it's simply the abstraction level you want to work at. If you're at the level where your workload fits easily on a single server, or maybe a couple servers, then a pets-like system works fine. If you see the need to horizontally scale then a cattle-like system is what you need. There's a practical problem right now in that containerization ecosystems are usually heavy enough that it takes advanced tools (like bubblewrap or firejail) to isolate your services on a single service which offers the edge to cattle-like systems.
In my experience, many smaller services with non-critical uptime requirements can run just fine on a single server, maybe just moving the data store externally so that failure of the service and failure of the data store are independent.
BSD is for those core infrastructure that you want to meticulously configure. If the system is cattle who cares what OS is underneath
ZFS is probably the biggest reason for me. I have a machine with a zfs pool running samba and nfsd.
Philosophically I tend to prefer *BSDs over Linux. I have a few FreeBSD machines, one OpenBSD, and one Linux.
Philosophically I tend to prefer *BSDs over Linux. I have a few FreeBSD machines, one OpenBSD, and one Linux.
> ZFS is probably the biggest reason for me.
Maybe in the past there was an argument for that, but ever since FreeBSD started using OpenZFS implementation...what's the difference?
My ideal OS would be something like NixOS, but on FreeBSD and with better language than Nix.
Maybe in the past there was an argument for that, but ever since FreeBSD started using OpenZFS implementation...what's the difference?
My ideal OS would be something like NixOS, but on FreeBSD and with better language than Nix.
ZFS is part of the OS on FreeBSD.
Integrated more tightly in every respect.
ZFS is a first class part of FreeBSD. you can use it on linux, but it will always have some rough edges. How rough it open to question though, for some it works well.
Used ZFS on Debian in production for 8 years, yet to experience rough edges but always interested to learn.
Do you use ZFS for root, on Debian? (enabling "boot environments")
I've recently switched my FreeBSD setups to use that scheme, and it's been nice. Would be interested to hear if it's similarly straightforward on Debian (my second-favorite OS :)
Obviously requires support in the bootcode; I'm not sure of the state of that for Linux.
I've recently switched my FreeBSD setups to use that scheme, and it's been nice. Would be interested to hear if it's similarly straightforward on Debian (my second-favorite OS :)
Obviously requires support in the bootcode; I'm not sure of the state of that for Linux.
No, to be fair I use it for everything except root (which I prefer to backup as IaC, not that I wouldn't use ZFS, it's just not default so requires more effort). I use ZFS datasets to back everything except the OS, including DBs which has been the most satisfying aspect of using ZFS (being able to snapshot live DBs together with all other relevant state rather than a as a separate replication process).
While I can't comment on using it for root, I can say for other use, the only annoyance I have is compiling the kernel module on every single update. This is automatically handled by APT, but for very small servers it can be slow... at most ~15 mins. Could be solved with private distribution for a large fleet but I can't be bother with that stuff. Hoping at some point Debian will relax their strict "to the letter of the GPL" attitude at some point like they did with install media drivers. But it's not the worst experience, at least installing is automated.
While I can't comment on using it for root, I can say for other use, the only annoyance I have is compiling the kernel module on every single update. This is automatically handled by APT, but for very small servers it can be slow... at most ~15 mins. Could be solved with private distribution for a large fleet but I can't be bother with that stuff. Hoping at some point Debian will relax their strict "to the letter of the GPL" attitude at some point like they did with install media drivers. But it's not the worst experience, at least installing is automated.
zfsbootmenu https://docs.zfsbootmenu.org/en/v3.0.x/
Also nice way to recover zfs if anything goes wrong. yea, it's a linux image for just booting. But you put it as an EFI image, and works great.
Also nice way to recover zfs if anything goes wrong. yea, it's a linux image for just booting. But you put it as an EFI image, and works great.
I've been running zfs on root on my Debian home server, only the install was a tiny bit more involved but it was done in maybe half an hour going off of the guide and trying to understand everything it was doing with 0 experience (... And then did it again after I broke networking after an hour lol)
Well, rough edges:
- bootloader (when root is on ZFS)*
- ARC vs kernel page cache and OOM Killer
That's all in my opinion.
*: Relative to FreeBSD, but that's because bootloader in FreeBSD is part of the base system and in linux it could be one of many.
- bootloader (when root is on ZFS)*
- ARC vs kernel page cache and OOM Killer
That's all in my opinion.
*: Relative to FreeBSD, but that's because bootloader in FreeBSD is part of the base system and in linux it could be one of many.
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.
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.
My experience with ZFS (over 10 years ago now) was awful. Still have a bad taste in my mouth though no doubt it's much improved today.
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.
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.
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.
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
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
Well since FreeBSD is pulling ZFS source from Linux, I am not certain what are the rough edges. And I have ran ZFS for 7+ years on Linux with zero issues.
ZFS is not part of linux. It is a separate project that publishes both to FreeBSD and some shims so you can run it on Linux. FreeBSD pulls and directly integrates it, but for license reasons linux doesn't pull it in directly. Yes the upstream project does have some shims of linux use that they public directly, but FreeBSD is a first class user of that project while the linux shims are a hack that some in the kernel do not want to work.
> My ideal OS would be something like NixOS, but on FreeBSD and with better language than Nix.
Something nicer than nix would be nice, but otherwise perhaps keep an eye on https://github.com/nixos-bsd/nixbsd
Something nicer than nix would be nice, but otherwise perhaps keep an eye on https://github.com/nixos-bsd/nixbsd
Yeah, it's acceptable, I want to try to convert my home server to nixbsd.
My ideal OS (for a server) is Guix, NixOS without Nix-the-language. Sadly no one is packaging for it.
Ubuntu can have zfs with an install of a package.
BSD’s inability to utilize docker ecosystem had me decided to stick with Ubuntu for a decade, unless things change and BSD gets clear advantages over Linux.
BSD’s inability to utilize docker ecosystem had me decided to stick with Ubuntu for a decade, unless things change and BSD gets clear advantages over Linux.
Here's where I'll show my age. If you got into a unix-like OS in the '90s, the *BSD ergonomics will make more sense.
I remember when Ubuntu and docker each entered the scene and my initial impressions of both were pretty negative.
I remember when Ubuntu and docker each entered the scene and my initial impressions of both were pretty negative.
Ubuntu can have ZFS. FreeBSD just does, as long as you select "ZFS on root" for your disk layout when you install. It just works, and then you automatically get things like snapshots and easy rollback during upgrades.
Ubuntu ships an outdated version that misses a lot of bugfixes. They don't seem to be interested in either backporting fixes or shipping the current stable version. Every other day some Ubuntu user hits the ZFS GitHub issues with a problem that was fixed years ago.
After hitting this in production, I will never choose Ubuntu again.
On top of the things you mentioned, it’s basically impossible to produce a working playbook that switches from Ubuntu’s garbage package to the upstream ones - systemd wedges badly about 25% of the time, and force disables the zfs units. None of the documented systemd overrides worked.
I’m enjoying devuan and openbsd at home.
On top of the things you mentioned, it’s basically impossible to produce a working playbook that switches from Ubuntu’s garbage package to the upstream ones - systemd wedges badly about 25% of the time, and force disables the zfs units. None of the documented systemd overrides worked.
I’m enjoying devuan and openbsd at home.
Got sick of doing ZFS on Arch Linux and lagging behind on new kernel releases. Switched to bcachefs (only for my laptop) which has the trifecta of data and metadata checksumming, compression, and encryption. It's also just simpler to use.
Cheap Complexity.
https://www.schneier.com/blog/archives/2022/08/security-and-...
The article is directly talking about mass-produced electronic commodities. The same is even more so for bits where the cost of copying is not merely "low" as in microcontrollers, but essentially free.
In my opinion, systemd does solve a lot of problems, at a cost of somewhat more complexity and resource utilization. But it is the nature of material culture to complexify with time as more physical resources become available, i.e., "progress". More advanced commodities don't come out of a thin air of "better processes", but processes that interweave with other parts of the economy more intimately given the previously produced commodities. Something similar can be true inside the computer.
https://www.schneier.com/blog/archives/2022/08/security-and-...
The article is directly talking about mass-produced electronic commodities. The same is even more so for bits where the cost of copying is not merely "low" as in microcontrollers, but essentially free.
In my opinion, systemd does solve a lot of problems, at a cost of somewhat more complexity and resource utilization. But it is the nature of material culture to complexify with time as more physical resources become available, i.e., "progress". More advanced commodities don't come out of a thin air of "better processes", but processes that interweave with other parts of the economy more intimately given the previously produced commodities. Something similar can be true inside the computer.
I started reading but stopped as soon as it was a systemd rant. systemd, while not for everyone is a good for most people.
I kept on reading because I use OSes that have different init systems, one of which is systemd. Choice is great. Of course, your comment could be accused of being a rant too.
Choice is great, but I don't think we can expect everyone to maintain "unit files" for every init system. If you can and can afford to run systemd it's probably worth it, it's a "nice to have" most of the time.
If you wanna run your own init solution you can but it might be a bit of effort, embedded people often do this while a system like a desktop with dbus and display servers and IPC left and right might standardize on systemd
If you wanna run your own init solution you can but it might be a bit of effort, embedded people often do this while a system like a desktop with dbus and display servers and IPC left and right might standardize on systemd
Choice is fine, but the perception is that "the science is settled" and systemd is objectively better; therefore if you are still a systemd refusenik you're a little bit crazy and more difficult to take seriously.
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.
Very well put. I can see how if you learnt Linux before systemd, it may feel like a regression in some ways, but for anyone learning Linux after systemd it's somewhat impenetrable to use anything else. Systemd successfully "productised" and canonicalised what appears to have only really been a bunch of loose conventions beforehand (e.g. sysvinit, not sure I've never seen scripts from different authors work completely the same).
The only reason I DON'T use FreeBSD as much as I wish is because it doesn't have systemd. In my opinion a good versatile init system for managing daemons is a must-have for a server OS.
> systemd, while not for everyone is a good for most people
Are you really sure?
systemd is a tool that automates system configuration with no interaction from the user, and it does it in such a way that the user doesn't have to know how the system works, then the user doesn't want to know, and then no longer actually knows.
When that happens, the user can't make any political decisions about his/her system, the "system" account gets to have higher privileges than "Administrator", the user is no longer the owner of the OS, can't control what the system does, not even what it does with his/her personal data, and finally we all turn into uneducated mindless drones. Oh, wait, we're already there. How did that happen?
Great for company computers ; very bad for users.
Are you really sure?
systemd is a tool that automates system configuration with no interaction from the user, and it does it in such a way that the user doesn't have to know how the system works, then the user doesn't want to know, and then no longer actually knows.
When that happens, the user can't make any political decisions about his/her system, the "system" account gets to have higher privileges than "Administrator", the user is no longer the owner of the OS, can't control what the system does, not even what it does with his/her personal data, and finally we all turn into uneducated mindless drones. Oh, wait, we're already there. How did that happen?
Great for company computers ; very bad for users.
I'm 100% certain, you're regurgitating the typical anti-systemd shill that hates into a future where we might be so lucky that Linux users don't need to know anything about their init system. That day is a good day for Linux users if it happens.
I don't think not knowing all of what systemd does will turn Linux users into mindless drones and it's quite dismissive to take that stance, these are users that chose another OS for their out of their own free will.
I don't think not knowing all of what systemd does will turn Linux users into mindless drones and it's quite dismissive to take that stance, these are users that chose another OS for their out of their own free will.
You don't have to belive me, you know... Just look at what happend with Microsoft users over time as the OSs became more and more unconfigurable. On the other side, Linux users, from the beginning until recently, were very competent. They stayed competent because they had to. School is compulsory for everybody a reason - extremely few people learn, unless they're forced to.
"Mindless drones" is probably a little harsh - I usually reserve that for mobile phone/tablet users.
"Mindless drones" is probably a little harsh - I usually reserve that for mobile phone/tablet users.
You're turning "these systems work so incredibly shit that we must know everything about it to work it" into something positive while dismissing the state we had before systemd. And regarding learning, it seems people are still willing to use and work in the Linux ecosystem even after systemd and Kubernetes and other high level abstractions that makes utilizing computers easier.
I think using the description "mindless drone" for someone using a device is better left off this and any HN communication as I assume 99% of readers use a mobile phone daily.
I think using the description "mindless drone" for someone using a device is better left off this and any HN communication as I assume 99% of readers use a mobile phone daily.
I still don't use systemd and this year I stopped using openrc too. Now I'm using only sysvinit. It was very very educational and I even reported bugs in sysvinit, some of them were there for over 20 years.
The people you are attracting to Linux are not the kind of people that will improve it in any way. As Linux is free (well, most distros), you won't even see any extra money. Only idiotic bug reports will increse. "Interent isn't working!!!111 FIX IT NOWWW!!!111"
You're not even attracting competent sysadmins. You'll have more security breaches, more automated hacking (because without manually-written scripts, all systems behave predictably the same), more costly fixes (because consultants that still know the job are expensive).
Mobile users that feel offended users may vote me down, I don't mind, but you know the type of users I was referring to.
The people you are attracting to Linux are not the kind of people that will improve it in any way. As Linux is free (well, most distros), you won't even see any extra money. Only idiotic bug reports will increse. "Interent isn't working!!!111 FIX IT NOWWW!!!111"
You're not even attracting competent sysadmins. You'll have more security breaches, more automated hacking (because without manually-written scripts, all systems behave predictably the same), more costly fixes (because consultants that still know the job are expensive).
Mobile users that feel offended users may vote me down, I don't mind, but you know the type of users I was referring to.
Wow OP there, I didn't think anyone would pass by my random blog and post the link here .... I'm surprised at the number of comments for a post that was originally there just to feed my blog with a first page and provide a bit of content.
Especially for an article that I feel is barely finished and needs a lot of updating.
Thanks for https://aumont.fr/posts/Jails-backup-nocodb/ too
It's a fun write-up. After reading it I am feeling spinning up a FreeBSD for run now.
If you are curious about a two-server infra with FreeBSD VNET jails:
https://blog.uxtly.com/freebsd-jails-network-setup
https://blog.uxtly.com/freebsd-jails-network-setup
A really nice blog post! I bet some of the tricks in there will be useful to me in the future :)
Just this past weekend I gave up trying to install OpenSUSE on a new laptop. I couldn't figure out which magic combination of overlapping Xorg, Wayland, and who knows what else settings were required to make ctrl:nocaps work both in the console and in KDE. I had FreeBSD running with a X11 Mate desktop, with all my files and software , ready to rock in less than an hour. Only thing remaining is to figure out suspend/hibernate and make the brightness keys work. What a breath of fresh air.
I have mixed feelings about FreeBSD. Some stuff is genuinely good: major/minor release branches, the best ZFS experience you can get OOB, actual man pages, overall a lot "cleaner" than most Linux distros.
OTOH when you compare it to e.g. OpenBSD (or in many instances, even Linux), it's an actual mess. The default install leaves you browsing thru the handbook to get simple things to work; it has three (three!) distinct firewalls; the split between /usr/local/etc and /etc constantly leaves you guessing where to find a particular config file; even the tiny things such as some default sysctl value being an XML snippet - actually, WTF?
The desktop story is also pretty bad. OpenBSD asks you during installation, whether you'd like to use X11 - and that's it. You boot to XDM, you get a basic window manager, things like volume buttons just work, all in the base system - no packages, no config files. You can install Gnome or XFCE from there, and rest assured you'll always have a working fallback. FreeBSD still feels like 90's Linux in that area. Regarding usability, both are behind Linux in things like connecting to Wifi networks, but in OpenBSD's case you just save a list of SSIDs/passwords in a text file, and the kernel does the rest for you.
The author is praising jails. I think it's nice that you can trace the lineage all the way back to 6.x, it sings a song of stability. You can also put each jail on a separate ZFS dataset to get snapshot/restore, cloning, etc. But I think it's still a poor middle ground between OpenBSD and OCI. OpenBSD keeps making steps (privsep, pledge, unveil) to provide isolation, while remaining conceptually simple for the developer and imposing no extra maintenance burden on the operator. Containers by design are declarative, separate the system image from state, etc - it's a wholly different concept for someone used to e.g. managing stateful jails or VMs, but it reinforces what already were good design principles.
OTOH when you compare it to e.g. OpenBSD (or in many instances, even Linux), it's an actual mess. The default install leaves you browsing thru the handbook to get simple things to work; it has three (three!) distinct firewalls; the split between /usr/local/etc and /etc constantly leaves you guessing where to find a particular config file; even the tiny things such as some default sysctl value being an XML snippet - actually, WTF?
The desktop story is also pretty bad. OpenBSD asks you during installation, whether you'd like to use X11 - and that's it. You boot to XDM, you get a basic window manager, things like volume buttons just work, all in the base system - no packages, no config files. You can install Gnome or XFCE from there, and rest assured you'll always have a working fallback. FreeBSD still feels like 90's Linux in that area. Regarding usability, both are behind Linux in things like connecting to Wifi networks, but in OpenBSD's case you just save a list of SSIDs/passwords in a text file, and the kernel does the rest for you.
The author is praising jails. I think it's nice that you can trace the lineage all the way back to 6.x, it sings a song of stability. You can also put each jail on a separate ZFS dataset to get snapshot/restore, cloning, etc. But I think it's still a poor middle ground between OpenBSD and OCI. OpenBSD keeps making steps (privsep, pledge, unveil) to provide isolation, while remaining conceptually simple for the developer and imposing no extra maintenance burden on the operator. Containers by design are declarative, separate the system image from state, etc - it's a wholly different concept for someone used to e.g. managing stateful jails or VMs, but it reinforces what already were good design principles.
> the split between /usr/local/etc and /etc constantly leaves you guessing where to find a particular config file;
Isn't it just that /etc is the base OS and /usr/local is all packages added on top?
Isn't it just that /etc is the base OS and /usr/local is all packages added on top?
The base/packages split is one of the main reasons why I appreciate the BSDs (that includes macOS). However /usr/local/etc in particular violates several assumptions:
- I can make /usr read-only, exclude it from backups, put it on an NFS share, or otherwise treat it as immutable during normal operation;
- I can nuke /usr/local any time, fall back on the base system, and reinstall packages from there;
- I can put /etc in version control and track all configuration changes;
- I don't need to think whether to look for /etc/nginx or /usr/local/etc/nginx, this also simplifies automation like scripts or Ansible roles; etc
Notably, OpenBSD takes the effort to ensure all packages install their configs in /etc.
- I can make /usr read-only, exclude it from backups, put it on an NFS share, or otherwise treat it as immutable during normal operation;
- I can nuke /usr/local any time, fall back on the base system, and reinstall packages from there;
- I can put /etc in version control and track all configuration changes;
- I don't need to think whether to look for /etc/nginx or /usr/local/etc/nginx, this also simplifies automation like scripts or Ansible roles; etc
Notably, OpenBSD takes the effort to ensure all packages install their configs in /etc.
I don't think those first two are violated? I'm pretty sure you can make /usr read-only, mount it from a shared source, and nuke /usr/local at will. I do agree that splitting config files by base and not-base means there are two places, but given this particular system design it seems like a bad assumption rather than a bad design.
Symbolic links can be made, but test test test and make sure anyone else administering that host knows exactly what has been linked and why. Purists might scream, but its none of their business if it doesn't get in anyone else's way.
> the split between /usr/local/etc and /etc constantly leaves you guessing where to find a particular config file
I started with FreeBSD and it never was a problem to me until I started to use Linux too. Now I just make symlinks from /usr/local/etc to /etc for software I use both on Linux and FreeBSD. The rule is simple - if an app is from the base system it is in /etc and if you installed some software from packages (ports) then configs will be in /usr/local/etc.
I started with FreeBSD and it never was a problem to me until I started to use Linux too. Now I just make symlinks from /usr/local/etc to /etc for software I use both on Linux and FreeBSD. The rule is simple - if an app is from the base system it is in /etc and if you installed some software from packages (ports) then configs will be in /usr/local/etc.
FreeBSD is more of an admin's system than a user's system and this perfectly illustrates one of the reasons why. Outside of this forum, in regular consumer land, OS users don't want to know or care about the distinction between base and ports, and nothing anyone says about it is going to change that. So I run lots of BSD at home but I recommend Mint to family.
May be I'm biased but a distinction between base OS and 3rd party software is a simple concept to me, also it is not unique to BSD. E. g. in Windows there were different menu sections to install/uninstall optional Windows components and to uninstall 3rd party software.
If aynthing Linux is an outlier in that core OS components and 3rd party apps both come in similar packages which makes it hard to distinguish which is a part of the base OS and which and optional 3rd party software. In FreeBSD I know that I can delete all packages and still have a system remotely accessible via SSH (with rare exception a normal user will not come across). In Linux to tell which package can be uninstalled without breaking the system one have to be an expert. Can I delete iproute package if I don't use ip command, can I remove NetworkManager, is systemd-container optional? Where the OS stops and 3rd party apps start?
If aynthing Linux is an outlier in that core OS components and 3rd party apps both come in similar packages which makes it hard to distinguish which is a part of the base OS and which and optional 3rd party software. In FreeBSD I know that I can delete all packages and still have a system remotely accessible via SSH (with rare exception a normal user will not come across). In Linux to tell which package can be uninstalled without breaking the system one have to be an expert. Can I delete iproute package if I don't use ip command, can I remove NetworkManager, is systemd-container optional? Where the OS stops and 3rd party apps start?
In regular consumer land, nobody is going to care that some config files are in /etc and others are in /usr/local/etc because a regular consumer has no idea what either one is, anyway.
[deleted]
I have had BSD as my router for a few years in the past and used Linux for a few decades but I never got this “BSD is cleaner” argument. Linux has man pages and Google gives you plenty more practical resources when in doubt and nothing felt unstable compared to “BSD is more tightly integrated” statement.
Lack of community resource such as documents, blogs, StackOverflow answers and docker ecosystem just drove me away from BSD as I lose nothing by using Linux. The only thing I miss could be OpenBSD’s pf.
Lack of community resource such as documents, blogs, StackOverflow answers and docker ecosystem just drove me away from BSD as I lose nothing by using Linux. The only thing I miss could be OpenBSD’s pf.
Maybe "cleaner" really means "more uniform", compared to the wide variety of Linux distros and their incompatibilities? Or like the word "intuitive", really just means "what I'm used to".
More uniform most likely. With FreeBSD can google some issue you’re encountering and the solutions you find are likely to be applicable, even with differing hardware, OS version, etc.
With Linux there’s been many times I’ll google some problem and the only solution that turns up is for distro Y which is mostly or entirely irrelevant to distro X that I’m running at the moment. This happens even with the big mainstream distros like Ubuntu and Fedora, but of course it’s worse with more niche ones.
With Linux there’s been many times I’ll google some problem and the only solution that turns up is for distro Y which is mostly or entirely irrelevant to distro X that I’m running at the moment. This happens even with the big mainstream distros like Ubuntu and Fedora, but of course it’s worse with more niche ones.
> I think it's nice that you can trace the lineage all the way back to 6.x
It's 4.0 actually - March 2000. For jails and kqueue.
It's 4.0 actually - March 2000. For jails and kqueue.
> actual 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 effort. I've often found minor discrepancies between those resources and what I actually found installed on my system.
Debian does an absolutely amazing job: every executable in every package has to come with a man page, and if there isn't one, the maintainers will at least write a synopsis. You can also read these man pages online: <https://manpages.debian.org>; you get to browse by release, section, you even get translations. Some derivatives (e.g. Ubuntu) will provide their own online browser as well.
But this is where things start to get dicey. Most distributions make heavy use of GNU coreutils, glibc, GCC, etc. Some of these (like GCC) are complex, because the problem domain is complex. On the other hand, coreutils' level of unnecessary complexity is almost byzantine; to cope with that, the GNU project mostly abandoned man pages (these mostly just contain a synopsis) in favour of an in-house "info" system <https://www.gnu.org/software/texinfo/manual/info-stnd/info-s...>, which is basically TeX <https://tug.org> with layers on top.
But not all distros use GNU tools nowadays; e.g. Alpine (actually pretty popular, thanks to the Docker ecosystem) uses busybox and musl libc. However for some reason Alpine not only does not provide an online man page browser, but requires installing a meta-package to add the man pages to your system. The differences between GNU and busybox+musl are non-trivial (and not unlike GNU vs BSD).
You can blame the Linux ecosystem fragmentation, and you would be correct to point out there are three popular BSDs, each with its own goals and little quirks. My final point is about the quality of the documentation. Compare coreutils chmod(1) <https://linux.die.net/man/1/chmod> and OpenBSD chmod(1) <https://man.openbsd.org/chmod.1>. The former is a brief, dense, and intimidating wall of text that expects you to immediately grasp what "ugoa" or "rwxXst" stand for; you will only find out that the tool manages file access permissions once you dig through the third paragraph; the text concludes by referring you to "info coreutils aqchmod invocationaq". By contrast, OpenBSD's man page has a clear introduction, then paces you through explaining the basic; goes into detail over the octal and symbolic representations (with pretty tables); warns you about a common mistake; has several examples with explanations (including equivalences between octal and symbolic forms); and concludes by referring you to the POSIX standards.
Best of it, you can expect the same high standard of quality throughout the entire base system, from user commands to device drivers and kernel internals.
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 effort. I've often found minor discrepancies between those resources and what I actually found installed on my system.
Debian does an absolutely amazing job: every executable in every package has to come with a man page, and if there isn't one, the maintainers will at least write a synopsis. You can also read these man pages online: <https://manpages.debian.org>; you get to browse by release, section, you even get translations. Some derivatives (e.g. Ubuntu) will provide their own online browser as well.
But this is where things start to get dicey. Most distributions make heavy use of GNU coreutils, glibc, GCC, etc. Some of these (like GCC) are complex, because the problem domain is complex. On the other hand, coreutils' level of unnecessary complexity is almost byzantine; to cope with that, the GNU project mostly abandoned man pages (these mostly just contain a synopsis) in favour of an in-house "info" system <https://www.gnu.org/software/texinfo/manual/info-stnd/info-s...>, which is basically TeX <https://tug.org> with layers on top.
But not all distros use GNU tools nowadays; e.g. Alpine (actually pretty popular, thanks to the Docker ecosystem) uses busybox and musl libc. However for some reason Alpine not only does not provide an online man page browser, but requires installing a meta-package to add the man pages to your system. The differences between GNU and busybox+musl are non-trivial (and not unlike GNU vs BSD).
You can blame the Linux ecosystem fragmentation, and you would be correct to point out there are three popular BSDs, each with its own goals and little quirks. My final point is about the quality of the documentation. Compare coreutils chmod(1) <https://linux.die.net/man/1/chmod> and OpenBSD chmod(1) <https://man.openbsd.org/chmod.1>. The former is a brief, dense, and intimidating wall of text that expects you to immediately grasp what "ugoa" or "rwxXst" stand for; you will only find out that the tool manages file access permissions once you dig through the third paragraph; the text concludes by referring you to "info coreutils aqchmod invocationaq". By contrast, OpenBSD's man page has a clear introduction, then paces you through explaining the basic; goes into detail over the octal and symbolic representations (with pretty tables); warns you about a common mistake; has several examples with explanations (including equivalences between octal and symbolic forms); and concludes by referring you to the POSIX standards.
Best of it, you can expect the same high standard of quality throughout the entire base system, from user commands to device drivers and kernel internals.
> 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.
Actually, there is.
https://web.git.kernel.org/pub/scm/docs/man-pages/man-pages....
It's included with many default distro installs.
This is technically true, but this pretty much exactly illustrates my point. The SCM URL you've provided, you have to dig it up. It refers you to <https://man7.org/linux/man-pages/index.html>, which again, is a personal website of a member of the community. Then e.g. the fnctl(2) page comes from the 6.10 kernel release - AFAICT I can't browse the past releases or track HEAD. Compare with <https://man.openbsd.org> or <https://man.freebsd.org/cgi/man.cgi>, you can find both straight from the landing pages.
Meanwhile if you can't find man7.org (Google search results are only getting worse) and start browsing <https://docs.kernel.org>, it refers you to <https://www.kernel.org/doc/man-pages/> which refers you to <https://www.kernel.org/doc/man-pages/maintaining.html>, <https://www.kernel.org/doc/man-pages/missing_pages.html>, and Wikipedia - none of which seem to be relevant, can't tell because it's a wall of text rather than a man page browser.
Now imagine you have to fix a b0rked system that can't display its own man pages. You're now stuck with this mess.
Meanwhile if you can't find man7.org (Google search results are only getting worse) and start browsing <https://docs.kernel.org>, it refers you to <https://www.kernel.org/doc/man-pages/> which refers you to <https://www.kernel.org/doc/man-pages/maintaining.html>, <https://www.kernel.org/doc/man-pages/missing_pages.html>, and Wikipedia - none of which seem to be relevant, can't tell because it's a wall of text rather than a man page browser.
Now imagine you have to fix a b0rked system that can't display its own man pages. You're now stuck with this mess.
> Complicated stuff = high probably of failure
This is a myth. The 787 has about 60 million miles of wiring in it. It is vastly more complicated than an airliner from the 1940s, and it also much, much safer. Poorly engineered technology fails, not necessarily complex technology
> secondary problem is the stacking of abstraction layers docker / kubersomething
Then don't use Kubernetes or Docker? They aren't mandatory
This is a myth. The 787 has about 60 million miles of wiring in it. It is vastly more complicated than an airliner from the 1940s, and it also much, much safer. Poorly engineered technology fails, not necessarily complex technology
> secondary problem is the stacking of abstraction layers docker / kubersomething
Then don't use Kubernetes or Docker? They aren't mandatory
Is any open source software or Linux distribution engineered to the level of the 787?
Yes. Boeing Onboard Network System (ONS) running on the Network File Server (NFS)?
It and its 787 sibling are highly customized Linux distros.
Aircraft include the 747-8, 787, some 737, ...
http://www.b737.org.uk/flightinstsmax-maint.htm
https://www.teledynecontrols.com/en-us/Product%20Brochures/T...
It and its 787 sibling are highly customized Linux distros.
Aircraft include the 747-8, 787, some 737, ...
http://www.b737.org.uk/flightinstsmax-maint.htm
https://www.teledynecontrols.com/en-us/Product%20Brochures/T...
No this is a common rule in industry in particular.
The more components you add a component into to a defined system (excepted for redundancy purpose), the higher the probability of failure.
This is exactly why Toyota provides tier A car in term of reliabily and majority of European / US car full of failures by adding a lot of useless gadget.
The more components you add a component into to a defined system (excepted for redundancy purpose), the higher the probability of failure.
This is exactly why Toyota provides tier A car in term of reliabily and majority of European / US car full of failures by adding a lot of useless gadget.
Alpine, Void, Devuan or Artix all would have allowed author to use Linux while addressing his points of concern. I don't think the BSD's have real advantages anymore since so much core performance stuff is in Linux first. When most of the software is available on all these platforms, it mostly comes down to user preference.
I run Linux, macOS, FreeBSD, and SmartOS/illumos in various capacities personal and professional.
Each has its own strengths, but I choose FreeBSD for home servers (shared file/media server. and network gateway), for a few specific reasons:
Each has its own strengths, but I choose FreeBSD for home servers (shared file/media server. and network gateway), for a few specific reasons:
- ZFS (on root, fully integrated tooling for jails, etc)
- More consistency/less churn in base system (great for set-and-forget systems)
- Ports/pkg (still better than any Linux pkg manager)Can you enumerate why ports/pkg is better than any package manager on Linux?
The first two are the exact reason I run FreeBSD on my home servers, too.
To add to your list, Debian can be configured at installation to not use systemd (this option pretty well mooted Devuan) and MX Linux uses an optional shim to run their Debian spinoff without it if chosen at the Grub menu on bootup.
[deleted]
I have tried several times to run FreeBSD on my home servers and every single time it fails to boot let alone run. Each happily runs Linux (with ZFS) all day long with no issues.
I know the project is smaller in scope and has less funding than Linux (distros and subprojects included) but it's kind of ridiculous. It's incredibly frustrating to set aside the time to set up a machine only to have the kernel panic half way through booting the install media.
From there it's an annoying and exhausting yak shaving exercise just trying to get the machine to start. Eventually I just give up and put the latest Ubuntu LTS which boots and installs with no problems. I import my ZFS pool and everything just hum along.
I cut my Unix teeth on FreeBSD 3 and 4. I want to use modern FreeBSD but it never seems to run on hardware I actually own. That's why I don't run FreeBSD on my home servers.
I know the project is smaller in scope and has less funding than Linux (distros and subprojects included) but it's kind of ridiculous. It's incredibly frustrating to set aside the time to set up a machine only to have the kernel panic half way through booting the install media.
From there it's an annoying and exhausting yak shaving exercise just trying to get the machine to start. Eventually I just give up and put the latest Ubuntu LTS which boots and installs with no problems. I import my ZFS pool and everything just hum along.
I cut my Unix teeth on FreeBSD 3 and 4. I want to use modern FreeBSD but it never seems to run on hardware I actually own. That's why I don't run FreeBSD on my home servers.
I've also found hardware support lacking. In my case SATA controller threw errors on FreeBSD and worked fine in Linux. It's something that's impossible for FreeBSD through because Linux has much more drivers, testers and eyes for exotic hardware. However there exist hardware compatibility lists and most common hardware is supported very well.
I really wanted to run FreeBSD for my home NUC firewall/router as I like the pf syntax, but had to give up in the end because it couldn’t drive the USB Ethernet adapter at 1 full Gbps speeds, whereas Linux had no problem with the same devices, so NixOS it is.
With the switch of TrueNAS to Linux, I have no more BSD at home, unfortunately.
With the switch of TrueNAS to Linux, I have no more BSD at home, unfortunately.
I have a machine which cannot boot neither Ubuntu nor Fedora, and nobody online seems to know why. Hardware support can be like that.
> ZFS is more efficient on FreeBSD (Insert Source)
FreeBSD and Linux share the same ZFS codebase, openzfs.
FreeBSD had its own zfs implementation but they had to drop it becayse they couldn't keep up with openzfs.
FreeBSD and Linux share the same ZFS codebase, openzfs.
FreeBSD had its own zfs implementation but they had to drop it becayse they couldn't keep up with openzfs.
They merged with openzfs to maintain a common base so Linux didn't venture off on its own, not because they couldn't keep up.
But Linux makes it a faff because the license is incompatible so you have to run it as a 3rd party module and the kernel devs regularly break it. With FreeBSD it’s already there and you know it will work.
That's only partially true.
The license is "compatible" enough to be shipped by distributions rather than kernel.
AFAIK, the thing is: no one has seriously decided to test the license compatibility (as in, test it in court) and everybody's essentially scared of Oracle dragging them through endless legal litigation. Oracle owns most/all the IP that came from Sun Microsystems and while ZFS/OpenZFS is CDDL licensed... Who wants to spend millions in legal fees to find out?
Canonical did (still does?) ship OpenZFS with Ubuntu but maybe they're not big enough for Oracle to go after them (who knows? the lawnmower works in misterious ways).
The license is "compatible" enough to be shipped by distributions rather than kernel.
AFAIK, the thing is: no one has seriously decided to test the license compatibility (as in, test it in court) and everybody's essentially scared of Oracle dragging them through endless legal litigation. Oracle owns most/all the IP that came from Sun Microsystems and while ZFS/OpenZFS is CDDL licensed... Who wants to spend millions in legal fees to find out?
Canonical did (still does?) ship OpenZFS with Ubuntu but maybe they're not big enough for Oracle to go after them (who knows? the lawnmower works in misterious ways).
My zfs never broke under Ubuntu and installation is easy by installing 1 package.
Lucky you
While they do share the same code base, personally (and therefore anecdotally) I have noticed an issue where on Linux with ZFS my programs will get OOM killed whereas they won't on FreeBSD+ZFS or on Linux+ext4. My theory was that the ARC pages on Linux weren't available for clearing under memory pressure whereas maybe they were in FreeBSD but that's just a guess. Hopefully someone knows more, but at least anecdotally even with the "same" ZFS code base, they can perform differently in situ.
For me, it's about friction vs total understanding. I accept that I don't know and won't know/understand everything.
I can install a relatively minimal Linux server (usually Ubuntu Server), disable snaps, install Docker community, copy my app directories (with docker-compose.yaml files in each) and `docker compose up -d` in each directory and be (back) up in moments. When I was trying a couple different hosts for mail delivery, the DNS changes took longer than server setup and copy/migration. It was pretty great.
It's also lead me to a point where I'm pretty happy or unhappy with given applications by how hard or easy a compose file for the app and it's dependencies are. Even if, like my mail server, the whole host is effectively for a single stack.
No, I'm not running more complex setups like Kubernetes or even Swarm... I'm just running apps mostly at home and on my hosted server. It's been pretty great for personal use.
For work, yeah, apps will be deployed via k8s. The main projects I'm on are slated for migration from deployed windows apps, mostly under IIS or Windows Services, to Linux/Docker.
I can install a relatively minimal Linux server (usually Ubuntu Server), disable snaps, install Docker community, copy my app directories (with docker-compose.yaml files in each) and `docker compose up -d` in each directory and be (back) up in moments. When I was trying a couple different hosts for mail delivery, the DNS changes took longer than server setup and copy/migration. It was pretty great.
It's also lead me to a point where I'm pretty happy or unhappy with given applications by how hard or easy a compose file for the app and it's dependencies are. Even if, like my mail server, the whole host is effectively for a single stack.
No, I'm not running more complex setups like Kubernetes or even Swarm... I'm just running apps mostly at home and on my hosted server. It's been pretty great for personal use.
For work, yeah, apps will be deployed via k8s. The main projects I'm on are slated for migration from deployed windows apps, mostly under IIS or Windows Services, to Linux/Docker.
Thought I agree with points of an author saying that it is wasteful to run 10 SQLs to run ten applications, I am not SYS admin and I do not want to spend few hours every week upgrading my software. With docker you do 'docker compose pull; docker compose up' and you done. You can do that via cron in every dir with your compose file and you are done.
In fact I think even that thing is still to complicated. We need one-click deploys, automatic updaters for Linux or FreeBsd or similar for regular people to be able to self host and own their data.
Having local pizzeria hosting its menu on Facebook is not a good thing. Having an online only calendar app as an only way to schedule haircut locally is not good thing. Having all your files stored on OneDrive or GoogleDrive is not a good thing.
If author thinks FreeBsd is better - cool. Then work on a solution for ordinary people to host file storage server using FreeBsd in a simple way.
Create simple wizard to install Nextcloud or Owncloud or mail sever on FreeBsd.
This post is true but it is just a rant that do not solves any real problems. One if them is that people do not want to manage servers. For better or worse - is beside the point.
In fact I think even that thing is still to complicated. We need one-click deploys, automatic updaters for Linux or FreeBsd or similar for regular people to be able to self host and own their data.
Having local pizzeria hosting its menu on Facebook is not a good thing. Having an online only calendar app as an only way to schedule haircut locally is not good thing. Having all your files stored on OneDrive or GoogleDrive is not a good thing.
If author thinks FreeBsd is better - cool. Then work on a solution for ordinary people to host file storage server using FreeBsd in a simple way.
Create simple wizard to install Nextcloud or Owncloud or mail sever on FreeBsd.
This post is true but it is just a rant that do not solves any real problems. One if them is that people do not want to manage servers. For better or worse - is beside the point.
What makes you think you have to spend "a few hours every week" to keep a FreeBSD setup up and running?
I have pretty much every server running from web server to mail server and I don't spend "a few hours" per YEAR to keep it running. about once a week I run a pkg update, pkg upgrade and service x reload in each jail to update the software and 99.9% of the time it works smoothly.It really doesn't get much simpler than that. This could also be done with cron like in your example, but I don't think automating updates is such a great idea. I think updates should be monitored.
I have a lot of confidence in the nginx/postfix/dovecot/etc developers ability to develop professional software.
FWIW I am also not a sysadmin.
I have pretty much every server running from web server to mail server and I don't spend "a few hours" per YEAR to keep it running. about once a week I run a pkg update, pkg upgrade and service x reload in each jail to update the software and 99.9% of the time it works smoothly.It really doesn't get much simpler than that. This could also be done with cron like in your example, but I don't think automating updates is such a great idea. I think updates should be monitored.
I have a lot of confidence in the nginx/postfix/dovecot/etc developers ability to develop professional software.
FWIW I am also not a sysadmin.
I think you reading to much into my comment. I did not meant that specifically FreeBsd needs an extra attention.
What I meant is that dockerizing your applications (which author of article seems to have a problem with) is easier from that point of view. There is no need to provide a package for each distribution or OS you want to support. You can bundle all the necessary dependencies if there are any (like i.e. databases which author provide as an example of unnecessary redundancy). There are solutions for web managing docker containers and stacks like Portainer, Taisun, Yacht and probably more I am not aware of. You have Watchtower and Diun for update notifications. So it is simpler for developers and partially for an user.
Maybe there are similar solutions for FreeBsd package manager, but this is only for FreeBsd. With docker it should work on every environment that can run docker. So again it is simpler.
You can run your services without docker and sometimes it is easier without it (i.e. running DLNA server) still, I would not want to run my email server as nginx/postfix/dovecot/sogo/mysql as separate services that I need to separately install, configure and update. There are dockerized solutions for that that exists already that you can start and run with docker + some DNS config. It is just easier.
If you are fine with your stack on FreeBsd it is totally fine, but there is a reason why less, or non-technical people are running commercial NAS devices like Synology. Because it is easier. And there is a reason why non-technical people are using Google Drive and iCloud for their needs like files sync, backups and email instead of running their own mail server and NAS: because it is easier.
So I do not have anything against FreeBsd and their native packages. But you wrote yourself:
> about once a week I run a pkg update, pkg upgrade and service x reload in each jail to update the software and 99.9% of the time it works smoothly. It really doesn't get much simpler than that.
Yes it does: web or phone app management. Why you have an app for every silly smart devices people are buying (like i.e. smart fridge or smart dishwasher)? Because it is easier for ordinary people. Samsung and LG do not make CLI for those to manage those devices via SSH. Maybe it would be even easier, once you are familiar with that, but people are not. Try to explain your hairdresser or plumber what is FreeBsd, pkg, jails and services.
> This could also be done with cron like in your example, but I don't think automating updates is such a great idea. I think updates should be monitored.
Which is exactly why I wrote that I, personally, do not want to spend few hours every week to upgrade and monitor upgrade process of all my devices. Especially since those are used by my family and I do not want to update them during a day, because they will be complaining that they can't use something. And I do not want to do that at night because I want to sleep. I you have nice solution for running 10 or 20 applications on FreeBsd, with very easy and quick update and backup process for them, please write about it. My solution takes about 2 hours every day for 4 devices and about 6 hours of update and backup - every day. But sending about of 2TB of data backups (even incremental) must take some time.
So, again, I agree with an author with few points but in an essence, I do not agree. I does not matter if you use FreeBsd, or Ubuntu or Debian or UnRaid for your self hosting needs. We need simpler solutions for self hosting for ordinary people.
What I meant is that dockerizing your applications (which author of article seems to have a problem with) is easier from that point of view. There is no need to provide a package for each distribution or OS you want to support. You can bundle all the necessary dependencies if there are any (like i.e. databases which author provide as an example of unnecessary redundancy). There are solutions for web managing docker containers and stacks like Portainer, Taisun, Yacht and probably more I am not aware of. You have Watchtower and Diun for update notifications. So it is simpler for developers and partially for an user.
Maybe there are similar solutions for FreeBsd package manager, but this is only for FreeBsd. With docker it should work on every environment that can run docker. So again it is simpler.
You can run your services without docker and sometimes it is easier without it (i.e. running DLNA server) still, I would not want to run my email server as nginx/postfix/dovecot/sogo/mysql as separate services that I need to separately install, configure and update. There are dockerized solutions for that that exists already that you can start and run with docker + some DNS config. It is just easier.
If you are fine with your stack on FreeBsd it is totally fine, but there is a reason why less, or non-technical people are running commercial NAS devices like Synology. Because it is easier. And there is a reason why non-technical people are using Google Drive and iCloud for their needs like files sync, backups and email instead of running their own mail server and NAS: because it is easier.
So I do not have anything against FreeBsd and their native packages. But you wrote yourself:
> about once a week I run a pkg update, pkg upgrade and service x reload in each jail to update the software and 99.9% of the time it works smoothly. It really doesn't get much simpler than that.
Yes it does: web or phone app management. Why you have an app for every silly smart devices people are buying (like i.e. smart fridge or smart dishwasher)? Because it is easier for ordinary people. Samsung and LG do not make CLI for those to manage those devices via SSH. Maybe it would be even easier, once you are familiar with that, but people are not. Try to explain your hairdresser or plumber what is FreeBsd, pkg, jails and services.
> This could also be done with cron like in your example, but I don't think automating updates is such a great idea. I think updates should be monitored.
Which is exactly why I wrote that I, personally, do not want to spend few hours every week to upgrade and monitor upgrade process of all my devices. Especially since those are used by my family and I do not want to update them during a day, because they will be complaining that they can't use something. And I do not want to do that at night because I want to sleep. I you have nice solution for running 10 or 20 applications on FreeBsd, with very easy and quick update and backup process for them, please write about it. My solution takes about 2 hours every day for 4 devices and about 6 hours of update and backup - every day. But sending about of 2TB of data backups (even incremental) must take some time.
So, again, I agree with an author with few points but in an essence, I do not agree. I does not matter if you use FreeBsd, or Ubuntu or Debian or UnRaid for your self hosting needs. We need simpler solutions for self hosting for ordinary people.
Switched to FreeBSD at home as well and it was such a wonderful decision.
As a long time Linux user, what was unexpected and eye-opening was seeing how FreeBSD does things. Somethings better and somethings worse. The better things are WAAYY better. And, for many of those things that felt better, in summary it's really the culmination of the entire ecosystem. The whole package is just better to me. The cohesive system is really a killer app. Oh, and pf is great too.
I havn't given up on linux; it's just running as a VM in bhyve now.
I also run Freebsd on a Thinkpad T490 laptop. Works great.
As a long time Linux user, what was unexpected and eye-opening was seeing how FreeBSD does things. Somethings better and somethings worse. The better things are WAAYY better. And, for many of those things that felt better, in summary it's really the culmination of the entire ecosystem. The whole package is just better to me. The cohesive system is really a killer app. Oh, and pf is great too.
I havn't given up on linux; it's just running as a VM in bhyve now.
I also run Freebsd on a Thinkpad T490 laptop. Works great.
> Overall system reliability is therefore the product of the individual reliability of each component.
Is that true? All you need is one bad mosfet and all the other components fine, zero reliability. Doesn't a M x N matrix with only one extreme value average out from many samples over time?
Is that true? All you need is one bad mosfet and all the other components fine, zero reliability. Doesn't a M x N matrix with only one extreme value average out from many samples over time?
> TLDR : the main problem is SYSTEMD
I couldn't agree more.
Its a testament that this s/w is _still_ NOT LIKED by so many people.
I've been a linux on the desktop, FreeBSD for the server user/admin for over 20 years.
It's a great combination...
I couldn't agree more.
Its a testament that this s/w is _still_ NOT LIKED by so many people.
I've been a linux on the desktop, FreeBSD for the server user/admin for over 20 years.
It's a great combination...
For some reason the silverbullet link in the website is broken if I copy it or just click it. But typing the exact same thing works.
The article link is wrong.
https://siliverbullet.md/
It should be below (without the extra “i”):
https://silverbullet.md/
https://siliverbullet.md/
It should be below (without the extra “i”):
https://silverbullet.md/
Oh, I didn't see the typo. Thanks!
Docker is an excellent tool, especially when used with SELinux enabled. It offers process isolation, resource restrictions, and reproducibility. While similar isolation can be achieved with chroot or jails, these methods lack reproducibility. Additionally, managing updates in chroot and jails can be quite challenging compared to Docker or Portainer.
Jails and chroot is a big no-no for CI/CD, in my opinion also the reason no one use it.
Curious what “home servers” are really for. I’ve gone decades without needing a home server — what am I missing out on?
I've thrown "home server workloads" at my Mac mini. It stays on 24/7 anyway, because idle power draw is negligible.
Syncthing is a great use case. Wherever I take my laptop, the files stay in sync between the two devices; I don't need a third device to act as a server, or iCloud, or any other cloud.
Miniflux. I read my RSS feeds from three devices, so I want to track read status and save bookmarks. It provides a Google Reader-compatible API (yes it lives on), so I can plug NetNewsWire into it.
It's an exit node for Tailscale. Did I mention Tailscale? It's like still being on the same LAN anywhere you go. It doesn't matter if your home server doesn't have a public IP.
Grafana is cool for anything you can plot, as long as you can mash it into something vaguely resembling a time series. Sensor readings, data pulled from some API, CSV export from your bank, your chess ELO, etc. It's often combined with Prometheus. So you can also scrape anything that speaks enough HTTP (which is... many things, these days).
I want to explore something like Navidrome or Jellyfin; for now I use Syncthing for my music library, but even if I could run it on iPhone, the whole collection wouldn't fit. Unfortunately it seems there are no decent apps.
You're also free to explore uncharted territory. Rubenerd is hosting a "house-wide" SQL database: <https://rubenerd.com/our-personal-database/>
Syncthing is a great use case. Wherever I take my laptop, the files stay in sync between the two devices; I don't need a third device to act as a server, or iCloud, or any other cloud.
Miniflux. I read my RSS feeds from three devices, so I want to track read status and save bookmarks. It provides a Google Reader-compatible API (yes it lives on), so I can plug NetNewsWire into it.
It's an exit node for Tailscale. Did I mention Tailscale? It's like still being on the same LAN anywhere you go. It doesn't matter if your home server doesn't have a public IP.
Grafana is cool for anything you can plot, as long as you can mash it into something vaguely resembling a time series. Sensor readings, data pulled from some API, CSV export from your bank, your chess ELO, etc. It's often combined with Prometheus. So you can also scrape anything that speaks enough HTTP (which is... many things, these days).
I want to explore something like Navidrome or Jellyfin; for now I use Syncthing for my music library, but even if I could run it on iPhone, the whole collection wouldn't fit. Unfortunately it seems there are no decent apps.
You're also free to explore uncharted territory. Rubenerd is hosting a "house-wide" SQL database: <https://rubenerd.com/our-personal-database/>
On mine I run calibre, jellyfin, openbooks, and Samba to share files out. All my other computers backup to my home server and it has a process to deal with incremental and offsite (btrfs snapshots and b2).
I also use it from my other computers via ssh to access git, irc, keepass, and whatever else tickles my fancy.
I also use it from my other computers via ssh to access git, irc, keepass, and whatever else tickles my fancy.
Controlling your data, instead of giving it to some SaaS. But unless you day job is sysadmin, better treat it as a hobby that takes some time and effort, not a free alternative.
File server, Syncthing, Home Assistant, Cameras/NVR.
For all those things you really shouldn't trust "the cloud"
For all those things you really shouldn't trust "the cloud"
I use both a home server and a cloud VM, and they work together. I'm thankfully able to use FreeBSD 14 on my cloud VM (just a preference).
I push data from my home server for easy access on my cloud VM. For example, weather data from my weather station, images/time-lapses from my weather cam. I have no ports open to my home network. Basically just fun stuff without exposing my home network.
I use the cloud VM as an SSH "jump box" into my home network. My OpenBSD box sets up a remote SSH tunnel port. I can then use the SSH -J option to jump through the cloud VM into that home OpenBSD box (as well as chain "jumps" to other home servers).
I push data from my home server for easy access on my cloud VM. For example, weather data from my weather station, images/time-lapses from my weather cam. I have no ports open to my home network. Basically just fun stuff without exposing my home network.
I use the cloud VM as an SSH "jump box" into my home network. My OpenBSD box sets up a remote SSH tunnel port. I can then use the SSH -J option to jump through the cloud VM into that home OpenBSD box (as well as chain "jumps" to other home servers).
* This way I don't need any home server to trust a cloud VM.
* This mostly is for checking on my Home Assistant instance.
* I've also fixed some things remotely with an SSH session.
You’re leaking all the domain you’re accessing?
Are all your data in clouds that are scanned for AI training etc? All your email are belongs to the big corps?
By now they know about yourself more than you do.
You’re not the one missing, you’re just giving it away.
Plex and pihole are basically production services on my home network. If something goes wrong I get a Sev 1 page from my wife and kids :)
I have a few use cases and a few servers for them:
My router/firewall is a NUC PC plugged straight into the fibre ONT. It also runs DHCP and DNS (both my home zone and acting as a caching resolver with a huge cache for the wider internet which means really snappy DNS lookups compared to using ISP servers).
My NAS is an eight core server with 64GB ECC ram running a ZFS pool with 8 12TB WD Red Pro drives for storing my collection of curated Linux ISOs, running TrueNAS SCALE, running always-on services inside containers:
- PostgreSQL for a bunch of personal project databases
- TeslaMate collecting data from our EVs into the PostgreSQL database
- Plex for serving up media to the Apple TV
- Tailscale exit node so I can access my home network on the go
- Step CA for managing my personal certificate authority used to issue everything I want to have TLS for with a certificate easily (LetsEncrypt doesn’t work for private network servers)
- Tarsnap for periodically backing up all data, documents and configuration I really do not want to lose
- UniFi controller managing my UniFi APs (four of them)
I’m sure I will have more use cases in the future, but it’s really handy to have always running infrastructure and storage at home you can rely on!
And I don’t spend much time tinkering with it now that it’s set up, it’s just maintenance mode.
From time to time I adjust a few configs or upgrade a hardware component here and there but it’s been stable like this for years (apart from the TrueNAS CORE to SCALE migration which was a bit of a shitshow due to moving from FreeBSD to Linux, had to rebuild all jails into Docker containers).
My NAS is an eight core server with 64GB ECC ram running a ZFS pool with 8 12TB WD Red Pro drives for storing my collection of curated Linux ISOs, running TrueNAS SCALE, running always-on services inside containers:
- PostgreSQL for a bunch of personal project databases
- TeslaMate collecting data from our EVs into the PostgreSQL database
- Plex for serving up media to the Apple TV
- Tailscale exit node so I can access my home network on the go
- Step CA for managing my personal certificate authority used to issue everything I want to have TLS for with a certificate easily (LetsEncrypt doesn’t work for private network servers)
- Tarsnap for periodically backing up all data, documents and configuration I really do not want to lose
- UniFi controller managing my UniFi APs (four of them)
I’m sure I will have more use cases in the future, but it’s really handy to have always running infrastructure and storage at home you can rely on!
And I don’t spend much time tinkering with it now that it’s set up, it’s just maintenance mode.
From time to time I adjust a few configs or upgrade a hardware component here and there but it’s been stable like this for years (apart from the TrueNAS CORE to SCALE migration which was a bit of a shitshow due to moving from FreeBSD to Linux, had to rebuild all jails into Docker containers).
Mine is running, in no particular order:
* UrBackup for all of the host systems in the home to backup to
* Plex for home movies
* HomeAssistant
* OpenThread Border Router
* Zigbee2MQTT
* Matter Server
* PostgreSQL (for HA)
* InfluxDB (for long term statistics from HA)
* EMHASS (linear optimizer to maximise profit on my Solar PV + Battery system)
* Minecraft server for the kids
* Mosquitto MQTT broker
* TeslaMate for car data
In my case, the heaviest use is HomeAssistant - every light in the house has smarts, either directly, or through smart relays. Telling my energy provider how much charge to add to the EV's so they schedule it and I only pay 7p per kWh during the dispatching windows. Managing energy flow in the house (charge battery? discharge battery? only charge battery from solar that would otherwise be curtailed due to a 5kW export limit) etc. etc.
It's running in a short depth 2U rackmount chassis inside my network rack, with 6 4TB drives running in RaidZ2 and offsite backups which are aided by a 1Gbps symmetric FTTP connection.
* UrBackup for all of the host systems in the home to backup to
* Plex for home movies
* HomeAssistant
* OpenThread Border Router
* Zigbee2MQTT
* Matter Server
* PostgreSQL (for HA)
* InfluxDB (for long term statistics from HA)
* EMHASS (linear optimizer to maximise profit on my Solar PV + Battery system)
* Minecraft server for the kids
* Mosquitto MQTT broker
* TeslaMate for car data
In my case, the heaviest use is HomeAssistant - every light in the house has smarts, either directly, or through smart relays. Telling my energy provider how much charge to add to the EV's so they schedule it and I only pay 7p per kWh during the dispatching windows. Managing energy flow in the house (charge battery? discharge battery? only charge battery from solar that would otherwise be curtailed due to a 5kW export limit) etc. etc.
It's running in a short depth 2U rackmount chassis inside my network rack, with 6 4TB drives running in RaidZ2 and offsite backups which are aided by a 1Gbps symmetric FTTP connection.
On mine I run:
- Kavita and Jellyfin to self-host my books, comics, movies and TV. Self hosting is particularly important for non-Hollywood/non-US-centric media which routinely disappears from the internet.
- A custom webapp to self-host my photos (if I did it again today I'd use Immich)
- Gitea to self-host a few Git repos
- A GPU so I can use it remotely to offload AI/ML workloads from my laptop
It is networked with my ither devices via Tailscale so me, my friends and family can access it from everywhere. It is like having a private Netflix, Kindle, Google Photos and Comixology/MangaReader that allows any media to be downloaded to read offline.
I also have second Windows server used for hosting dedicated servers for video games.
- Kavita and Jellyfin to self-host my books, comics, movies and TV. Self hosting is particularly important for non-Hollywood/non-US-centric media which routinely disappears from the internet.
- A custom webapp to self-host my photos (if I did it again today I'd use Immich)
- Gitea to self-host a few Git repos
- A GPU so I can use it remotely to offload AI/ML workloads from my laptop
It is networked with my ither devices via Tailscale so me, my friends and family can access it from everywhere. It is like having a private Netflix, Kindle, Google Photos and Comixology/MangaReader that allows any media to be downloaded to read offline.
I also have second Windows server used for hosting dedicated servers for video games.
Serving pirated media files in a way that's similar-enough to Netflix for normies in your house to use it comfortably.
An always-on machine to handle recurring tasks (remote backups, say).
Maybe a VPN gateway (you can also just use an AppleTV for that, though, with Tailscale)
Home automation if HomeKit isn't your thing, for whatever reason.
Network-wide adblocking, custom DNS, et c.
You really, really don't need one. But they can be nice.
Also some people just like tinkering. Can't relate (any more) but I've got my thing down to requiring single-digit hours per year.
[EDIT] Of course, part of how I avoid making it more work is that I don't upgrade the core OS, since it has minimal exposure to public networks and everything I care about comes from Docker so IDGAF how old the package collection is. Especially with ZFS in play, upgrades are... fraught. At some point whatever old-ass Debian I have on there will be too old and I'll have to, IDK, image the whole base OS disk as a backup and spend probably a whole weekend screwing with it when it inevitably breaks itself on upgrade. I may just migrate to FreeBSD instead, when the time comes.
An always-on machine to handle recurring tasks (remote backups, say).
Maybe a VPN gateway (you can also just use an AppleTV for that, though, with Tailscale)
Home automation if HomeKit isn't your thing, for whatever reason.
Network-wide adblocking, custom DNS, et c.
You really, really don't need one. But they can be nice.
Also some people just like tinkering. Can't relate (any more) but I've got my thing down to requiring single-digit hours per year.
[EDIT] Of course, part of how I avoid making it more work is that I don't upgrade the core OS, since it has minimal exposure to public networks and everything I care about comes from Docker so IDGAF how old the package collection is. Especially with ZFS in play, upgrades are... fraught. At some point whatever old-ass Debian I have on there will be too old and I'll have to, IDK, image the whole base OS disk as a backup and spend probably a whole weekend screwing with it when it inevitably breaks itself on upgrade. I may just migrate to FreeBSD instead, when the time comes.
[deleted]
[deleted]
come for the reminder to try FreeBSD some time again, read light systemd bashing (can't be harmed at that point), stay for managing Jails backup through.. NocoDB :) Stunning travel photography btw!
... and if someone looks for more reasons 'why' FreeBSD then here they are:
- https://vermaden.wordpress.com/2020/09/07/quare-freebsd/
- https://vermaden.wordpress.com/2020/09/07/quare-freebsd/
Does it support GPU computing?
Just another “I don’t like systemd and refuse to understand it” rant.
I can’t think of any change that has improved my Linux sysadmin experience more than the move to systemd.
Is it complicated? Perhaps it is. But this FUD about it being resource intensive or unreliable or difficult to use is complete nonsense.
And on top of that systemd isn’t even “Linux.” Plenty of popular production-ready distros like Alpine Linux don’t even use it.
And of course I’m not saying FreeBSD is bad, but I’m not the one writing and publishing an article bashing a system I don’t understand.
I can’t think of any change that has improved my Linux sysadmin experience more than the move to systemd.
Is it complicated? Perhaps it is. But this FUD about it being resource intensive or unreliable or difficult to use is complete nonsense.
And on top of that systemd isn’t even “Linux.” Plenty of popular production-ready distros like Alpine Linux don’t even use it.
And of course I’m not saying FreeBSD is bad, but I’m not the one writing and publishing an article bashing a system I don’t understand.
I do understand systemd well. It’s not great. But less terrible than the pile of crap it replaced. And that’s probably good enough.
FUD? No. There are plenty of people on plenty of sites asking, "How do I do this very simple thing using systemd?", along with plenty of answers which depend on which distro it is, how recent it is, et cetera.
For instance, DNS handling and NTP keep coming up over and over, and it's almost becoming a meme. Why? Because it's the Microsoft mentality - we (the systemd people) know better than you (you're just the machine's owner and administrator), and we'll take care of this. You want to? Not without a fight.
So no, it's not FUD when reasonable people can't give reasonable answers for how to do something that's otherwise reasonably simple.
For instance, DNS handling and NTP keep coming up over and over, and it's almost becoming a meme. Why? Because it's the Microsoft mentality - we (the systemd people) know better than you (you're just the machine's owner and administrator), and we'll take care of this. You want to? Not without a fight.
So no, it's not FUD when reasonable people can't give reasonable answers for how to do something that's otherwise reasonably simple.
1. Plenty of sites ask all kinds of questions that depend on which distro is it, how recent is it, etc. This doesn't mean that systemd is bad because the answers change over time.
2. DNS handling and NTP comes up over and over...for who exactly? I work with Linux as a full-time job and this has never come up as a pain point.
3. This "Microsoft mentality" thing is such a 2014 argument about systemd. Basically because systemd didn't perfectly conform to "the UNIX philosophy," we are assuming that they are evil bastards like Microsoft. E.g., journalctl had the gall to make a queryable logging system, and because that concept has some passing similarties the Windows Event Viewer it must be bad. If Linux Torvalds has a strong opinionated design on something and refuses a contribution to the Linux kernel, that's cool because he's Enlightened Tech Jesus, but if systemd's maintainers dare to have opinionated design they are draconian Microsoft employees. And again no significant controversial event has happened since that 2014/2015 era of systemd when, really, the software was much older and less mature at that time so disagreements were understandable.
4. Again you claim there are no reasonable answers for how to do "something," when really there are. If nobody knew the answers it wouldn't be the init system for pretty much every big name Linux distro out there (Ubuntu...Red Hat...Fedora...Amazon Linux...Oracle...Arch...SteamOS...)
2. DNS handling and NTP comes up over and over...for who exactly? I work with Linux as a full-time job and this has never come up as a pain point.
3. This "Microsoft mentality" thing is such a 2014 argument about systemd. Basically because systemd didn't perfectly conform to "the UNIX philosophy," we are assuming that they are evil bastards like Microsoft. E.g., journalctl had the gall to make a queryable logging system, and because that concept has some passing similarties the Windows Event Viewer it must be bad. If Linux Torvalds has a strong opinionated design on something and refuses a contribution to the Linux kernel, that's cool because he's Enlightened Tech Jesus, but if systemd's maintainers dare to have opinionated design they are draconian Microsoft employees. And again no significant controversial event has happened since that 2014/2015 era of systemd when, really, the software was much older and less mature at that time so disagreements were understandable.
4. Again you claim there are no reasonable answers for how to do "something," when really there are. If nobody knew the answers it wouldn't be the init system for pretty much every big name Linux distro out there (Ubuntu...Red Hat...Fedora...Amazon Linux...Oracle...Arch...SteamOS...)
I'm only still on Linux for my server because Docker saves me from having to interact with systemd at all. Or, indeed, from caring very much what distro I'm even on.
If you ever consider switching to Podman, you’ll be surprised to see how it kinda pushes you back to systemd.
I try never to mess with my stack unless something breaks so badly that changing it is necessary. This hasn't happened yet in... six years, for my current server? This is the first time I've had a "home server" that's more value than the cost of maintaining it, and frankly it's because I neglect the hell out of it and resist any urge to go make things "better" just-because. And because of the isolation of Docker images from the awful mixed-together system-and-userspace distro package manager—I can upgrade any daemon I care about with a tiny edit to a shell script and a couple commands, works every time, never fucks up my base system or other unrelated daemons due to any stupid crap like sometimes happens when you try to get newer packages on an older version of a Linux distro.
Docker's just a package manager and process manager, the way I use it, and has performed flawlessly in that role.
Docker's just a package manager and process manager, the way I use it, and has performed flawlessly in that role.
systemd is indeed awesome. i'd rather kms than go back to maintaining init.d scripts.
> systemd is indeed awesome. i'd rather kms than go back to maintaining init.d scripts.
systemd-as-init-replacement was probably fine. systemd-as-kitchen-sink can get annoying.
systemd-as-init-replacement was probably fine. systemd-as-kitchen-sink can get annoying.
But where does the init system end and the kitchen-sink begin? For instance do you consider networking to be part of init or is it something else. For me, I bring network up in initramfs, so it's definitely part of my init.
The only truly bad systemd-* I've worked with is systemd-journald. Which often fails to contain log entries that should be present or simply just corrupts itself.
The only truly bad systemd-* I've worked with is systemd-journald. Which often fails to contain log entries that should be present or simply just corrupts itself.
> But where does the init system end and the kitchen-sink begin?
resolved, timesyncd, homed, journald, networkd (was very happy with Debian's interfaces(5)). Never thought of mounting file systems as process control, so also add mounting and taking over fstab. Given the ever-growing number of 'sub-systems', I'm sure new ones have been created that I'm not aware of. (I'm personally most regularly annoyed by resolved, especially as a server sysadmin where I need DNS to be deterministic, and not clever: I've gotten to the point of doing a chattr +i /etc/resolv.conf.)
I'm waiting for a systemd-mail so Zawinski's Law can be fulfilled:
* https://en.wikipedia.org/wiki/Jamie_Zawinski#Zawinski's_Law
> For me, I bring network up in initramfs, so it's definitely part of my init.
I've run Solaris, IRIX, BSD, and 1990s Linux, and I've never thought of networking as related to process control (init).
resolved, timesyncd, homed, journald, networkd (was very happy with Debian's interfaces(5)). Never thought of mounting file systems as process control, so also add mounting and taking over fstab. Given the ever-growing number of 'sub-systems', I'm sure new ones have been created that I'm not aware of. (I'm personally most regularly annoyed by resolved, especially as a server sysadmin where I need DNS to be deterministic, and not clever: I've gotten to the point of doing a chattr +i /etc/resolv.conf.)
I'm waiting for a systemd-mail so Zawinski's Law can be fulfilled:
* https://en.wikipedia.org/wiki/Jamie_Zawinski#Zawinski's_Law
> For me, I bring network up in initramfs, so it's definitely part of my init.
I've run Solaris, IRIX, BSD, and 1990s Linux, and I've never thought of networking as related to process control (init).
Just one example of what I like about systemd, and maybe you can call me new school, but I've really grown to like journald/journalctl.
Having systemd units automatically categorized and queryable has been very nice (the -u flag). The tag flag has also been great for me.
The --since and --until flags are godsends, I don't really care to waste time converting timestamps in my brain when all I want to do is do something like journalctl -u my_service --since yesterday --until today.
To me a way to centralize logs and have a tool like this to query them in a relatively advanced way is a major benefit.
I find that the complaints about systemd are mainly about UNIX philosphy and not about the actual functionality and benefits of those design choices. It seems like even mentioning that it's good brings back all these 2014 arguments about it.
You brought up mounting, the second paragraph of the systemd-mount manual quite clearly explains the benefit and what makes it different than the lower level mount command. And really it's not like systemd is ripping away your old tools especially in that particular case.
Having systemd units automatically categorized and queryable has been very nice (the -u flag). The tag flag has also been great for me.
The --since and --until flags are godsends, I don't really care to waste time converting timestamps in my brain when all I want to do is do something like journalctl -u my_service --since yesterday --until today.
To me a way to centralize logs and have a tool like this to query them in a relatively advanced way is a major benefit.
I find that the complaints about systemd are mainly about UNIX philosphy and not about the actual functionality and benefits of those design choices. It seems like even mentioning that it's good brings back all these 2014 arguments about it.
You brought up mounting, the second paragraph of the systemd-mount manual quite clearly explains the benefit and what makes it different than the lower level mount command. And really it's not like systemd is ripping away your old tools especially in that particular case.
> Just one example of what I like about systemd, and maybe you can call me new school, but I've really grown to like journald/journalctl.
Except the file format does not seem to be ACID and can get corrupted, so if the system crashes you may lose the reasons for said crash. This is strange since SQLite was available at the time, so I'm not sure why they didn't use a battle-tested, known-good format; Howard Chu (of OpenLDAP, etc):
* https://www.linkedin.com/pulse/20140924071300-170035-why-you...
> To me a way to centralize logs and have a tool like this to query them in a relatively advanced way is a major benefit.
Centralizing logs from my perspective is sending them to a central host, which last time I checked, journald could not do, so I have to run (r)syslogd regardless to do off-host log-shipping.
And it's easy enough to tell (r)syslogd to put everything in one file (which is the default on some distros) and optionally do separate file at times. With the added benefit of not necessarily having all of your eggs in one binary basket. And if you want a query-able logging API, you can do that too:
* https://www.rsyslog.com/doc/configuration/modules/omlibdbi.h...
* https://syslog-ng.github.io/admin-guide/070_Destinations/270...
> I find that the complaints about systemd are mainly about UNIX philosphy and not about the actual functionality and benefits of those design choices.
My complaint about systemd is about tight coupling between components. If someone finds limitations with (e.g.) journald, how do they swap it out or write a replacement? If the systemd folks want to have their own logging system that's fine, but why won't they architect things so it can be swapped out?
> And really it's not like systemd is ripping away your old tools especially in that particular case.
You mean like udev which used to be in a separate repo but the systemd folks took and tightly coupled?
* https://en.wikipedia.org/wiki/Udev#History
Except the file format does not seem to be ACID and can get corrupted, so if the system crashes you may lose the reasons for said crash. This is strange since SQLite was available at the time, so I'm not sure why they didn't use a battle-tested, known-good format; Howard Chu (of OpenLDAP, etc):
* https://www.linkedin.com/pulse/20140924071300-170035-why-you...
> To me a way to centralize logs and have a tool like this to query them in a relatively advanced way is a major benefit.
Centralizing logs from my perspective is sending them to a central host, which last time I checked, journald could not do, so I have to run (r)syslogd regardless to do off-host log-shipping.
And it's easy enough to tell (r)syslogd to put everything in one file (which is the default on some distros) and optionally do separate file at times. With the added benefit of not necessarily having all of your eggs in one binary basket. And if you want a query-able logging API, you can do that too:
* https://www.rsyslog.com/doc/configuration/modules/omlibdbi.h...
* https://syslog-ng.github.io/admin-guide/070_Destinations/270...
> I find that the complaints about systemd are mainly about UNIX philosphy and not about the actual functionality and benefits of those design choices.
My complaint about systemd is about tight coupling between components. If someone finds limitations with (e.g.) journald, how do they swap it out or write a replacement? If the systemd folks want to have their own logging system that's fine, but why won't they architect things so it can be swapped out?
> And really it's not like systemd is ripping away your old tools especially in that particular case.
You mean like udev which used to be in a separate repo but the systemd folks took and tightly coupled?
* https://en.wikipedia.org/wiki/Udev#History
[deleted]
> Given the ever-growing number of 'sub-systems', I'm sure new ones have been created that I'm not aware of.
Found one, repartitioning:
* https://www.freedesktop.org/software/systemd/man/latest/syst...
Found one, repartitioning:
* https://www.freedesktop.org/software/systemd/man/latest/syst...
The classic init.d scripts with start/stop functions and pidfiles are awful indeed. I cannot comprehend why they didn't use the openrc approach, which actually looks a lot like systemd, except it's a bunch of shell variables. The root problem is programs that insist on daemonizing themselves. Systemd solves this with the brute force of cgroups.
The way I see it, other init systems had 20 years to come up with a reliable model, but they didn't, and as is usual in FOSS, whoever actually writes the damn thing, decides how it looks.
The way I see it, other init systems had 20 years to come up with a reliable model, but they didn't, and as is usual in FOSS, whoever actually writes the damn thing, decides how it looks.
granted I'm sort of doing it via TrueNAS I suppose.
TL;DR "the major component that is primarily made to make managing servers and services easier and providing good journalling on Linux, systemd, makes me uncomfortable." which is quite the litmus test for stubborn sysadmin that didn't deploy anything remotely complex.
I'm on the opposite camp. If FreeBSD can provide a systemd-like service and device management software, then I would switch to it.
I'm on the opposite camp. If FreeBSD can provide a systemd-like service and device management software, then I would switch to it.
Would https://jdebp.uk/Softwares/nosh/ suffice?
> The biggest issue with FreeBSD : The very bad habbit of developper to deploy OpenSource software only with Docker
Holy smokes, that's quite biased!
Good on the author for having strong beliefs, but in my eyes containers avoid entire categories of problems, like: https://blog.kronis.dev/user/pages/blog/oracle-jdk-and-openj... (request processing times for a random system at work ages ago under load tests, it ran passably in OpenJDK, whereas running with the Oracle JDK resulted in an order of magnitude worse performance, this was before containers were introduced in the project; guess which vendor's version was installed in prod without telling us about it)
It was an old post, but sometimes there's configurations that do break in mysterious ways when the dependencies and the runtime environments aren't matched exactly to what was developed/tested against; see the whole reproducible software movement, can have good install scripts and other tools to help even without containers, but good luck managing the support matrix of a bunch of separate *nix distros and OSes, as well as having testing environments for those. Not even that much of an enterprise concern.
We shouldn't need containers for everything, but there aren't that many other good options for packaging software.
> There is a new fashion on the OpenSource world. Developpers think Docker is the new de-facto standard and only propose to install the tools with Docker.
It shouldn't be the only way, but I'll take Docker over random shell scripts and the ability to easily launch software and then later tear it down without messing up my host OS or having to mess around with VMs. Tbh, I do kind of wish that Vagrant had caught on more.
> Most of the time they do no provide any DOCUMENTATION to install their software in a baremetal way.
> At best, they offer an .rpm or .deb package for installation on a non-docker OS. But most of the time it's a docker file.
The Dockerfile is more or less living documentation, which is better than having a source code repo with nothing but obviously worse than someone taking the time of the day to write some guides or docs. Then again, if it's FOSS devs, then I'll take anything over nothing, given how much time they (don't) have.
> Even worse, modern applications often deploy the code and database needed to run the code directly in the docker compose file.
Deploying DBs or even multiple separate apps within a single container is pretty much an anti-pattern (anyone who has needed to decipher what happens inside of a GitLab Omnibus image, or update the Sonatype Nexus image from the embedded OrientDB to PostgreSQL probably understands the pain) and should be avoided, maybe save for rare cases like a web server with PHP-FPM (maybe with supervisord) if you really need to, or for the lazy/testing setups that will ultimately be a mess to maintain.
Edit: however if the complaint is literally just about having a Docker Compose file which contains a self-contained DB container, then it's up to you to decide whether you want or don't want to use it, or reference another DB running on the host or elsewhere (e.g. host.docker.internal or equivalent). It doesn't take much work to comment out a block.
> At what point did these people think it was relevant to run 10 different databases when I'm hosting 10 applications ?
You don't have to. You could have a single PostgreSQL or MariaDB/MySQL instance that just has multiple users and DBs/schemas. I honestly prefer the more distributed setup because I now can move software across servers trivially and can update the versions as I please and when something misbehaves, the impact is limited (because you can set CPU/RAM limits, easier than with cgroups).
Good for the author for enjoying FreeBSD, it's a pretty cool OS and feels more like it's "designed" instead of the more organic feel of how Linux distros work.
But I reject the motionally charged language and stance.
Holy smokes, that's quite biased!
Good on the author for having strong beliefs, but in my eyes containers avoid entire categories of problems, like: https://blog.kronis.dev/user/pages/blog/oracle-jdk-and-openj... (request processing times for a random system at work ages ago under load tests, it ran passably in OpenJDK, whereas running with the Oracle JDK resulted in an order of magnitude worse performance, this was before containers were introduced in the project; guess which vendor's version was installed in prod without telling us about it)
It was an old post, but sometimes there's configurations that do break in mysterious ways when the dependencies and the runtime environments aren't matched exactly to what was developed/tested against; see the whole reproducible software movement, can have good install scripts and other tools to help even without containers, but good luck managing the support matrix of a bunch of separate *nix distros and OSes, as well as having testing environments for those. Not even that much of an enterprise concern.
We shouldn't need containers for everything, but there aren't that many other good options for packaging software.
> There is a new fashion on the OpenSource world. Developpers think Docker is the new de-facto standard and only propose to install the tools with Docker.
It shouldn't be the only way, but I'll take Docker over random shell scripts and the ability to easily launch software and then later tear it down without messing up my host OS or having to mess around with VMs. Tbh, I do kind of wish that Vagrant had caught on more.
> Most of the time they do no provide any DOCUMENTATION to install their software in a baremetal way.
> At best, they offer an .rpm or .deb package for installation on a non-docker OS. But most of the time it's a docker file.
The Dockerfile is more or less living documentation, which is better than having a source code repo with nothing but obviously worse than someone taking the time of the day to write some guides or docs. Then again, if it's FOSS devs, then I'll take anything over nothing, given how much time they (don't) have.
> Even worse, modern applications often deploy the code and database needed to run the code directly in the docker compose file.
Deploying DBs or even multiple separate apps within a single container is pretty much an anti-pattern (anyone who has needed to decipher what happens inside of a GitLab Omnibus image, or update the Sonatype Nexus image from the embedded OrientDB to PostgreSQL probably understands the pain) and should be avoided, maybe save for rare cases like a web server with PHP-FPM (maybe with supervisord) if you really need to, or for the lazy/testing setups that will ultimately be a mess to maintain.
Edit: however if the complaint is literally just about having a Docker Compose file which contains a self-contained DB container, then it's up to you to decide whether you want or don't want to use it, or reference another DB running on the host or elsewhere (e.g. host.docker.internal or equivalent). It doesn't take much work to comment out a block.
> At what point did these people think it was relevant to run 10 different databases when I'm hosting 10 applications ?
You don't have to. You could have a single PostgreSQL or MariaDB/MySQL instance that just has multiple users and DBs/schemas. I honestly prefer the more distributed setup because I now can move software across servers trivially and can update the versions as I please and when something misbehaves, the impact is limited (because you can set CPU/RAM limits, easier than with cgroups).
Good for the author for enjoying FreeBSD, it's a pretty cool OS and feels more like it's "designed" instead of the more organic feel of how Linux distros work.
But I reject the motionally charged language and stance.
Look, as someone running a mix of bsd and linux machines...
The only salient point in this entire article is that BSD typically is less convoluted as a system (and as a consequence... usually less capable and less supported).
I find absolutely all of the other points to be "easy cop outs". They're there to provide him a mental justification for doing the thing he wants to do anyways, without actually justifying his logic or challenging any assumptions.
---
Case in point - I used to point all (most of) my hosted services at a single database. It genuinely sucked. It's a larger backup, it's a larger restore, if it goes down everything is down, and you better hope all the software you're hosting supports your preferred DB (hah - they won't, half will use postgres, half will use mysql, and half of the mysql half will actually be using mariadb, and I'm ignoring the annoying group that won't properly support a networked db at all and don't understand why I'm frustrated they only support sqlite).
You know the only thing it was actually doing for me? Marginally simplifying deployment, usually at first time setup.
You know what else the author of this post is trashing? Some pretty good tools for simplifying deployments.
Turns out... if spinning up a database is 3-10 lines in a config file, and automatic backups are super simple to configure with your deployment tool (see - all those k8s things he's bashing)... You don't even feel this pain at all.
---
Basically - This is a lazy argument.
Perfectly fine personal preference (I also sometimes enjoy the simplicity of my freeBSD machines, and I run opnsense for a reason).
But a trash argument against the things he's railing against.
Switching to k3s and running kubernetes was a a pretty giant time sink to get online (think maybe 25 hours) - but since it's come online... I've never had an easier time managing my home services.
Deployment is SO fucking simple, no one machine going down takes any service down, I get automatic backups, easy storage monitoring (longhorn and NAS), I can configure easy policies to reboot services, or manage their lifecycles, I can provision another machine for the cluster in under 10 minutes, and then it just works (including GPU accelerated workloads).
These days... It's been so long since I've ssh'd into some of my machines that I occasionally have to think for a minute before I remember the hostname.
I don't think about most of them AT ALL - they just fucking work (tm).
I remember the before times - personally, I don't want to go back. It's never been easier to run your own cloud - I currently have 112 online pods across 37 services. I don't restart jack shit on my own - the system runs itself.
Everything from video streaming to LLM inference to simple wikis and bookstack.
The only salient point in this entire article is that BSD typically is less convoluted as a system (and as a consequence... usually less capable and less supported).
I find absolutely all of the other points to be "easy cop outs". They're there to provide him a mental justification for doing the thing he wants to do anyways, without actually justifying his logic or challenging any assumptions.
---
Case in point - I used to point all (most of) my hosted services at a single database. It genuinely sucked. It's a larger backup, it's a larger restore, if it goes down everything is down, and you better hope all the software you're hosting supports your preferred DB (hah - they won't, half will use postgres, half will use mysql, and half of the mysql half will actually be using mariadb, and I'm ignoring the annoying group that won't properly support a networked db at all and don't understand why I'm frustrated they only support sqlite).
You know the only thing it was actually doing for me? Marginally simplifying deployment, usually at first time setup.
You know what else the author of this post is trashing? Some pretty good tools for simplifying deployments.
Turns out... if spinning up a database is 3-10 lines in a config file, and automatic backups are super simple to configure with your deployment tool (see - all those k8s things he's bashing)... You don't even feel this pain at all.
---
Basically - This is a lazy argument.
Perfectly fine personal preference (I also sometimes enjoy the simplicity of my freeBSD machines, and I run opnsense for a reason).
But a trash argument against the things he's railing against.
Switching to k3s and running kubernetes was a a pretty giant time sink to get online (think maybe 25 hours) - but since it's come online... I've never had an easier time managing my home services.
Deployment is SO fucking simple, no one machine going down takes any service down, I get automatic backups, easy storage monitoring (longhorn and NAS), I can configure easy policies to reboot services, or manage their lifecycles, I can provision another machine for the cluster in under 10 minutes, and then it just works (including GPU accelerated workloads).
These days... It's been so long since I've ssh'd into some of my machines that I occasionally have to think for a minute before I remember the hostname.
I don't think about most of them AT ALL - they just fucking work (tm).
I remember the before times - personally, I don't want to go back. It's never been easier to run your own cloud - I currently have 112 online pods across 37 services. I don't restart jack shit on my own - the system runs itself.
Everything from video streaming to LLM inference to simple wikis and bookstack.
Linus is too in-bed with Microsoft.
RedHat the main powerhouse behind Linux ans is now owned by IBM. And Ubuntu is just corporate Debian who pushes their own proprietary (Flatpak) software which is cobbled together and just generally sucks.
Systemd is bloated in wanting to do everything at once. I have never had a linux systemd distribution that just shutdowns without prompting me "waiting x/2minutes - x/y retries".
FreeBSD is my daily driver and will always be my primary. Once you get over the "eww it's bsd" linux snobbery you start to realise how solid it actually is.
Wifi works, graphics work. Wine and Proton works. Ports is fantastic and kernel compiling is easy. It even works on my MSI 2024 laptop. [1]
Linux is lost in a communistic maze of leap frog.
[1] https://bsd-hardware.info/?probe=b7f27b9528
RedHat the main powerhouse behind Linux ans is now owned by IBM. And Ubuntu is just corporate Debian who pushes their own proprietary (Flatpak) software which is cobbled together and just generally sucks.
Systemd is bloated in wanting to do everything at once. I have never had a linux systemd distribution that just shutdowns without prompting me "waiting x/2minutes - x/y retries".
FreeBSD is my daily driver and will always be my primary. Once you get over the "eww it's bsd" linux snobbery you start to realise how solid it actually is.
Wifi works, graphics work. Wine and Proton works. Ports is fantastic and kernel compiling is easy. It even works on my MSI 2024 laptop. [1]
Linux is lost in a communistic maze of leap frog.
[1] https://bsd-hardware.info/?probe=b7f27b9528
Wifi? You mean the thing where people often resort to running a Linux VM to handle it?
I have had no issue with Wifi on multiple occasions. Works just fine nowadays without any Linux compatibility add-on.
Wifi not being available isn't the fault of FreeBSD. If vendors actually gave open sourced drivers to their products and not locked behind a proprietary binary blob then we would be in a completely different world.
I can recall when WiFi on Linux was pretty much non-existent until deals were made back in 2018.
So stop throwing that this is FreeBSDs fault, it's 100% down to the vendors locking down hardware.
Wifi not being available isn't the fault of FreeBSD. If vendors actually gave open sourced drivers to their products and not locked behind a proprietary binary blob then we would be in a completely different world.
I can recall when WiFi on Linux was pretty much non-existent until deals were made back in 2018.
So stop throwing that this is FreeBSDs fault, it's 100% down to the vendors locking down hardware.
Nobody said it was the fault of FreeBSD.
> Wifi not being available isn't the fault of FreeBSD.
No. Just because it's available doesn't mean it's good. Until FreeBSD supports modern Wifi (4/5, i.e 802.11n/ac) then you're just ticking the box to say you've got it, but Linux actually supports these modern network setups and FreeBSD does not. There is no debating this at this point in time.
And to be clear, I'm referencing wifibox (https://github.com/pgj/freebsd-wifibox) which has been written about extensively and exists to work around FreeBSDs well known poor wifi support.
> So stop throwing that this is FreeBSDs fault
Nope, it's on FreeBSD if they want it. They appear to have finally prioritized it but it's not there yet.
https://freebsdfoundation.org/blog/january-2025-laptop-suppo...
No. Just because it's available doesn't mean it's good. Until FreeBSD supports modern Wifi (4/5, i.e 802.11n/ac) then you're just ticking the box to say you've got it, but Linux actually supports these modern network setups and FreeBSD does not. There is no debating this at this point in time.
And to be clear, I'm referencing wifibox (https://github.com/pgj/freebsd-wifibox) which has been written about extensively and exists to work around FreeBSDs well known poor wifi support.
> So stop throwing that this is FreeBSDs fault
Nope, it's on FreeBSD if they want it. They appear to have finally prioritized it but it's not there yet.
https://freebsdfoundation.org/blog/january-2025-laptop-suppo...
Wifi vendors supply drivers for Linux. They do not supply drivers for FreeBSD. It is not FreeBSD's fault.
It does not matter: FreeBSD has languished in development for wifi drivers for years now.
FreeBSD does not have modern wifi, it is a simple statement.
FreeBSD does not have modern wifi, it is a simple statement.
Ubuntu pushes Snap. Flatpak is the open platform that nearly every other distribution uses.
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 suits: ZFS, a different kernel and network stack, a cohesive system from a small(ish) team of authors, the handbook, etc. But the usual Linux hobgoblins listed above are a red herring here, to my mind.