141–150 of 251 posts
Earlier quoted context omitted.
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.
Debian is fat?? I always thought it was a nice, minimalist server distro.
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.
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.
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.
Earlier quoted context omitted.
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 th…
> 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?
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…
> 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 u…
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.
Earlier quoted context omitted.
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.
Debian is fat?? I always thought it was a nice, minimalist server distro.
Earlier quoted context omitted.
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 mac…
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…
> 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 s…
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.
Earlier quoted context omitted.
> 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
> 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.