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

271–280 of 332 posts

Re: Systemd, 10 years later (2020)

#271

Post by Blikkentrekker »

rixed wrote: post #269
Blikkentrekker wrote: post #230

Earlier quoted context omitted.

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 li…

> 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.

Indeed there isn't. And people that want simpler declarative configuration files can have them as far as I'm concerned.

My ire is the mentality common of Red Hat employees that I am wrong for wanting traditional Unix-style flexible configuration and their dependency politics to try to get others to switch over. If they just designed their software how they want to and otherwise let it be, such as KDE and XFCE are doing, then they would not be drawing the same criticism, but they have a tendency of coming with a dismissive attitude to everyone who wants it different than they do and insist their way is the future and when people point out that their way does not offer functionality they need either for convenience, or their livelihood they dismiss 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.

If various Red Hat projects didn't find a way to create dependencies on systemd to encourage it's adoption and systemd was simply there for the people that wanted it but left those that didn't alone, then it wouldn't be so controversial.

What I quoted was “Who wouldn't want [...]”; that's the Red Hat mentality, that everyone who has subjective ideals than they either does not exist, or is wrong.

Re: Systemd, 10 years later (2020)

#272

Post by ajvs »

nomorecommas wrote: post #201
marcodiego wrote: post #3

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.

Pretty much. Wish I could say the same for pulseaudio.

At least PipeWire is a thing now.

Re: Systemd, 10 years later (2020)

#273

Post by chronogram »

Blikkentrekker wrote: post #165
dijit wrote: post #141

Earlier quoted context omitted.

And this means we can’t do things like force disconnect an eGPU or whatever on acpi events. I think I figured out my issue with systemd. It does not apply Chesterton Fence when redeveloping things… and how could it, when it redevelops so much. Maybe it’s fine if it’s all you’ve ever know (or you never hacked on your system) but those that did have lost something.

The situation is that such hackers and tweakers rarely use systemd, for these reasons. They are simply annoyed by A) it being pushed on them; B) people often acting that they are irrational for not liking it while it does not what they expect and need; and C) discussions with Freedesktop developers that, frankness be, reveal they live inside of a very strange bubble and have no idea of the use cases outside of it. Th…

> libinput did not need a way to disable mouse acceleration because everyone wants mouse acceleration.

You mean you want a flat acceleration curve? You want to accelerate the mouse, otherwise you need a gaming mouse with the DPI set very high and then keep going into the mouse firmware to adjust the DPI whenever you play a game or switch between different (scaled) resolutions. Libinput has different acceleration profile defaults for different devices, but you can just change it to the flat profile which I prefer as well.

See https://wayland.freedesktop.org/libinput/doc/latest/pointer-...

Re: Systemd, 10 years later (2020)

#274

Post by posix_me_less »

usrbinbash wrote: post #251
roenxi wrote: post #194

Earlier quoted context omitted.

> the transition was fully imperceptible A normal user will never really link the features they see or do not see back to the init system. I'll draw a parallel with the worst subsystem being cut out of modern Linux - X Windows. As far as I can tell Linux is missing good macro systems that can record actions taken by a user, then replay them. For loops for non programmers, basically. This isn't because the idea is rad…

> the monoculture created by systemd systemd became the de-facto default init sys because Distro Maintainers have chosen it. I posted this link here before, but I will happily post it again: https://www.reddit.com/r/archlinux/comments/4lzxs3/why_did_a... Such a thing doesn't happen if the thing offered isn't an improvement over what was before. As a matter of fact, this doesn't even happen if the thing offered is onl…

> Such a thing doesn't happen if the thing offered isn't an improvement over what was before.

It does happen sometimes. GNOME3 and GTK3 didn't offer much to Linux desktop users, yet they were adopted.

And improvement is subjective. Maybe systemd made maintainers' lives better. But it also introduced big nasty software full of bugs that discourages hacking by users. Many users consider that a deterioration of the Linux ecosystem.

I'll take wrestling a bug in a 400-line shell script to wrestling a bug in the systemd C code and compiling my fixed version.

Re: Systemd, 10 years later (2020)

#275

Post by posix_me_less »

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.

Writing more code does not always mean producing better software. Often it's better to just move to an already existing better software. For service management, there are many alternatives already.

Re: Systemd, 10 years later (2020)

#276

Post by posix_me_less »

petre wrote: post #250
int_19h wrote: post #216

Earlier quoted context omitted.

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.

MySQL and SQLite, but the former is not a real transactional database, it's quite a joke compared to Postgres. The latter is a file based database. We use MySQL at work and I am exasperated by it. It's possible that even Firebird is better.

What exactly do you miss in MySQL compared to Postgres? With InnoDB it can do transactions, no?

Re: Systemd, 10 years later (2020)

#277

Post by morelisp »

posix_me_less wrote: post #275
morelisp wrote: post #247

Earlier quoted context omitted.

“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.

Writing more code does not always mean producing better software. Often it's better to just move to an already existing better software. For service management, there are many alternatives already.

> Writing more code does not always mean producing better software.

I didn't say it did! I said if you really buy into the "Linux is about choice", "Red Hat stole our fun OS" etc. bullshit that always circumscribes the populist anti-systemd position in these debates - then you don't really have a moral or tactical position other than "shut up and code."

I don't think that's true - I think there are other obligations to users which are just as important - but these all suggest systemd even more than the "master of my own machine" nonsense.

Re: Systemd, 10 years later (2020)

#278

Post by Nasreddin_Hodja »

usrbinbash wrote: post #251
roenxi wrote: post #194

Earlier quoted context omitted.

> the transition was fully imperceptible A normal user will never really link the features they see or do not see back to the init system. I'll draw a parallel with the worst subsystem being cut out of modern Linux - X Windows. As far as I can tell Linux is missing good macro systems that can record actions taken by a user, then replay them. For loops for non programmers, basically. This isn't because the idea is rad…

> the monoculture created by systemd systemd became the de-facto default init sys because Distro Maintainers have chosen it. I posted this link here before, but I will happily post it again: https://www.reddit.com/r/archlinux/comments/4lzxs3/why_did_a... Such a thing doesn't happen if the thing offered isn't an improvement over what was before. As a matter of fact, this doesn't even happen if the thing offered is onl…

> systemd became the de-facto default init sys because Distro Maintainers have chosen it.

Because they were forced to choose it due to vendorlock and many other projects became dependent on systemd. Unsystemding everything would be very expensive.

Same problem will be with snap and flatpak.

Re: Systemd, 10 years later (2020)

#279

Post by morelisp »

Blikkentrekker wrote: post #270
morelisp wrote: post #247

Earlier quoted context omitted.

“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…

> 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.

It sounds to me like the bazaar system is working fine qua its own standards, then. Red Hat writes what they need to solve their problems, party X writes what they need to solve their problems, the code is shared, everyone gets what they want.

Except: It sounds like what you really want is for Red Hat to solve your problems, not only their problems. That's definitely not how this stuff shook out historically. And it opens a door you might not want to open, because now you need to ask yourself why users liked systemd, and what obligations you have to support beyond your own needs in your own software.

Re: Systemd, 10 years later (2020)

#280

Post by throwaway984393 »

erik_seaberg wrote: post #173
throwaway984393 wrote: post #93

Earlier quoted context omitted.

Part of it was political, but it was also just practical. Poettering's designs are some of the worst for usability I've ever seen. They technically work, but you need a million StackOverflow Q&As to figure out how to get anything done or solve the many common problems. It's like somebody decided that the problem with Linux was it wasn't complicated enough. And then everbody just went with it.

I keep coming back to the https://news.ycombinator.com/item?id=19023885 issue. There’s a default setting somewhere that makes systemd knowingly kill normal user processes it did not start. Why does that exist? It was never init’s job, and init is not something end users should have to be aware of to run stuff with POSIX nohup.

Jesus. I didn't know about that, but it totally makes sense. Like when systemd devs told Linus he should change his kernel to fix a bug in systemd.
Post reply on HN