Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Systemd, 10 years later (2020)

blog.darknedgy.net

Post reply on HN
Print view View original

261–270 of 332 posts

Re: Systemd, 10 years later (2020)

#261

Post by greatgib »

akagusu wrote: 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.

This is plain wrong. The code of systemd was already shit from the beginning.

Random system breakages for stupid reasons.

And everything hardcoded the ugliest way possible so that it is impossible to have alternate systems like some embedded ones.

Re: Systemd, 10 years later (2020)

#262

Post by greatgib »

Systemd is like Windows. A monolithic one size fit all big shit. Most people will tell you that they are perfectly fine and the system is great. But they are just used to all the issues they are encountering or don't realize that they are caused by that.

Lots of people are not surprised when you tell them that pulseaudio was created by the same author. Because it is kind of working in most cases. But there are always, aside, a lot of annoyances or things that work badly without a real justification: hard to fix and understand what is going on when it doesn't work; sometimes it decides alone to not use or not show the output/input that you want and you have no possibly to decide; sometimes it is using 10% of your CPU despite the fact that you are not playing a single sound at the moment,...

Re: Systemd, 10 years later (2020)

#263

Post by lifeisstillgood »

bjourne wrote: post #174
lifeisstillgood wrote: post #79

Earlier quoted context omitted.

Idempotent is surely a valuable piece of software jargon. I know exactly what the user intends, and have good ideas of how hard it is and what likely trade offs they will be making behind the scenes surely it is the very opposite of bullshit.

But the phrase in the paragraph is non-idempotent which is completely redundant. Every piece of software in the world is non-idempotent.

Apart from the idempotent ones ... :-)

Re: Systemd, 10 years later (2020)

#264

Post by Blikkentrekker »

the_why_of_y wrote: post #258
Blikkentrekker wrote: post #71

Earlier quoted context omitted.

It was not. There is strange false history that systemd replaced sysvinit, which occurred only on Debian, because Debian was the last major system to discard sysvinit. Gentoo had replaced sysvinit with OpenRC in 2006; Fedora and Ubuntu were using Upstart in 2005. systemd primarily replaced Upstart and systems that used Runit or OpenRC tended to have stayed with them. Frankness be, this false history seems to be craft…

> Debian was the last major system to discard sysvinit This is partially incorrect and partially misleading. Incorrect in that openSUSE and Arch are major distros and migrated from sysvinit to systemd. https://news.opensuse.org/2011/12/22/systemd-e2-80-93-boot-f... https://www.reddit.com/r/archlinux/comments/4lzxs3/why_did_a... Misleading in that Ubuntu and Fedora did use Upstart but not in its native mode, they used…

> Incorrect in that openSUSE and Arch are major distros and migrated from sysvinit to systemd.

OpenSUSE also had upstart in the meanwhile but continued to support sysvinit as an alternative.

Arch Linux had sysvinit as it's pid1, but it's big sell initially was that, similar to Crux, it had a custom BSD-style init script setup and did not use sysvinit's booting and rc mechanism.

OpenRC systems typically also continue to use sysvinit's pid1 to this day, which is not the complaint people have with it but the impossible to understand script sand lack of dependency management of it's service management because it was never meant to do service management which was a bit of a hack.

> Misleading in that Ubuntu and Fedora did use Upstart but not in its native mode, they used it in its sysvinit compatibility mode. This is almost identical to sysvinit, so from the point of view of a user or a package maintainer it was functionally barely distinguishable from sysvinit.

There is no such compatibility mode as far as I know. A big sell of Upstart and OpenRC was always that it was backwards compatible with old-style sysvinit-style scripts even though new ones were written in the new style. There is no global mode as far as I know but no doubt many of the olds scripts remained.

> OpenRC was considered by Debian, but 7 out of 8 members of the technical committee preferred both systemd and Upstart to OpenRC (Ian Jackson preferred sysvinit over OpenRC and "further discussion" over every other option).

That would not surprise me. It's not what Debian is looking for.

Re: Systemd, 10 years later (2020)

#265

Post by wrycoder »

int_19h wrote: post #215
wrycoder wrote: post #17

Earlier quoted context omitted.

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.

If you want the Unix philosophy, why not use an actual Unix? The BSDs not only all have traditional init systems, but are also more in line with how old-school Unix worked in general (e.g. base system segregation).

I have. OpenBSD is great!

The biggest problem I had was that it was difficult to keep upgraded. In those days, it was basically a re-install every six months, plus a merge of any local changes. I understand things are much better now, and I may give it another try.

Re: Systemd, 10 years later (2020)

#266

Post by rixed »

Blikkentrekker wrote: post #230
rixed wrote: post #226

Earlier quoted context omitted.

acpid vs logind is another illustration of the trade offs involved when moving towards GUIfication of the bazar that is (was?) unix. Basically the proposition is akin to a weapon exchange program: hand over your powerful but dangerous Turing complete configuration language in exchange for nicer looking desktops. Who would not prefer a better looking desktop?

It's what you consider nicer. I consider dialog windows to be a slow and frustrating way to configure anything and on top of that in this case it loses me the ability for my computer to do what I want it to when I close my lid. And if it simply remained at that, but left me alone I wouldn't be so irate, but I don't feel left alone and “ Who would not prefer a better looking desktop? ” already borders on this “ My way…

I now realize the sarcasm was unfortunately not obvious, and I have to apologize.

-- Sent from my terminal

Re: Systemd, 10 years later (2020)

#267

Post by api »

int_19h wrote: post #216
api wrote: post #180

Earlier quoted context omitted.

I feel the same way about Postgres. It's powerful but it's insanely arcane and full of land mines and footguns. It's great for forcing you to hire consultants, DBAs, or pay cloud providers a lot to run it for you.

Which SQL RDBMS isn't, though? Postgres is a breeze compared to someting like DB2. High-performance relational databases just seem to be an inherently arcane target.

CockroachDB is probably the best example of a modern RDBMS.

Re: Systemd, 10 years later (2020)

#268

Post by api »

Too wrote: post #253
api wrote: post #61

Earlier quoted context omitted.

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.

What is arcane about systemctl stop and journalctl --since?

How do I list what's running? I have to Google that every time. How do I list units? What are units? What the fuck are... and so on. The output is hard to read. The files are all over. The directory and file names are counterintuitive. It’s just… needlessly arcane.

Git has the same problem but at least git is excellent enough software in other ways that it makes up for the horrible UX. Systemd is mediocre.

Re: Systemd, 10 years later (2020)

#269

Post by rixed »

Blikkentrekker wrote: post #230
rixed wrote: post #226

Earlier quoted context omitted.

acpid vs logind is another illustration of the trade offs involved when moving towards GUIfication of the bazar that is (was?) unix. Basically the proposition is akin to a weapon exchange program: hand over your powerful but dangerous Turing complete configuration language in exchange for nicer looking desktops. Who would not prefer a better looking desktop?

It's what you consider nicer. I consider dialog windows to be a slow and frustrating way to configure anything and on top of that in this case it loses me the ability for my computer to do what I want it to when I close my lid. And if it simply remained at that, but left me alone I wouldn't be so irate, but I don't feel left alone and “ Who would not prefer a better looking desktop? ” already borders on this “ My way…

I believe this issue of Turing complete config language vs simpler declarative configuration is one of the basic thing for which there exist no good universal solution.

I face the very same issue in my day job where I'm struggling to cut the right balance between a featureful data manipulation language with which the customer can implement whatever he needs, as long as he is OK with a bit of programming, or a more limited one for which we have a GUI... and that GUI itself has to be tested, and I'm also currently reviewing QA tools to help testing GUIs, and they basically fall in two camps: those that require one to spend a week learning how to program them, and those that are much more limited but come with a straightforward GUIs...

Before systemd the same conflict happened with network-manager: my network setups were usually custom and out of reach from network-manager that I despised and purged of my desktops first thing after a fresh install. Yet with time network-manager supported more and more use cases and I'm now happy to use it. Maybe one day systemd will also make it possible to add the bits of hackery here and there and we will all be satisfied with it.

For now, if so many users have it easier thanks to systemd, which seems to indeed be the case, then it's still something.

Re: Systemd, 10 years later (2020)

#270

Post by Blikkentrekker »

morelisp wrote: post #247
Blikkentrekker wrote: post #127

Earlier quoted context omitted.

And that is probably the motivation for this design philosophy of limiting options that Redhat and Freedesktop champion where more and more, simple, clean, turing complete solutions are replaced by a discrete list of simple options. But it does not change at all why I dislike it, and why I am annoyed by Freedesktop's pushing and insistence that many keep to these more custoizable solutions supposedly simply because t…

“People who write the code get to make the rules” is perhaps the most fundamental part of bazaar development ideology. If you don’t like it, write more code.

People are writing code.

The difference is that everyone outside of Red Hat an Freedesktop isn't creating artificial dependencies on each other's projects to “gently push them” so people outside of it again have to write more code to decouple them again.

They did write the code to fork elongind in such a way that it no longer required systemd; they did write the code so that GNOME could run without logind like every other system; they did write the code to fork of udev from systemd again so that it could run without glibc. — None of these projects suffered loss of functionality.

They're complaining that they have to, because every time, these dependencies that have no technical justification happen, it's always one RedHat project depending on another to create product tying and encouraging adoption.

The rule of capitalism is simply that product tying works in practice, however bad it is for the user and consumer. That's why Apple likes to come with custom cables that only work on their hardware for no technical reason, and that's why logind was incorporated into systemd and came to depend on it for no technical reason.

Post reply on HN