Comment by Denvercoder9 | Hacker News Reader

Comment by Denvercoder9 | Hacker News Reader

Parent Full thread

> Basically the opposite of systemd, which is a giant code ball of code with components tightly coupled.
> [..]

> The use or non-use of of either of these program will also not effect device discovery / hot-plugging, mounting of file systems, system run levels, network time, system logging, etc.

This comes up again and again in the systemd discussion, but it's at best a mischaracterization. Yes, there's some code sharing between different components, but it's not a monolith. On my Debian system it ships 50+ different binaries split across 8 different packages. You can use the network management without using the NTP service, the journal without using the device manager, the tmpfiles manager without using the user manager, etc.

Most, if not all, of these components only depend on the service manager (i.e. PID 1). That's more or less unavoidable for an event-driven system, there'll always be a dependency on the event bus. The components itself can be freely swapped out for different, even incompatible, implementations. If you don't even want to run the service manager, all external interfaces are stable, pretty well-documented and relatively straightforward, so it's even possible to write a completely independent implementation without breaking external dependencies.

By the way, if we're talking about loose coupling and POSIX, this OpenBSD implementation isn't it either. resolvd has an hardcoded reference to the unwind socket, and they use a special BSD-only socket type to communicate between the different processes.

> On my Debian system it ships 50+ different binaries split across 8 different packages.

Nobody cares. The number of binaries is irrelevant. What is relevant are stable, documented interfaces between them that someone else could implement if they so choose and remain compatible. And systemd people have repeatedly said they do not intend to maintain stable interfaces between the various components of systemd. As long as that's true, it's completely fair to call systemd a monolith, 50+ binaries or not.

In other words, this is a ‘only Microsoft employees may use the secret 7 on the dice’ situation.

What's really relevant is market share. Guess what? Systemd is winning because it massively sucks less than what existed before it.

No, it's winning because RedHat is forcing everyone's hand by hiring most of Linux desktop developers, and the rest are insufficient to maintain other solutions to keep feature parity.

It's Embrace Extend Extinguish in action, except by using the force of running two biggest distributions in addition to GNOME project. (And a bunch of others depending directly on them.) Even Debian was unable to weather all the dependencies using the new interfaces. Gentoo tries still with OpenRC, more or less successfully.

I don't think Red Hat are forcing anyone's hand. I think the fact that Red Hat are hiring passionate developers to work on something they love full time is something they should be lauded for. Of course Red Hat have to pick a project they're going to focus on, they can't focus on every implementation, and it only makes sense that community projects aren't going to have feature parity with software that's being built for enterprise use cases, worked on people whose it's their full time job. It's because of the wider support that the majority of distros decided to go with them.

That is incorrect. https://news.ycombinator.com/item?id=23067431

Your own comment that you've linked here, which mentions Russ Allbery, has him quoted saying, "Most of those [systemd] components are clearly superior to anything we have available now on Linux platforms and will be used in the distribution going forward".

Then there's Fedora, which is upstream of Red Hat, who has many of it's contributors as Red Hat employees, so I don't see how it's odd that they would adopt software that Red Hat are invested in.

Are you just going to ignore the evidence that goes counter to the narrative you want to establish?

I'm not intentionally ignoring any evidence, so I invite you to elaborate on what you're alluding to.

What I also don’t get: why the hell would do I care which NTP implementation is used in most cases. What I do care about is that it’s running and working. systemd has a good init system and a decent set of other services. Could things be improved? Sure. But honestly as long as when I boot my Debian-derived distro it works as expected why am I going yo go digging into how it works? What can I possibly gain by switching which DHCP client or which NTP daemon I’m using?

> What I also don’t get: why the hell would do I care which NTP implementation is used in most cases.

Because some implementations have time jump while others have it slew it slowly.

On boot-up a jump may be fine to get with ± some number of milliseconds, but once the system is running, there are situations where jumps could be a problem (especially in the negative direction, where a moment is "repeated").

> But honestly as long as when I boot my Debian-derived distro it works as expected why am I going yo go digging into how it works? What can I possibly gain by switching which DHCP client or which NTP daemon I’m using?

Because as a sysadmin it is your job to understand how a system works. There should be very little "magic" happening. Sure there are many times where things Just Working™ is fine (it's why I run a Mac at home), but many others where you should understand why things are working the way they are.

> Because as a sysadmin it is your job to understand how a system works.

No, as a sysadmin your job is to deliver a working system. To do that it usually helps to understand how the system works, but it's not a necessity. As long as something keeps working, and you're equipped to go digging if and when it's necessary, it's fine to not understand or know how something works.

>As long as something keeps working, and you're equipped to go digging if and when it's necessary, it's fine to not understand or know how something works

How do you know it's working if you don't understand it? What's preventing some admin socket to be activated, is the firewall good, etc

you can ride and breed horses without understanding horse physiology or DNA. when you need to fix a broken or lame horse or breed a better horse, knowing how it works helps alot

presumably most sys admins are more akin to vets than riders

I am a sysadmin for some systems. I am merely a user for others. Servers that run my projects? Sure I will dig into what’s up. My Raspberry Pi running Raspbian so I can run my 3D printer off it? I’m a user.

> What I also don’t get: why the hell would do I care which NTP implementation is used in most cases. What I do care about is that it’s running and working.

You should care whether it's SNTP (which only slews and/or steps the clock periodically) or full NTP (which also adjusts the clock frequency, so once it's synchronized, no further slew and/or step is needed). Full NTP is better.

Looking quickly at the manual pages for systemd-timesyncd and systemd-timedated, I can see that systemd-timesyncd is just SNTP, so a full NTP implementation like chrony or ntpsec should be preferred. From what I can see, if you have chrony installed and configured correctly, systemd's "timedatectl set-ntp true" (enable NTP) will prefer to enable chrony instead of systemd-timesyncd (it goes through systemd-timedated which looks at /usr/lib/systemd/ntp-units.d/, where chrony is usually listed first).

(Also, there's some difference between chrony and ntpsec; AFAIK, chrony is much better when you have an intermittent network connection.)

> What can I possibly gain by switching which DHCP client

Yesterday I switched to systemd-networkd on debian to gain the feature of having the hostname be set via DHCP and not have to write a script myself. In the process I pulled in a javascript dependency via policykit, which is giving me pause and I am re-evaluating if my approach is correct here.

But for this feature I had to switch DHCP server and client. TBF it's not something that comes up all the time, but it sure is something I thought was more commonly implemented.

> In the process I pulled in a javascript dependency via policykit, which is giving me pause and I am re-evaluating if my approach is correct here.

To be fair, policykit is great. It solves a real problem (namely is this user allowed to peform this action, which traditional POSIX permissions do not solve in a portably) in a very sane way that is totally optional to opt in to.

Should polkit use a different, turing complete language than JavaScript? I don't know, probably, but it's not an awful choice. There is definitely more developer literacy for JS than, say, Lua or some other bespoke monstrosity they could've picked instead.

Doesn't POSIX and Linux Standard Base already mandate certain scripting languages to be preinstalled, such as Python?

I've heard a rumour that POSIX mandates that Perl be installed, although I haven't been able to substantiate it.

POSIX-described Turing-complete interpreters include at leat the Bourne shell, awk, and sed, none of which you probably want to use for implementing a security policy.

Apparently LSB 5.0 mandates[1] both Perl (5.8) and Python (2.4), but that won't pacify anyone with an axe to grind about applications making Linux-specific assumptions.

[1]: https://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Languages...

> Apparently LSB 5.0 mandates[1] both Perl (5.8) and Python (2.4)

Wow, that didn't age well. That document actually says Python "2.4.2 or greater" and Perl "5.8.8 or greater", which doesn't help if the installed interpreters are Python 3.10 and Perl 6.c (2018.06), since both are greater than the specified versions but incompatible with them. Even if it had specified the major release (that is, Python 2.x greater than 2.4.2 and Perl 5.x greater than 5.8.8), that wouldn't help once those major releases are no longer maintained.

Perl 6 isn't really a thing anymore.

Python3 requires some code changes, but on the whole is the same language.

Perl 6 was intended to be an upgrade from 5, but over time developed into a completely new language that shared stylistic similarities to Perl 5. Perl 6 can't be compatible with Perl 5 to any large extent because XS isn't a thing anymore, so any modules that had binary parts to them can't be easily ported.

These days Perl 6 got renamed to "Raku", to signify that it's its own, independent language.

The Perl 5 line continues to exist and apparently plans for the next major version to be Perl 7.

> I've heard a rumour that POSIX mandates that Perl be installed, although I haven't been able to substantiate it.

It’s not: https://shellhaters.org

> Lua or some other bespoke monstrosity

Lua is definitely the opposite of 'bespoke monstrosity'. It's pretty much the intersection of tiny interpreter, fast execution, and simple language.

Apologies if I mistyped this, Lua is not remotely a monstrosity. It's great! But I don't think it would be appropriate here, and I think more developers can grok JS in this day and age.

The Debian policykit packages have (frustratingly) diverted from upstream here. They do not pull in mozjs, sanding users with the older and far less flexible rules files.

If you don't like it, try dhcpcd I which can set the hostname via DHCP by default.

On Linux there are no hard dependencies although your distro may enforce a udev dependency.

I care about which NTP implementation is used because OpenNTPD supports getting time constraints from TLS servers. Which.. no, I absolutely do not actually worry about NTP servers intentionally feeding my laptop the wrong time, but this is just a feature that sounds too cool to ignore. How can I not go out of my way to have that going on??

Sometimes I kinda envy people who don't have this shiny-tech-obsession and are satisfied with things just working :)

Oh don’t get me wrong I customize things. I have just moved on from customizing parts of a Linux distro. At some point I want to customize things that make more of an impact on the real world.

> But honestly as long as when I boot my Debian-derived distro it works as expected why am I going yo go digging into how it works?

My (least) favorite SystemD gotcha I discovered recently is the way it's taken over 'fstab' in some distros. I think Debian is one of them. When you edit 'fstab', you need to run 'systemctl daemon-reload'. Fine. Whatever. I don't have a huge problem with that.

However, when you try to boot after a disk has been removed from the system, it won't. Instead it drops to a recovery console, BUT if you use a distro without a 'root' password, it can't drop into the recovery console and you're screwed.

The default setup on a lot of Linux distros won't boot if you remove a non-system disk. I like SystemD more than the old init system(s), but there are some really, really dumb decisions that have been made along the way.

Yep. Hit that one too.

Learned the hard way the need for the 'nofail' flag in 'fs_mntops' field, which was undocumented in the man page in the early versions ...

Ok that’s a bit much. Why is SystemD encroaching on the fstab??

Because systemd services can depend on mount points or cause mountpoints to come up dynamically, in a way that pure fstab does not support, e.g. for containers. So (as far as I understand) fstab is now simply an input to the actual mount system.

It's not encroaching on fstab, it's using it as input during boot, because mounting is intimately coupled with service ordering. Think about services that reside on a network filesystem: the network has to be up to mount the filesystem, but the network in turn can require arbitrary services to run, which can require other local filesystems to be mounted. You can't get configurations like these to work without coupling mounting and service ordering.

It's fundamentally not that different from sysvinit, with its various init scripts that mounted filesystems according to the fstab.

> Instead it drops to a recovery console, BUT if you use a distro without a 'root' password, it can't drop into the recovery console and you're screwed.

That's indeed an unfortunate situation. systemd allows you to set the SYSTEMD_SULOGIN_FORCE environment variable for the rescue.service to override this behaviour and always give you a rootshell. It's an open bug for the Debian installer to set that variable by default if installing without a root password (#952450).

If you want your system to boot if a filesystem can't be mounted, use the longstanding nofail option on the noint point.

> why the hell would do I care which NTP implementation is used

Allow me to introduce you to BSD users. (I don’t get it either).

systemd fundamentally made a branding mistake, not a technical one. Putting all of these components under one 'systemd' umbrella name meant that people simplistically think of them as one thing and then start making the 'Unix philosophy' argument.

Moving the goalposts yet again. Not only must it be technically superior for everyone, not only must it adhere to decades old computing dogma, but now it must be branded in such a way that it’s individual components must be unidentifiable?

We're in a thread about OpenBSD, a Unix that keeps literally the entire OS (except for ports) in one repo, and ships them together.

So this is a strange criticism to make.

You're right that Linux is pretty much the only operating system where users can mix and match core system components. That's precisely why people get so mad about systemd!

If I wanted to use an operating system where all the components were tightly coupled and made by a single vendor, I'd use Windows, or macOS, or a BSD. (In fact I do use those operating systems when that's what I want.) But I would also like for other kinds of systems to exist in the world. I downloaded Linux because I wanted to use an operating system that _wasn't_ macOS!

They are free to make that criticism but they should do it without invoking "the Unix philosophy" which Linux has never adhered to.

Unix never had interchangable components like that.

Specially because "the Unix philosophy" as preached by Linux afficionados never happened in real UNIX, it keeps being preached as some kind of cargo cult by people that weren't even around during the UNIX wars heyday.

Because it all lives in one repo, some distros make the choice of packaging all of systemd into one package, so that you can't choose to not install timesyncd or networkd.

You can choose not to use them though. RHEL uses neither of those two, for example.

> Most, if not all, of these components only depend on the service manager (i.e. PID 1).

And dbus. The components being discussed here don't depend on either.

> Yes, there's some code sharing between different components, but it's not a monolith.

So I can take the code for just systemd-resolved and port it to FreeBSD or Solaris?

What part of “not a monolith” requires portability to other operating systems?

The use of stable, documented, orthogonal interfaces. That part.

Reply on news.ycombinator.com