Live data from Hacker News

Systemd, 10 years later (2020)

blog.darknedgy.net

311–320 of 332 posts

Re: Systemd, 10 years later (2020)

#311

Earlier quoted context omitted.

I have never criticized most of these. I have very specifically only criticized Red Hat developers. I have no problem with any of the others and they don't show the same problems.

I'm replying to a post in which you specifically called out Wayland and D-Bus, and your criticism of GTK and fd.o is all over this thread. Your lack of criticism of SuSE developers appears to be because you misremembered when/how they switched to systemd - because they did, relatively quickly. But that raises the real question: If the problem is systemd, and the problem is so bad, why do you only blame Red Hat and no…

> I'm replying to a post in which you specifically called out Wayland and D-Bus, and your criticism of GTK and fd.o is all over this thread. Your lack of criticism of SuSE developers appears to be because you misremembered when/how they switched to systemd - because they did, relatively quickly.

And you also brought in SuSE, Arch, and KDE, which I never criticized to make your argument that I simply hate everything work, which is quite disingenuous.

> But that raises the real question: If the problem is systemd, and the problem is so bad, why do you only blame Red Hat and not the every other distribution that switched to it? Do you think they were all victims of Tricksy Lennart, or?

I do not, and have never blamed distributions for switching to systemd.

They can use what they want and it's neither their fault nor problem that systemd and other Red Hat projects are known to create dependencies upon one another for ill technical merit.

I have criticized Red Hat projects for creating dependencies on other Red Hat projects for political, rather than technical reasons; the rest is simply your putting words into my mouth to make a straw-man argument function.

Re: Systemd, 10 years later (2020)

#312

Earlier quoted context omitted.

I'm replying to a post in which you specifically called out Wayland and D-Bus, and your criticism of GTK and fd.o is all over this thread. Your lack of criticism of SuSE developers appears to be because you misremembered when/how they switched to systemd - because they did, relatively quickly. But that raises the real question: If the problem is systemd, and the problem is so bad, why do you only blame Red Hat and no…

> I'm replying to a post in which you specifically called out Wayland and D-Bus, and your criticism of GTK and fd.o is all over this thread. Your lack of criticism of SuSE developers appears to be because you misremembered when/how they switched to systemd - because they did, relatively quickly. And you also brought in SuSE, Arch, and KDE, which I never criticized to make your argument that I simply hate everything w…

I haven't seen any of these supposed Red Hat projects that have dependencies for political reasons. If that were really true then it would be trivial for anyone to remove those dependencies, and there wouldn't be anything for anyone to complain about. Any way you slice it doesn't seem like a cause for alarm.

Re: Systemd, 10 years later (2020)

#313

Earlier quoted context omitted.

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

> you don't really have a moral or tactical position other than "shut up and code." I don't believe that. People commenting negatively on some Linux software/trend do not need any such privilege or permission or show of stake. I think anybody with Linux experience is entitled to his/her opinion on what should and should not be done on their Linux machine and in the Linux software space, whether they produce new code…

That's just re-stating the grandparent comment! If you think everyone is entitled to their opinion then the only tangible way to express that opinion would be to produce new code. What use is the opinion if nobody ever implements it?

Re: Systemd, 10 years later (2020)

#314

Earlier quoted context omitted.

> But it also introduced big nasty software full of bugs If a bug happens in this code, everything is affected, everyone screams at the same time, it is obvious there is a bug, and once its fixed, its fixed everywhere and for every service. If there is a bug in one of the old init scripts, it may go unnoticed for several years, until suddenly someone needs service Bar depend on Service Foo, but Bar cannot figure out…

Yes, but often only for major bugs that are deemed worthy of developer's attention. In practice it's not always so great. Read systemd's bug tracker, not all user-reported bugs get fixed to those users satisfaction, neither by redhat nor by systemd. Systemd is too big and developers refuse to accomodate everybody. Shell scripts are tunable to the specific system. If a rare bug is in a shell script, I can usually find…

>If a bug is in systemd, I can't easily fix it myself. I now have to fight upstream to recognize my issue and fix it for me.

That's not true. You can do as you would with the shell script and patch it in your local copy. If this is too much hassle then that shell script workflow shouldn't be broken by systemd and you can always fall back to it. It's still possible to run shell scripts as systemd units. You could also run another service manager as a systemd unit as another workaround.

Also, in my experience, if you're fixing an actual crash, those patches are really likely to get accepted. Upstream appreciates that, I haven't seen them fight anyone over an easily verified issue. If you're submitting giant 10,000 line patches that change the public interfaces and cause regressions, that's a different story.

Re: Systemd, 10 years later (2020)

#315

Earlier quoted context omitted.

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.

FreeBSD is generally more straightforward for desktop use, IMO.

Re: Systemd, 10 years later (2020)

#316
post #144

Earlier quoted context omitted.

> 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. Are you saying that being "idempotent" is completely inscrutable? Is it not a fairly straight-forward concept?

If we're going to be pedantic, "idempotent" (or rather non-idempotent) as used in the description is rather vapid and meaningless. Idempotency is a quality that describes the result of an action; as such, only actions can be thought of as idempotent. Applying the word idempotent to any noun that does not describe an action (such as "dataflow" in this case) is meaningless. What does it mean for a dataflow to be idempo…

That feels unnecessarily pedantic. If the sole job of entity X is to perform action Y, and it always performs this action idempotently, then why not describe X as idempotent? It's shorter, and it's clear enough. It might not be precisely accurate in the dictionary definition of the word - but natural languages also have DSLs, and those DSLs evolve to adapt to their use cases. Saying "thing that performs an idempotent action" over and over again is a waste of everybody's time.

Re: Systemd, 10 years later (2020)

#317

Earlier quoted context omitted.

It reads like an over-eager developer read Design Patterns and then was tasked with writing a new init system for Linux.

I think the whole problem with systemd wasn't just about technology. The results were spectacular. Before systemd normal Linux boot times were well over a minute. After switching you could get below 10 seconds on the same hardware. And that is just one aspect. I think the core of the problem was somewhere between the style of introducing changes and the way how people communicated. After all, it speaks for itself tha…

Here's a good example.

https://bugs.freedesktop.org/show_bug.cgi?id=76935

Re: Systemd, 10 years later (2020)

#318
post #95

Earlier quoted context omitted.

My devuan linux desktop says something like this on each boot: INIT: version 2.88 booting Using makefile-style concurrent boot in runlevel S.

I've tried Devuan once then it some roadblock because Docker wouldn't run easily on it, but that was a long time ago. I may try it again one of these days now that the latest Devuan stable is based on Debian Bullseye. The "why" is simple: to restore some balance in the force. I do prefer my Linux world to be one where I still have a choice as to which init system and PID 1 my system is running.

Devuan has its own problems with its image and communication:

https://lwn.net/Articles/786593/

It's not even the immaturity of the joke that bothered me back then, but that the response to the criticism was to imply that it is "corporate bullshit" and/or "giving up on having fun".

Re: Systemd, 10 years later (2020)

#319
post #267

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.

CockroachDB is probably the best example of a modern RDBMS.

Is it ACID?

Re: Systemd, 10 years later (2020)

#320
post #250

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.

If Postgres is unnecessary arcane, then surely MySQL is that squared, given all the legacy traps? You know, stuff like "utf8" not actually being UTF-8.
Post reply on HN