111–120 of 251 posts
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.
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
Earlier quoted context omitted.
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 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…
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 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…
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.
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.
> 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
Earlier quoted context omitted.
> 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 ne…
> 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.
If systemd is the reason, there are several good distros without systemd (I run Void Linux in particular). If "kubesomething" is the reason, there's no requirement to use it. I think most people don't run it on their home servers. If containers are the reason, then again, they are not a requirement. But they are pretty similar to BSD's jails. I don't think they are particularly complex. FreeBSD has a number of strong…
To me arch linux is the middle ground between a too-much-complexity "fat" distribution like ubuntu or debian and a-minimal-but-eclectic-freebsd. the arch wiki is VERY comprehensive, linux has a huge community, and arch forced you to understand much just by stepping through the installation process.
Earlier quoted context omitted.
> 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 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
Bash and zsh are approximately to same age. I think bash is older by only a few months.