Live data from Hacker News

Systemd, 10 years later (2020)

blog.darknedgy.net

61–70 of 332 posts

Re: Systemd, 10 years later (2020)

#61

Systemd pissed off many people. For me and most users, the transition was fully imperceptible. With the difference that systemctl tools seem to work better for what it does than the many sparse different tools it replaced.

It’s a functional improvement over old init, but the thing I hate about it is how unnecessarily arcane it is. It seems “designed for job security” or more likely designed for consulting revenue.

There is absolutely no need for its command names and everything else about it to be so counterintuitive.

Re: Systemd, 10 years later (2020)

#62
post #43

Earlier quoted context omitted.

I mean, emacs doesn't respect the UNIX philosophy either, but that's one of the most praised pieces of software to come out of the UNIX space. The UNIX philosophy isn't meant to be taken as gospel - hell, it's very hard to define what "doing one thing" even means.

Didn’t emacs get developed on ITS or Multics? Seems Unix just imported it, but your point still holds.

https://en.wikipedia.org/wiki/Emacs#History

Yes.

Emacs development began during the 1970s at the MIT AI Lab, whose PDP-6 and PDP-10 computers used the Incompatible Timesharing System (ITS) operating system that featured a default line editor known as Tape Editor and Corrector (TECO)

Re: Systemd, 10 years later (2020)

#63
post #43

Earlier quoted context omitted.

I mean, emacs doesn't respect the UNIX philosophy either, but that's one of the most praised pieces of software to come out of the UNIX space. The UNIX philosophy isn't meant to be taken as gospel - hell, it's very hard to define what "doing one thing" even means.

Didn’t emacs get developed on ITS or Multics? Seems Unix just imported it, but your point still holds.

Early versions of Emacs didn't have lisp extension languages, which is kind of strange to think about considering the role elisp plays in GNU Emacs as we know it today. GNU Emacs with elisp is something that developed in the context of the MIT lisp machine scene. Sure it runs and was developed on unix-like operating systems, but lisp extensible emacs were never really some sort of embodiment of the 'unix principles'.

Re: Systemd, 10 years later (2020)

#64
post #46

The hatred for Systemd seems to come from those who see the unix philosophy of small, single use programs being thrown away in favour of a monolith. Back when I had linux as a desktop (around the day of slackware 10) there were plenty of problems with simple stuff like mounting usbs, connecting to wifi etc--possible but a pain. I've hardly looked at systemd or linux in such a way for a long time, however.

I'm not sure, it seems to me that the hatred for systemd seems to come from those that learned something else and don't want to learn systemd. My analysis would be that the "unix philosophy" is just a convenient argument against it.

Re: Systemd, 10 years later (2020)

#65
post #45
post #12

Earlier quoted context omitted.

it's kind of like locked bootloaders and pentalobe screwdrivers for organizing a unix system where most users were used to easy to inspect and modify scripts and single purpose programs . yes, it's still open source, but modifications and inspection are far more complicated creating a much higher barrier to entry. in the earlier days when it was still buggy, even linus himself was screaming about not being able to ea…

It's not like systemd is written in deliberately obfuscated C or something inscrutable altogether like Brainfuck. A monorepo containing well-organized boring C, developed on github of all places, is the polar opposite of raising the barrier to contributing vs. what was replaced. Full-disclosure: I contribute to systemd.

Of course, but I would not like to have to patch it to modify something that on other systems can be modified with either a configuration option, or a shell script.

To me, the most poisonous example that contrasts the traditional design with Freedesktop's design is acpid contrasting logind. In the former case, an acpi event is sent, and acpid simply executes a file such as `/etc/acpi/action/lid_down.sh`. That file can contain anything the system administrator wills, from a simple script that does nothing more than `systemctl sleep` to whatever complex task he could desire.

The last time I checked the situation, logind had replaced this powerful, and simple mechanism with a configuration that offers nine options to execute when the lid is pressed, none of which involve executing a simple file. Of course I can edit the source code and recompile to allow it to do what I want it to, but I would far rather simply quickly alter a simple shell script to do so.

And luckily I can, because I do not use logind but acpid, but that does not change the ire I experience when dealing with many Redhat and Freedesktop people who make it very clear that I should be using logind, that it's better, and that they create artificial dependencies on it to as Poettering calls it “gently puh” me in that direction.

Re: Systemd, 10 years later (2020)

#66
post #26

I am old enough to remember that problems with systemd were less technical and more political. People didn't like the way systemd developers pushed the community to adopt systemd, specially when they asked for 3rd party developers to make systemd a hard dependency. Unfortunately,people don't remember this today, and think users resisted to systemd adoption only because they didn't like systemd.

SystemD is kind of like MacOS, if you have a typical use case then it makes everything very easy. If you are doing something weird it can make your life a living hell.

> If you are doing something weird it can make your life a living hell.

I find it much easier to reliably accomplish non-standard things with systemd unit definitions, than it used to be with the ill-defined complex set of shell scripts we had before.

Re: Systemd, 10 years later (2020)

#67
post #57
post #42

Earlier quoted context omitted.

I’m a fan of this description. It might not be the easiest to understand or the first one you should read, but I wish more things had this kind of description somewhere (but not necessarily on the introductory materials or front page).

It’s buzzword bingo with the aim to inflate the writer’s ego and intimidate the reader. This stuff happens all the time when insecure people get to write things.

Exactly.

“Idempotent” is one of the key words used as a cudgel in this way. It’s great for the bullshit artist, as to a layman the dictionary definition is completely inscrutable.

Re: Systemd, 10 years later (2020)

#68
post #58

Earlier quoted context omitted.

Like what if you don't mind me asking, and what did people used to use as an alternative?

For the init system, the most common predecessor was a combination of sysvnit and "initscripts" (a shell script for each daemon on your system). Writing the init scripts was simple for the most basic cases but quite complex for complete, bug free case coverage. A big appeal of systemd for packagers and sysadmins was the relative simplicity of unit files. Now we just have to fill out a simple boilerplate INI style fil…

And less distro divergence in how to write the service scripts, or how to start services etc.

Re: Systemd, 10 years later (2020)

#69
post #26

I am old enough to remember that problems with systemd were less technical and more political. People didn't like the way systemd developers pushed the community to adopt systemd, specially when they asked for 3rd party developers to make systemd a hard dependency. Unfortunately,people don't remember this today, and think users resisted to systemd adoption only because they didn't like systemd.

Network configuration (on say, Debian) is still a pain and has a lot of different ways of accomplishing similar tasks. Anything beyond the plain vanilla singular network device that is either dhcp/static is often painful. Systemd has some sauce, there is legacy /etc/network* stuff, there are daemons which can be configured graphically… it’s still a mess. In this arena, I think systemd has failed for the last decade. It introduced yet another way of doing things without considering the whole scope of what it needed to replace.

I’m old enough to remember the culture wars and even older to remember a well thought out approach to overall configuration in Debian given the available tools of the time.

Re: Systemd, 10 years later (2020)

#70
post #12

Earlier quoted context omitted.

it's kind of like locked bootloaders and pentalobe screwdrivers for organizing a unix system where most users were used to easy to inspect and modify scripts and single purpose programs . yes, it's still open source, but modifications and inspection are far more complicated creating a much higher barrier to entry. in the earlier days when it was still buggy, even linus himself was screaming about not being able to ea…

Right. I have a simple rule: don’t use a GNU/Linux system that uses systemd. It doesn’t respect the Unix philosophy. It’s trying to turn it into Windows. I’m waiting for Microsoft to buy Red Hat. Failing that, IBM.

I hate the feature and mission creep of systemd and try to use other unixes where I am able; but what you wrote is downright insane.

There were several init replacements in the mainstream before systemd. OSX and Solaris both had their own, and they were as UNIX (officially certified) as you can get.

Also, as long as we're doing non-sequitors; Microsoft is more likely to buy Canonical than they are to buy RedHat or IBM.

Post reply on HN