Systemd Is Approaching 1.3 Million Lines While Poettering Lost Top Contributor Spot For 2019

[Lecedy]

Can't people recognize sarcasm these days? I don't think the person in question was trying that hard to avoid sarcastic tone.

[RomuloP]

Unix Philosophy is my favorite literature in the fantasy category....

[DanL]

I am all for systemd and I think Poetering should continue to improve and expand the tools that systemd provides. He should set a goal of 2 million lines of source code by years end. Its all open source source code and thus fully open for people to use as they see fit.

Uhhh, what? Let's not have code for the sake of having code. That's feature creep/bloat, and some folks already have an issue with systemd in that regard.

[jrch2k8]

Well, what sort of cleaning would you like? The great majority of issues are requests for enhancements, not bugs (only 104 bugs on the list). According to git, they are closing/resolving issues at almost the same rate as they are getting new ones.
So issues on git are not only problems and bugs, but mainly requests for new features, with a few bugs among them.

Damn, you beat me to it but again most trolls just copy and paste the issues number on the trackers and use it as argument since most of them can't even differentiate between bugs and others request there

[FPScholten]

I would like Systemd to clean/close its more than thousand opened issues. That would be a great indicator.

Well, what sort of cleaning would you like? The great majority of issues are requests for enhancements, not bugs (only 104 bugs on the list). According to git, they are closing/resolving issues at almost the same rate as they are getting new ones.
So issues on git are not only problems and bugs, but mainly requests for new features, with a few bugs among them.

[Neraxa]

That's what they all say. Even SystemD zealots will say that their 1.3 million lines of code will compile into multiple binaries, but we all know it is just another monolith.
You just can't take it apart...
Just as you can't take out from Linux a wifi driver and use it in your own script. If you can't put it in a /rc.d script, it's not Unix.

I am all for systemd and I think Poetering should continue to improve and expand the tools that systemd provides. He should set a goal of 2 million lines of source code by years end. Its all open source source code and thus fully open for people to use as they see fit.

systemd actually sypports rc.d scripts fine. In fact, you can start your services from those scripts. If you wanted to start apache from rc.d you could do systemctl disable apache to stop it from being started from the unit file and then put in an rc.d script to start it.

This is why the anti-systemd rhetoric is nonsense. it does not take away the old way of doing things, it just adds new features in addition to the older features. So apparently what anti-systemd people object to is the introduction of new features that they think other people should not be allowed to do.

systemd is all open source, so by definition, it can be "taken apart" meaning you can read the source code and do with it what you please.

systemd, due to its ability to use dbus, is also decentralized and allows a loosely coupled way of doing things. This actually allows you to write your own daemon that can respond to system events on the bus. This means it can be made MORE loosely coupled than the shell scripts. This is true especially if you write your daemons which interact with the dbus protocol.

[Britoid]

That's what they all say. Even SystemD zealots will say that their 1.3 million lines of code will compile into multiple binaries, but we all know it is just another monolith.
You just can't take it apart...
Just as you can't take out from Linux a wifi driver and use it in your own script.

monolithic project? perhaps
monolithic computer program? no

[Neraxa]

Devuan got it all wrong. Systemd is not the main problem. The real culprit is Linux.
Linux kernel violates all UNIX principles (besides, it's not even UNIX).
It is a single monolithic repository with 27.8 million lines of code that can not be taken apart.
The Linux kernel is forcefully pushed to us by multi-billion dollar corporations like Redhat and the likes.
Devuan should dump this malicious attempt of corporate infiltration into OSS ecosystem and switch to Gnu Hurd instead.

Who is funding the kernel is ad hominem and this attack is also completely absurd and backwards because you are basically insulting these companies for doing the RIGHT THING by contributing to open source development and causes. That is ludicrous. The investments companies are making in the kernel is something we should welcome with open arms and encourage and give them gratitude for doing so.

Everything else is just plain flat out wrong. Its no different than most standard kernels. Monolithic vs microkernel is an architectural issue. Most kernels are monolithic. Hurd would have the same features in its tree as well. Microkernel/multiservers have suffered from performance issues which remain just part of the nature of its design.

That being monolithic means not modular is a myth because kernels can be built with static linking which would have no impact on speed but allow for the build system to allow different files or features to be substituted or opted at build time according to compile options and the use of the preprocessor. There is also dynamic linking (loadable kernel modules). Patch sets are also used and most of the distros actually do apply their own patch sets to the kernel. This refutes what you are saying.

Its an open source kernel under GPL, anyone can use it and access the source code and do with it what they please. Its not Windows where its a proprietary blob, so stop making that false comparison.

A good part of the line count is device drivers, because device drivers are encouraged to be mainlined, this makes sense actually, since it makes running tests of the device drivers easier and basically provides a built in test suite for the kernel to ensure compatibility with device drivers. There is a lot of other stuff that needs to be in the kernel and always has been since the early Unices such as the filesystems, networking, scheduling, security infrastructure, and so on. Security infrastructure has improved and has needed to with sandboxing and so forth. The features in the kernel are to provide improved services to the applications, to provide more flexibility and capability to applications, to allow applications to be protected from one another, for trusted applications to be able to manage and apply security to other applications.

The Linux kernel has also worked to ensure backwards compatibility on the system call interface for applications, even though the kernel often adds new features and capabilities, effort goes into making sure this does not break applications. Linus has resisted calls to remove legacy application facing interfaces from the kernel to avoid breaking old applications. This relates to binary builds of applications, source compatibility is stronger than binary compatibility, but the kernel has taken binary compatibility seriously. Like most kernels, including the BSDs, Linux undergoes constant improvement, but goes to lengths to ensure application compatibility.

While the kernel release process does include effort to ensure stability, Most non-rolling release distros do not advance to a new kernel version immediately so if stability is your concern a distro kernel tends to be stable and more tested. An LTS distro release offers the most stability. If you want to test new kernels as they come out, feel free, rolling releases tend to have a more aggressive update schedule, but if stability is your concern its not the best option so don't complain if you do.

[Britoid]

...or at least write a filesystem driver in shell script.

Hey clearly that's a basic freedom right?

[Vistaus]

Just as you can't take out from Linux a wifi driver and use it in your own script.

Is FreeBSD more compliant then? 'Cause Haiku takes drivers from FreeBSD and use them in their own kernel.