Diseased Open Source Software Community - it's about ethics in Code of Conducts

[LOWERCASE LETTERS]

This is why windows rules and linux sucks and is gay. Y'all can't even agree how to make a computer start up

 

[Atlas Sneezed]

This is why windows rules and linux sucks and is gay. Y'all can't even agree how to make a computer start up

The service manager concept of windows was the direct inspiration for systemd...

The only good thing about systemd was watching Kay Sievers (Lennarts right wank hand) getting btfo, seething and malding on lkml trying to merge kdbus. For those not in the known, Lennart and co were so incompetent that they absolutely failed in the deserialization part of dbus making it too to slow pass messages larger than a couple of lines. Their fix? Put it in the kernel of course, what could go wrong!

Thankfully the kernel people put them through the thousand-cuts treatment and they threw in the towel after about a year, trying to rewrite it into dbus-01

 

[Looking Glass]

My systemd experiences are usually the opposite... "Shutdown" .... "Waiting for something.... 1 minute of 3 minute timeout" Why, there was literally nothing running except a couple terminals.

Did you know that mpd will halt the shutdown process until the currently playing track finishes? That's usually what my unreasonably long timeouts are.

Edit in response to edit:

The only good thing about systemd was watching Kay Sievers (Lennarts right wank hand) getting btfo, seething and malding on lkml trying to merge kdbus. For those not in the known, Lennart and co were so incompetent that they absolutely failed in the deserialization part of dbus making it too to slow pass messages larger than a couple of lines. Their fix? Put it in the kernel of course, what could go wrong!

Dbus is an abomination in nearly every aspect and should be destroyed. I am very happy kdbus was never merged.
Not only does dbus's system/session bus concept force arbitrary layers of services that don't play nice in any kind of nested service scenario, but the under-typing of the system, and design around glib's variant type makes it such a pain to deal with from any language or library.

 

[SleeplessEcho]

Windows is a Chromium bootloader for the average retard

Thank you. I laughed hard at this, and I really needed that today.

Older versions of mysql (pre-innodb) would absolutely shit itself. Newer ones will probably recover depending on which exact op it would be. Postgres will complain and possibly rollback the wal transaction. Neither of the above should be expected to be caused by a fucking init system.

Better yet, disable all journaling and async on XFS, start writing (complaining how it's now dog slow) to disk then pull the plug. Once you realize your filesystem is trashed go ahead and mail Ted Tso how his filesystem is shit because it should obviously be powerloss resistant without all the mechanisms that make it so

Not to dogpile (because you're already being told the same thing on many fronts), but your Java app corrupting data on SIGKILL is not systemd's fault; it's simply a consequence of it not being designed to be crash-safe. As most software is(n't), in fairness.

Systemd may be utterly retarded in its handling of this scenario (as it is so often) and the devs are known intractable blobs of fragile ego, sure. But assuming that a process may be killed at any point (by simple virtue of powerloss, if nothing else) is old news in programming. You either make your program resilient to it (hard), or offload the bits that need to be to a crash-safe software (such a transactional DB).

And XFS will absolutely survive doing what you just described by the way, as will ext4 with journaling, or ZFS, or any decent, modern(-ish) filesystem.

 

[bort420]

u can and probably should catch SIGTERM if u need to do any sort of cleanup on death

 

[Atlas Sneezed]

but your Java app corrupting data on SIGKILL is not systemd's fault

It wasn't *mine* as in I didn't write it. I was a sysadmin at the time. It was written by Day (and later acquired by Adobe). But guess who had to stay in the office every time to nanny the recovery every time the app was fucked by systemd?

But assuming that a process may be killed at any point (by simple virtue of powerloss, if nothing else) is old news in programming.

Absolutely agree.

And XFS will absolutely survive doing what you just described by the way

Not if you disable journaling (same for ext3/4) which I mentally equate to what systemd was doing to me. Like I said there's a difference between an accidental crash and outright malice coming from the init system.

 

[RepeatedMeme]

u can and probably should catch SIGTERM if u need to do any sort of cleanup on death

Absolutely, but that wouldn't help with Monsieur Sneezed's problem - Systemd, quite retardedly, sends SIGKILL, and sends it immediately. At some point, SystemD should send the kill, but only after it's given the process and it's children time to gracefully cleanup. In fact, it shouldn't even be sending the TERM signal to the children directly - It should let the program handle it's children as it wishes; The default TERM handler will propagate. Hard-killing the children robs you of the ability to do a final checkpoint, to quiesce, or to send remote clients a "Hey, retry this request, this was a soft-error".

 

[Eternal Spirit of Light]

And what would be building your packages for your custom OS? NASA? AMD going to drop you an EPYC server to throw in a datacenter to become a build server? Whose going to manage package upgrades, patches, version compatibility?

So an emerge takes too long. Yet you want to build an OS from scratch (which requires compiling everything from source), yet that will be okay.

Gentoo has binary packages and has had them for a year plus now.

Yes, I will do everything myself. Problem?
You might not be able to do it, but I will. Your criticism is trivial.

 

[bort420]

Absolutely, but that wouldn't help with Monsieur Sneezed's problem - Systemd, quite retardedly, sends SIGKILL, and sends it immediately. At some point, SystemD should send the kill, but only after it's given the process and it's children time to gracefully cleanup. In fact, it shouldn't even be sending the TERM signal to the children directly - It should let the program handle it's children as it wishes; The default TERM handler will propagate. Hard-killing the children robs you of the ability to do a final checkpoint, to quiesce, or to send remote clients a "Hey, retry this request, this was a soft-error".

lmao ok systemd is fuckin stupid for doing that

oh it's configurable: https://manpages.ubuntu.com/manpages/focal/man5/systemd.kill.5.html

u can probably make it do what u want but lol still

 

[SleeplessEcho]

It wasn't *mine* as in I didn't write it. I was a sysadmin at the time. It was written by Day (and later acquired by Adobe). But guess who had to stay in the office every time to nanny the recovery every time the app was fucked by systemd?

Poor wording on my part. Yeah, I got from context you were the sysadmin stuck with nannying that particular software (and I've worn that hat for 10 years so, my sincere condolences) and not the dev.

Not if you disable journaling (same for ext3/4) which I mentally equate to what systemd was doing to me. Like I said there's a difference between an accidental crash and outright malice coming from the init system.

For "traditional" filesystems such as ext4 and xfs, the journal is the mechanism through which they achieve crash safety. Disabling it implies opening yourself to data corruption on crash, which you (a sysadmin) really ought to be familiar with.

There are other ways to achieve crash safety, but afaik only one is mainstream and it's copy-on-write data formats (ZFS being the most notable in this class). Those FSs don't need journaling (although they can still benefit from forms of it, such as ZFS's SLOG).

And while I get (I sincerely do, I have been a sysadmin running prod systems for the better part of a decade!!) your point that there's "a difference between an accidental crash and outright malice coming from the init system", I must insist that in truth there truly isn't, and either a system (as a whole) is crash-safe or it isn't.

 

[Lady Ivlia de Nîmes]

and design around glib's variant type makes it such a pain to deal with from any language or library.

GLib's variant type is actually designed around DBus variants, not the other way around.

In general I'm mostly fine with DBus. Yes it's really not well designed, but there is a lot of value in having a standardized protocol for triggering actions instead of every tool implementing its own socket protocol. This way they can be triggered easily enough in shell scripts using qdbus/busctl instead of having to write special application for interfacing with every tool.

 

[Frederica Bernkastel]

I honestly find that Linux is not that good to use for anything serious, especially arch-based distros.

I mean... I use my Linux PC to pay bills and make phone calls. All you need to do anything serious is a browser. The people who tend to say this are people who focus primarily on gaming.

 

[Looking Glass]

In general I'm mostly fine with DBus. Yes it's really not well designed, but there is a lot of value in having a standardized protocol for triggering actions instead of every tool implementing its own socket protocol. This way they can be triggered easily enough in shell scripts using qdbus/busctl instead of having to write special application for interfacing for every tool.

This part isn't the problem. The problem is that it ended up being dbus and not something far better, which wouldn't be hard to make.

 

[x3firehexx]

My systemd experiences are usually the opposite... "Shutdown" .... "Waiting for something.... 1 minute of 3 minute timeout" Why, there was literally nothing running except a couple terminals.

If you are this pissed just hold the power button down for 5 seconds

 

[CNerd Prog]

Why do many projects call themselves an OS when they only do packages? NixOS, Guix?

 

[Cuckoman]

Absolutely, but that wouldn't help with Monsieur Sneezed's problem - Systemd, quite retardedly, sends SIGKILL, and sends it immediately. At some point, SystemD should send the kill, but only after it's given the process and it's children time to gracefully cleanup. In fact, it shouldn't even be sending the TERM signal to the children directly - It should let the program handle it's children as it wishes; The default TERM handler will propagate. Hard-killing the children robs you of the ability to do a final checkpoint, to quiesce, or to send remote clients a "Hey, retry this request, this was a soft-error".

That is a genuine mis-design in systemd. You are right.
Aside from that I think the biggest issue with systemd is that Pottering is very abrasive and often seems to refuse reasonable bugreports or suggestions just because. He does seem very difficult to work with, but so are many of these autists.

What systemd does right though is that for all its flaws it does manage to compute the ordering of starting/stopping services (most of the time) correctly. I like having a full blown system booting to a running system in 2 seconds or less once the kernel and initrd is finished.
That instead of taking 90 seconds to boot is a big deal for some workloads. Think batch jobs that consist of "spin up tens of thousands of machines and let them run, crunch data for 10 minutes, and then shutdown".

I also like that things like suspend and resume now mostly work on my laptop. I never had that working in the pre-systemd days and any accidental "shut the lid of the laptop" would require a powercycle and a full fsck to recover.

Most of the hate on systemd is more I think because it is popular to hate on it than actual issues. Sure there are issues with it ut imho there are less issues with it than sysv-init

EDIT: Or, since we are talking about Pottering. Maybe the SIGKILL is by design to punish people that do not write plugins for systemd to manage their service. Can not rule that out.

 

[CNerd Prog]

I mean... I use my Linux PC to pay bills and make phone calls. All you need to do anything serious is a browser. The people who tend to say this are people who focus primarily on gaming.

You can do everything on ChromeOS if you hate yourself.

 

[Eternal Spirit of Light]

I mean... I use my Linux PC to pay bills and make phone calls. All you need to do anything serious is a browser. The people who tend to say this are people who focus primarily on gaming.

I haven't played any games in a year nor do I plan to in the near future. Please understand that what I say may not be logical or intelligent at times because I am driven by my rage at computer software. (Rage against the machine, one might say)

 

[Max Free]

The service manager concept of windows was the direct inspiration for systemd...

That supposed to be a bad thing?
It doesn't really matter, as you trade in one poison against another in FOSS world. Eventually, people would just get used to the bugs and misbehavings and would work around them in a standardized way, if they wouldn't had to consider 100 other systems that try to do the same in a somewhat different way and have their own bandwagon of problems. systemd is popular not necessarily because it does things so good, but some unification and standard approaches are badly needed on Linux OS' even if they are inperfect.

 

[unaboomer]

The maintainers seemed to be hostile (downright aggressive sometimes, even) and didn't seem to tolerate any critique well,

A Red Hat spokesman at a conference several years ago had a similar cavalier attitude when explaining the switch to SystemD for RHEL 7, essentially replying YES.PNG when someone pointed out the prescriptive approach Red Hat was using to force the adoption of products nobody asked for:

As a leader in the industry, yes, we do steer the consensus on which technologies should be adopted. There will always be dissenters, but we have to do what's best for the greater good of all stakeholders.*

* Paraphrased, but it was every bit as dismissive and condescending as you could imagine