The Development Pace Of Systemd Fell Sharply This Year

[pal666]

For my taste, they concetrate far too much on that container stuff and far too little on everything else

because people interested in everything else are posting on forums instead of sending patches

[pal666]

Depends on the situation. For systemd, I would argue no, because that means less stupid crap being put in there that doesn't need to be put in. ... Meanwhile for something like the Linux kernel, a drop in commits could be a concern.

because kernel does need more stupid crap that doesn't need to be put in? are you on drugs?

[Brane215]

Why would they send patches if they want anything done ? They could roll their own implementation.

And why should systemd any different in that regard than, say, Wayland ?

Wayland might be interesting for some mobile equipment industry, but it is developed with ordinary user in mind.

[Holograph]

Stupid Question:
Is it always better to have more commits than previous year?

Depends on what the commits are. If they are for features and those features are useful and work properly, it's good. If they are all bug fixes, it's good to get the fixes, but bad to have needed a lot of bug fixes in the first place (for such an important component in the modern Linux distribution).

[starshipeleven]

I agree that it's a sign that the project is maturing. It will mellow for a few years, then it will be time for a new init system.

Doing better than systemd is impossible.

[schmidtbag]

because kernel does need more stupid crap that doesn't need to be put in? are you on drugs?

Right... because that's completely what I was implying...

I know you have a knack for being needlessly antagonistic and connecting dots that don't belong, but this is bad even for you.

[starshipeleven]

Why would they send patches if they want anything done ? They could roll their own implementation.

Because sending patches means they don't need to do maintenance on their own fork, duh. Why you think many companies send stuff to mainline Linux kernel instead of doing their own crappy fork?

And why should systemd any different in that regard than, say, Wayland ?

Because systemd is a binary init system and Wayland is a display PROTOCOL (i.e. an API, an interface)?
I mean it's like saying "why should systemd be any different than say, openGL".
Of course everyone can have its own openGL or Wayland backend/compositor/whatever, as long as the same API is shown. But systemd isn't an API/protocol.

Wayland might be interesting for some mobile equipment industry, but it is developed with ordinary user in mind.

Wayland is interesting for every system that needs a screen and runs more than one application, and it is developed with generic display server usage in mind, as it has extensions allowing anything to be added to fit any display server usecase.

[duby229]

For the moment, I don't really see anything in the land of Linux that will supplant systemd.
Not for the many benefits that it does give the user, and I get the feeling that anything that attempts to supplant it will likely have to take that into consideration.
I honestly doubt that one will materialize until it is likely that they can replicate most (if not all) of those said benefits.

Openrc already does by and large. I would love to see logind made totally independent of systemd though.

[zdzichu]

Wait. systemd since 2003?

It's udev commit history which is included in this repo. Systemd itself started six years ago.

[anarki2]

Umm, development doesn't equal to commit number. But whatever.