Live data from Hacker News

Systemd, 10 years later (2020)

blog.darknedgy.net

301–310 of 332 posts

Re: Systemd, 10 years later (2020)

#301

Earlier quoted context omitted.

I believe it is common to pretty much all Red Hat and Freedesktop developers. Poettering has come with very similar claims that betray that he does not understand what people outside of his small circle want and need, the same can be said for Wayland developers, DBus, NetworkManager, PulseAudio and all such other infamous projects.

If your problem is with the Red Hat developers, and the fd.o developers, and the GTK developers, and the Debian and Arch and SuSE and Ubuntu developers, and the DBus developers - maybe your problem is not actually with any of these developers but a mistaken idea of how open-source development ever worked? Or what, is everyone except you under thrall to Lennart Poettering, master wizard?

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.

Re: Systemd, 10 years later (2020)

#302
post #288

Earlier quoted context omitted.

It's difficult to understand what your complaint is, that describes every software project I've ever seen. You pick a target set of users and then develop for those users. Is there some other way to develop software?

I don't think it is common to find memorable quotes akin to “ I have no idea what XFCE is or does, sorry. ” outside of this circle. This is a vintage and often quoted Red Hat-ism that betrays their mentality. QT developers will not tell you “ I have no idea what LXQt is or does. ”; they do not generally break things that compromise 90% of their consumer base and they do not remove theming because they fear it's exist…

The ticket that quote came from is pretty old and turned out to be a non-issue. I've addressed that in another comment: https://news.ycombinator.com/item?id=29865759

If you're trying to prove a point, you could at least mention something that actually caused a real problem instead of taking this one out of context. I have no idea why anyone would keep mentioning this quote or find it memorable, it seems completely insignificant to me. You also seem to be ignoring all the positive interactions this engineer (or any other Red Hat engineer) might have had. I can personally name a lot of instances where Red Hat engineers have fixed upstream bugs that were affecting me. And just to make it clear I'm not saying this to single them out for praise, a lot of other companies fix upstream bugs too. That's how open source is supposed to work.

And you actually could go and search around on old mailing lists to find similarly questionable 11-year-old quotes from Qt developers if you really were interested in digging up more old drama. These things happen everywhere that people go because people don't agree on everything. I suspect you also think that's ultimately futile though, so why keep flogging this particular dead horse? This is still way, way outside the scope of discussion for systemd anyway.

Re: Systemd, 10 years later (2020)

#303

Earlier quoted context omitted.

If your problem is with the Red Hat developers, and the fd.o developers, and the GTK developers, and the Debian and Arch and SuSE and Ubuntu developers, and the DBus developers - maybe your problem is not actually with any of these developers but a mistaken idea of how open-source development ever worked? Or what, is everyone except you under thrall to Lennart Poettering, master wizard?

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 not the every other distribution that switched to it? Do you think they were all victims of Tricksy Lennart, or?

Re: Systemd, 10 years later (2020)

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

I have to hard disagree on this one. As someone who had half a foot in sysvinit, half in upstart, and half in systemd (don't try to do math with those numbers), sysvinit was always the hardest to use by wide margin. It was ridiculously complicated to get anything nontrivial to work. It was error prone, and the number of corner cases you had to think about was extreme. And the worst part was I kept having to relearn i…

Sysvinit was conplicated by RedHat. Then SUSE followed suit. On Slackware it is just nice and simple.

Re: Systemd, 10 years later (2020)

#305

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.

that's great because the unix philosophy is pretty much a PITA as soon as you get out of grep | cut | tail | tee. I definitely don't want "unix philosophy" for operating system management, that is the wrong tool for the job.

Then you should not use UNIX then. There is another mainstream OS besides UNIX. Some people like to be able to know what their system does and like to use tools on which they can rely on even when things go wrong.

Re: Systemd, 10 years later (2020)

#306

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.

I've been using various unices for thirty years this year. I have no respect for the 'unix philosophy'.

I am married since 30 years. I have no respect for my wife /s

Re: Systemd, 10 years later (2020)

#307
post #305

Earlier quoted context omitted.

that's great because the unix philosophy is pretty much a PITA as soon as you get out of grep | cut | tail | tee. I definitely don't want "unix philosophy" for operating system management, that is the wrong tool for the job.

Then you should not use UNIX then. There is another mainstream OS besides UNIX. Some people like to be able to know what their system does and like to use tools on which they can rely on even when things go wrong.

I think it's fair to say that Linux isn't Unix and goes well beyond the design constraints of Unix that were imposed when it was originally started in 1969. That's the era you stick to when you insist on only doing things the Unix way, but there are a lot of other ways to know what your system does and have reliable tools. In current times the most common usage of Linux is Android, which is ostensibly not Unix-like at all regarding its userspace. If you're talking about GNU, that quite literally means "GNU is not Unix".

Re: Systemd, 10 years later (2020)

#308
post #305

Earlier quoted context omitted.

that's great because the unix philosophy is pretty much a PITA as soon as you get out of grep | cut | tail | tee. I definitely don't want "unix philosophy" for operating system management, that is the wrong tool for the job.

Then you should not use UNIX then. There is another mainstream OS besides UNIX. Some people like to be able to know what their system does and like to use tools on which they can rely on even when things go wrong.

yes, I don't use UNIX, I use ArchLinux which is a much better operating system for my computer needs. The "proper" UNIX I've used (macOS) really sucked in comparison.

Re: Systemd, 10 years later (2020)

#309

Earlier quoted context omitted.

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…

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

Re: Systemd, 10 years later (2020)

#310

Earlier quoted context omitted.

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

> 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 and fix it, unless the script is insane, in which case I can write a sane one.

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. I don't have a good experience with this. Nowadays I'd rather write a small script to work around that bug if possible. Much faster and much more effective.

Post reply on HN