If systemd is the reason, there are several good distros without systemd (I run Void Linux in particular).
If "kubesomething" is the reason, there's no requirement to use it. I think most people don't run it on their home servers.
If containers are the reason, then again, they are not a requirement. But they are pretty similar to BSD's jails. I don't think they are particularly complex.
FreeBSD has a number of strong 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.
> 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.
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".
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.
Most straitforward reason is not having multiple database server and reuse one Pgsql or Mariadb for several instances of same app.
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.
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.
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...
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:
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.
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.
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.
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.
> 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.
>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,
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.
Linux is just a kernel and ZFS isn't in there.
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...
> 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
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.
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".