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

[aht0]

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.

Isn't it "taken apart" the moment you compile kernel from source? Depending on the choosen config larger or smaller portions get excluded during compile-time out of that 27.8MLoC and not baked into binary.

[CommunityMember]

I'm guessing the reason is that they weren't major contributors

In larger projects such as this, while there is initially a fair amount of low hanging fruit, and new development that many can help with, after some point the code becomes sufficiently stable and complex enough that only those with the time, interest, and (often) employer backing, can meaningfully contribute, and some of the past contributors move on to different projects in their organization.

I do not think total number of contributors is necessarily a good metric to determine the health of a project (unless the number starts to drop precipitously), but it is certainly an easy one to produce.

[Britoid]

Isn't it "taken apart" the moment you compile kernel from source? Depending on the choosen config larger or smaller portions get excluded during compile-time out of that 27.8MLoC and not baked into binary.

According to people who preach the "Unix way", you should be able to take out your I/O driver and replace it at runtime.

[pkese]

According to people who preach the "Unix way", you should be able to take out your I/O driver and replace it at runtime.

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

[pkese]

Isn't it "taken apart" the moment you compile kernel from source? Depending on the choosen config larger or smaller portions get excluded during compile-time out of that 27.8MLoC and not baked into binary.

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.

[pkese]

Congrats, you've all been successfully trolled. Don't you feel silly?

No, I'm just honestly and sincerely trying to see how far you can push Poe's law.

[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.

[Britoid]

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

Hey clearly that's a basic freedom right?

[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]

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