Systemd Saw The Most Commits Ever In 2015

[Shiba]

Based on the direction of most distributions, it's in the extreme majority for systemd to work as intended.

Back then most distribution relied on sysv or some bsd like init, that's the majority you are talking about. Moving from 2-3 minutes to ~15 seconds made good advertising (like it is something you will ever need) plus it is backed by Red Hat and we all know that what Red Hat do is law.

The "taking away the Unix" is a misguided believe based on how most distributions package systemd. Most of systemd's features are modular and optional. You can personally build systemd with just the init system if you wanted to, leaving out pretty much everything else, but distributions don't do that because systemd's other modules are awesome from a developer's standpoint.

Yeah, they are modular and replaceable with... nothing. Most got absorbed (udev anyone?) and the rest doesn't work in other combinations (have you tried systemd+ConsoleKit? OpenRC+logind? ecc).
Also from a developer standpoint working with .desktop-like config files is a cancer.

[arokh]

Yeah, they are modular and replaceable with... nothing. Most got absorbed (udev anyone?) and the rest doesn't work in other combinations (have you tried systemd+ConsoleKit? OpenRC+logind? ecc).

So write whatever replacement you like then?

Also from a developer standpoint working with .desktop-like config files is a cancer.

Are you referring to unit files? They have made life so easy, could you please elaborate on why you compare them to a life threatening disease?

[kaprikawn]

...and I *really* appreciate the extra 30 seconds I get when I'm doing my once a year reboot...

Just because you reboot once a year doesn't mean everyone else does. The only computer I use that has more than one day uptime is my server, and I even reboot that relatively frequently because it's running Arch, so I reboot it every time there's a new kernel release in the repo.

I wouldn't normally be a distro elitist, but for you I'll make an exception...maybe if you didn't use some fixed release distro for scrubs you'd have more reason to reboot for kernel upgrades [/joke]

[cjcox]

Future commits to systemd will be made by the new commitd module.

[winie]

Good luck in making Windows more popular than ever!

People leave linux because of systemd? I guess those morons must love services.msc.
and why stop there? go on windows forums and nag microsoft to use AUTOEXEC.BAT exclusively for init like the old days

[pal666]

it is backed by Red Hat and we all know that what Red Hat do is law.

more than 700 developers and still we got imbecile with "kokoko redhat kokoko"

[pal666]

I wouldn't normally be a distro elitist, but for you I'll make an exception...maybe if you didn't use some fixed release distro for scrubs you'd have more reason to reboot for kernel upgrades [/joke]

proper fixed release distros update kernels several times per point release

[interested]

Back then most distribution relied on sysv or some bsd like init, that's the majority you are talking about. Moving from 2-3 minutes to ~15 seconds made good advertising (like it is something you will ever need) plus it is backed by Red Hat and we all know that what Red Hat do is law.

Despite what some people claim, faster boot times is always an advantage, especially on systems that rarely are rebooted since they presumably have a need to maximize uptime.

Fast boot times, while universally attractive, wasn't the main selling point of systemd; it was getting rid of hard to parse and maintain shell scripts and replacing them with plain text config files, and having an init-system with the logic to handle complex dependencies instead of leaving it to humans to hand graft those.

systemd also provided the first real service management system that Linux ever had, and now provides a defence-in-depth security framework that leaves non-systemd distros in the dust.

In short, systemd won out because of overwhelming technical superiority, not good advertising of a single feature.

Yeah, they are modular and replaceable with... nothing. Most got absorbed (udev anyone?) and the rest doesn't work in other combinations (have you tried systemd+ConsoleKit? OpenRC+logind? ecc).

You clearly aren't well informed about the technical functionality of systemd. Of course systemd works with CK or CK2 or whatever instead of systemd-logind. The core of systemd; systemd (the deamon), udev and journald is rather tiny, and everything else is optional. You can use whatever you like.
That you can't rip out random pieces of systemd an expect them to work on non-systemd distros isn't a useful criticism. In case of systemd-logind the basic fact that OpenRC etc. don't use Cgroups to name and track processes makes it impossible to use. It is like demanding that some random tablefunction in Libreoffice should magically work on Vim or ed.

Claiming that systemd "absorbs code" makes you sound that you never heard of Open Source code before. LGPL code can't be "absorbed" in any meaningful way. Udev was invented and maintained by systemd-developers, and they made it easy for non-systemd distros to fork, hence "eudev". Care to name any other projects that got "absorbed" into systemd?

Also from a developer standpoint working with .desktop-like config files is a cancer.

Come on. systemd service config files are plain text "key/value" files divided into named sections; it doesn't get easier than that. systemd init files are probably more than 60 trillion times easier to parse for both humans and machines than SysVinit shell scripts.

[Stellarwind]

"Hard to parse and maintain shell scripts" are in fact quite easy. Change few lines in the template - done. If some service needs network to be configured when it starts, I'd just put it last - I don't care that much if it takes few more seconds for it to go up.

With systemd you end up wondering why the fuck requiring network.target is not enough and then dive into documentation to find out that there is some other obscure shit, possibly requiring some copy-pasting from interwebs to actually make it wait for the network scripts to finish. There are other stupid issues with systemd, like silently ignoring incorrent lines in unit files. Ok, I made a typo - tell me about it, don't just assume the default.

In the end, systemd might be good for maintainers. For someone just writing occasional service file, it is not. Maybe when I'll finally be forced to give up and live with it, I'll take my time to learn all the pitfalls, but for now apt-get install upstart-sysv is good enough.

Systemd might be good for notebooks or mobile phones... but again, I reboot my phone once a week max, when it runs out of juice occasionally and notebooks are often just hilbernating (imo time better spend making this work flawlessly).

[Stellarwind]

Come on. systemd service config files are plain text "key/value" files divided into named sections; it doesn't get easier than that. systemd init files are probably more than 60 trillion times easier to parse for both humans and machines than SysVinit shell scripts.

Until there happens to be a bug in systemd and it just doesn't work for some reason.
Something like this: https://github.com/systemd/systemd/issues/1505
Or this: https://github.com/systemd/systemd/issues/2099
And you can't do much about this without someone, who is able to debug systemd itself, not just your tiny bash script.