systemd Breached One Million Lines Of Code In 2017

[oiaohm]

If you have two code bases doing the same thing, one code base uses 10.000 LoC and the other use 2.000 LoC - guess which code base that probably is more well written and has fewer bugs? Bad developers write lot of code. Skilled developers write small amounts of code.

I would say guessing by lines of code is a really bad metric. A code base more have more lines of code because the developer is more skilled and has happened to see particular corner cases or the unskilled did not comment the code to make maintenance simple. No comments can decrease LoC count a hell of a lot a times.

One could be 10 000LoC with test cases and the 2000 LoC the person did not bother writing test cases. Yes it can be that test cases are more lines of code than the production result.

Quality code is a multi metric thing. Its not just writing the code that is important its having the ability to confirm that the code is working right as well is important.

You could have the most perfectly written code no test suite and you are suffering from strange problems. What gone wrong in this case the compiler was dud and you have no test casing to detect it.

A lot more focus need to be put into documentation and being able to confirm that was is coded in fact works there are many compact on lines projects that don't have documentation or proper testing systems.

[Guest]

Yes it does. It is well known that there are a constant amount of bugs in lines of code. If you have 1000 lines, you have say, 10 bugs. If you manage to compress it to 100 lines, you have 1 bug instead. A skilled developer writes less code than a newbie. When I started to develop, my code was really verbose, and a senior skilled programmer was always able to rewrite it and discard half of my code. There is a famous story where developers at Apple(?) had to report how much code they produced each day. And the star programmer (Steve Wozniak?) spent a day with refactoring the code and deleted 18.000 lines. So he reported "-18.000 lines of code".

If you have two code bases doing the same thing, one code base uses 10.000 LoC and the other use 2.000 LoC - guess which code base that probably is more well written and has fewer bugs? Bad developers write lot of code. Skilled developers write small amounts of code.

Ok, but isn't the amount of code in systemd in particular due to 1) many features. 2) amount of boilerplate code needed to write in C?
So it is the amount of code per function/feature and not total amount of code. As a skilled developer, you are able to write the same functions in less code. The total amount of features (which is what people complain about in systemd) is going to be more or less the same though.
Because by that definition, the Linux kernel also has too many lines of code when that's not true. It has an excessive number of drivers/features/whatever.

[pavlerson]

I would say guessing by lines of code is a really bad metric. A code base more have more lines of code because the developer is more skilled and has happened to see particular corner cases or the unskilled did not comment the code to make maintenance simple. No comments can decrease LoC count a hell of a lot a times.

One could be 10 000LoC with test cases and the 2000 LoC the person did not bother writing test cases. Yes it can be that test cases are more lines of code than the production result.

Quality code is a multi metric thing. Its not just writing the code that is important its having the ability to confirm that the code is working right as well is important.

You could have the most perfectly written code no test suite and you are suffering from strange problems. What gone wrong in this case the compiler was dud and you have no test casing to detect it.

A lot more focus need to be put into documentation and being able to confirm that was is coded in fact works there are many compact on lines projects that don't have documentation or proper testing systems.

In general, skilled developers write less code than bad developers. It is the same thing in all matters, such as writing academic research papers. A bad writer will use many words to describe one thing, whereas a good writer might structure the sentence so that he only use few words to describe the exact same thing. There is a saying attributed to Einstein that goes "Perfection is not achieved when there is nothing left to add, but when there is nothing left to take away". Winston Churchill wrote once in a letter "I am in hurry, therefore this letter will be long and contain unnecessary words". To rewrite text to make it shorter and clearer takes lot of mental effort. To just blurt down random words without structure does not take mental effort. It is the same in all engineering. You should strive to remove as much redundancy as possible to only keep the minimal whats needed. Redundancy is really evil. In databases you use Normalization schemes, such as CNF etc to remove redundancy which is evil. In programming you refactor all the time to remove redundancy. APIs should be minimal so they dont contain the same unnecessary functions with different names.

Mathematicians spends centuries to minimize axioms. Axioms are a set of mathematical propositions that are used to build the entire field of mathematics upon. For instance in Euclidean geometry, mathematicians have spent thousands of years to see if the Parallel axiom really is necessary - can it be derived from the other axioms? If it can be derived, then you can delete the Parallel axiom. Many mathematicians have spent thousands of years to try to minimize the axioms for Geometry that originated from Euclides. Only in the 19th century the Parallel axiom was finally proven to be necessary and not derivable from the other axioms.

To minimize something takes real engineering talent and hard thinking. That is difficult and every engineer wants to do that if they have time. For instance, you have functionality A and B and C. But after you think a while, you realize that you can express A by combining B and C in a very clever way that was non apparent. Because if it was apparent, they would not have created A in the first place. So, you conclude that A is not necessary so you can delete A. This minimization is done continuously in programming and engineering.

So, if I have two codebases that does exactly the same thing - nothing more, nothing less and no test code - and codebase A use 10.000 lines and codebase B use 2.000 lines - then most probably the B engineers are highly talented and have spent lot of time to compress and minimize redundancy. Developers in India that have been outsourced to, often produce lot of unnecessary code. So, you are wrong. In engineering, minimzation is good. Redudancy is evil.

[pavlerson]

Ok, but isn't the amount of code in systemd in particular due to 1) many features. 2) amount of boilerplate code needed to write in C?
So it is the amount of code per function/feature and not total amount of code. As a skilled developer, you are able to write the same functions in less code. The total amount of features (which is what people complain about in systemd) is going to be more or less the same though.
Because by that definition, the Linux kernel also has too many lines of code when that's not true. It has an excessive number of drivers/features/whatever.

I dont know if systemd has too many features. But in general, one thing should do one thing only. That is sound engineering. Unix uses that philosophy, and you have lot of simple small programs that only do one thing. However, Unix has very complex ways of combining programs, so you can invoke complicated behaviour using simple programs. Some people say that systemd breaks the Unix philosophy.

Regarding the Linux kernel. Some people also say that Linux kernel is bloated. Read what Linus Torvalds says:

https://en.wikipedia.org/wiki/Criticism_of_Linux#Kernel_performance

[oiaohm]

So, if I have two codebases that does exactly the same thing - nothing more, nothing less and no test code - and codebase A use 10.000 lines and codebase B use 2.000 lines - then most probably the B engineers are highly talented and have spent lot of time to compress and minimize redundancy. Developers in India that have been outsourced to, often produce lot of unnecessary code. So, you are wrong. In engineering, minimzation is good. Redudancy is evil.

This is wrong. Because a code base from a skilled developer may have asserts and other runtime tests inside the code. So the 10 000 lines of code could have runtime testing the 2000 lines is written by a novice who did not include runtime testing living in the world of hope and pray everything is right.

https://www.gnu.org/software/libc/manual/html_node/Consistency-Checking.html

Code base with assert and other thing are more likely to throw errors before doing something completely stupid due to a compiler bug.

Redundancy is part of good engineering. Skilled developers will at times include some redundant code sometimes quite a lot. Like you might have a C version of a particular function and like 9 different arch dependant versions of that function that are faster than what the compiler will generate and the unskilled developer only include one and is having bad performance. There are cases where a code base is 10 times bigger written by a skilled developer vs a unskilled because the skilled understood the corner cases and include the code to cover them like platform dependant code where it suited.

So like it or not looking at lines of code only tells you part of the story. A skilled developer will be able to explain why they have used more lines of code. A project using more lines of code does not mean its better/worse quality than a project using less. There are many cases where the project using more lines of code is the one written by the higher skilled developer and is in fact higher quality.

Remember just because source code have more lines of code does not mean all those end up in the binary either.

Your in general also does not match up. Just looking at something like sel4 uses 5 times the size in lines of code of a equal micro kernel but sel4 is in fact certified secure and has included extra information in the source to make that possible.

Reality the so called enterprise logic on lines of code you are using pavlerson is a major stuffed up the focus on Lines of Code means that developers who include extras to improve validation of their code get punished because due to more lines of code they have to be making worse code when in fact they are making code that can be validated to function correctly.

[Guest]

I dont know if systemd has too many features. But in general, one thing should do one thing only. That is sound engineering. Unix uses that philosophy, and you have lot of simple small programs that only do one thing. However, Unix has very complex ways of combining programs, so you can invoke complicated behaviour using simple programs. Some people say that systemd breaks the Unix philosophy.

Regarding the Linux kernel. Some people also say that Linux kernel is bloated. Read what Linus Torvalds says:

https://en.wikipedia.org/wiki/Criticism_of_Linux#Kernel_performance

yeah, I don't think systemd has 'too' many features. But they are a lot which justifies the amount of code.

Regarding the linux kernel, I did not know he said that. But it does explain why he yells at people for trying to mainline their 'pet features'.

[JPerez]

i feel that maybe you should learn how it is spelled before accusing it of bugs of whole new distro?

Sorry, English is not may native language, what I did misspell?
Also, Sorry if I hurt anyone's feelings for sharing my specific case (I really hoped anyone could give me some clue), I do not want to accuse the distribution of any bug but I do suspect SystemD since it seemed to be the only big change between those versions, and because I only suspect of it I didn't post it on the project forum, I know most people involved are very sensitive and proud of their work, also if there is a problem they will probably fix it without any user's input soon anyway, but by now I need to solve the problem for this specific case, I'm still doing some tests on this problem and I prepared 2 similar devices with the new version, once I get the other hardware to continue the test I will get more information, until then I will keep using the old OS version for production.

Sorry again If I hurt anyone's feelings and feel free to correct my writing or typos.

[aht0]

Interesting enough the /etc/resolv.conf race condition effects OS X, BSD and solaris as well. So the race condition is not systemd particular.

Care to describe it? I'd like to actually try and get it. At the moment only thing I can think of, that could screw up /etc/resolv.conf is dhclient applying "wrong" DNS from ISP to /etc/resolv.conf while you are running your own resolver, which is rather easily avoidable by adding resolvconf="NO" to /etc/rc.conf.

It's not supposed to get rid of shell scripts (or any other scripting/programming language, for that matter) in its entirety.
It's supposed to get rid of shell scripts to define the actual init process as well as initial configuration stages.
Obviously, software that can't be configured through just unit files will still have to depend on some form of scripting.
That's still a far cry from SysVinit, where EVERYTHING was a massive collection of shell scripts, often interdependent of each other.

Now we have another init, which is a mere component of a massive collective of binaries, completely interdependent of each other (by internal API's) - which make developing reliable replacement shims actually a moving target - anything but easy task, opposite to what some here like to emphasize.

[duby229]

Care to describe it? I'd like to actually try and get it. At the moment only thing I can think of, that could screw up /etc/resolv.conf is dhclient applying "wrong" DNS from ISP to /etc/resolv.conf while you are running your own resolver, which is rather easily avoidable by adding resolvconf="NO" to /etc/rc.conf.


Now we have another init, which is a mere component of a massive collective of binaries, completely interdependent of each other (by internal API's) - which make developing reliable replacement shims actually a moving target - anything but easy task, opposite to what some here like to emphasize.

Oh my god! Someone else finally pointed out the same thing I do! Its a miracle!

[oiaohm]

Care to describe it? I'd like to actually try and get it. At the moment only thing I can think of, that could screw up /etc/resolv.conf is dhclient applying "wrong" DNS from ISP to /etc/resolv.conf while you are running your own resolver, which is rather easily avoidable by adding resolvconf="NO" to /etc/rc.conf.

Of course the idea of resolveconf=0 does not help those who are moving their computers between networks or switching on and off vpns. Setting resolvconf no does not prevent other items from updating /etc/resolve.conf.

So there is a issue around the way dns resolve has been done for a while. /etc/resolve.conf was design the idea of a static world. Not the dynamic world we now live in.

Now we have another init, which is a mere component of a massive collective of binaries, completely interdependent of each other (by internal API's) - which make developing reliable replacement shims actually a moving target - anything but easy task, opposite to what some here like to emphasize.

I have had the fun of attempting to use runit instead of sysvinit with debian and finding out how many places dependant on undocumented sysvinit behaviour.

The Internal API's claim is interesting. Systemd has a reducing number of internal only APIs used for inter-process communication.

So attempting to replace the init system has always been a nightmare moving target.

Sysvinit you had distributions making more of their own unique work around to problems than you have in distributions using systemd.

Key difference between systemd and sysvinit is you used collection when talking about systemd. Meaning that all the parts to boot are mostly developed under 1 roof. You go back to sysvinit go compare redhat vs debian vs gentoo..... Notice how many fragments in sysvinit are coming from all over the place with no proper central management to make sure you stand a chance they will work with each other. Result under sysvinit the distribution maintainers were doing lots of custom patching so stuff worked in the sysvinit age.

Why have distributions been choosing systemd less work by their maintainers to have it work because the upstream is doing it.

The requirements to make a init these days have changed.

massive collection of shell scripts, often interdependent of each other

This was not clear enough. Sysvinit has been a massive collection of shell scripts from independent sources patched by distribution maintainers to make a system that somewhat works. Result of this mess was swapping to anything other than sysvinit was a pure nightmare for Linux.

Shiming over sysvinit is not simple look at systemd sysvinit emulation or any other init system that attempted to shim their way into a sysvinit system to attempt to reduce work load.

Systemd being C and having to make binaries makes it very clear how much effort is involved to do shim work. Its not like systemd shims are any more work that what was required to shim something other than sysvinit into a sysvinit system. Of course systemd has less unique per linux distribution stuff to worry about.