Systemd Creator Lands At Microsoft

[abott]

Systemd is better than all the shell script trash "systems" before it, and if you can do it better, I'm sure you would.

You can't, you won't, and systemd is better than any other trash boot systems. Get over yourselves, ffs.

[hoohoo]

Out of curiosity, and while I respect everyone's opinion, is labeling systemd a monstrosity your own stance based on your principles, or have you actually encountered some technical restriction or workflow disruption due to using systemd, thus arriving at the conclusion that it is a monstrosity?

I started with Unix (Solaris) i the '80s and moved to Linux around 1993 iirc. Pre systemd the init system, system mgmt, runlevel mgmt, logging, pretty much everything, was done with shell scripts and text files. I could directly read the config and log and logic. Changing the system config was that easy too.

My objection to systemd is two fold:
1) it replaced all the above for the most part with binary code, and a constantly moving target that borgs more and more of the non kernel with every release. It replaces perfectly good functionality and daemons that people have known and used for decades for no better reason than Poeterring and company want to. So, unless one was spoonfed systemd from birth it actually has made system admin more difficult and more obscure. Now it did solve some problems, primarily it is good at hot loading driver modules.
2) systemd includes some really braindead decisions, primary being that at a certain point it dropped a level of abstraction between PCIe and device names. If I plug a new card into a box using systemd then likely my network devices will show up under new names after booting up. This is stupidity beyond adjectives.

There is an old saying: If it ain't broke, don't fix it. Poetterring has been "fixing" stuff that weren't broke and imo in the process making stuff worse.

[sinepgib]

I started with Unix (Solaris) i the '80s and moved to Linux around 1993 iirc. Pre systemd the init system, system mgmt, runlevel mgmt, logging, pretty much everything, was done with shell scripts and text files. I could directly read the config and log and logic. Changing the system config was that easy too.

Having been used before isn't the same as being better. You could read the logic, that much is true. Changing the system config is trivial under systemd, compared to grokking arbitrary scripts.

My objection to systemd is two fold:
1) it replaced all the above for the most part with binary code, and a constantly moving target that borgs more and more of the non kernel with every release. It replaces perfectly good functionality and daemons that people have known and used for decades for no better reason than Poeterring and company want to.

Here's that beautiful braindead argument that this was the only reason systemd exists. By that logic, neither daemontools nor upstart, which predate systemd, would exist, because Poettering was not involved. Besides, some community distributions which aren't relevant enough for Red Hat to try and force their hand decided to adopt systemd, such as Arch, because it actually made their life easier. And no, the tight coupling with GNOME (which is a problem) was not the reason, as they could have gone with elogind like Gentoo did.

So, unless one was spoonfed systemd from birth it actually has made system admin more difficult and more obscure. Now it did solve some problems, primarily it is good at hot loading driver modules.

That's your opinion I guess.

2) systemd includes some really braindead decisions, primary being that at a certain point it dropped a level of abstraction between PCIe and device names. If I plug a new card into a box using systemd then likely my network devices will show up under new names after booting up. This is stupidity beyond adjectives.

It may or may not be a good thing, but it's certainly not painted accurately. The new scheme may lead to unreadable names, but those are actually much more predictable than the old ones. It's real fun to have your card be eth0 when that's the only card, but connect a second one and enjoy your random name assignment because one just announced itself to the kernel first. Same for disks.

There is an old saying: If it ain't broke, don't fix it. Poetterring has been "fixing" stuff that weren't broke and imo in the process making stuff worse.

Because a system without dependency handling works marvels, specially when one is turned off and the dependent ones can't tell.


The real reason systemd won is people like you. A better solution could have been implemented, if only the loudest critics weren't fixated on denying problems existed. You gave a false dichotomy for free to the systemd folk, very bad strategy. Because of you, systemd looked as if it competed with sysvinit rather than daemontools-like solutions to sysvinit's problems.

[hoohoo]

Having been used before isn't the same as being better. You could read the logic, that much is true. Changing the system config is trivial under systemd, compared to grokking arbitrary scripts.



Here's that beautiful braindead argument that this was the only reason systemd exists. By that logic, neither daemontools nor upstart, which predate systemd, would exist, because Poettering was not involved. Besides, some community distributions which aren't relevant enough for Red Hat to try and force their hand decided to adopt systemd, such as Arch, because it actually made their life easier. And no, the tight coupling with GNOME (which is a problem) was not the reason, as they could have gone with elogind like Gentoo did.



That's your opinion I guess.



It may or may not be a good thing, but it's certainly not painted accurately. The new scheme may lead to unreadable names, but those are actually much more predictable than the old ones. It's real fun to have your card be eth0 when that's the only card, but connect a second one and enjoy your random name assignment because one just announced itself to the kernel first. Same for disks.



Because a system without dependency handling works marvels, specially when one is turned off and the dependent ones can't tell.


The real reason systemd won is people like you. A better solution could have been implemented, if only the loudest critics weren't fixated on denying problems existed. You gave a false dichotomy for free to the systemd folk, very bad strategy. Because of you, systemd looked as if it competed with sysvinit rather than daemontools-like solutions to sysvinit's problems.

If I plug in a second NVMe drive or a second GPU and that changes the names of my network interfaces thwn that is just crap design. Don't care that the new name is directly tied to what ever PCIe state the cards now live at. Back before systemd this did not happen.

All I got from you, buddy, is a lot of sophistry about why systemd is good. Or it is good if you look at it a certain way. Or counter to it's global PCIe device naming makes it better because the old scheme might in one case change your ethernet card names. Whataboutism has come to disro design. Wonderful.

I'm kinda glad MS borged the guy, hopefully he will not have time to gin up libc and libm and libstd++ with deep rooted runtime dependencies on whatever he decides to include in systemd this week.