systemd Breached One Million Lines Of Code In 2017

[rtfazeberdee]

Let us ignore the fact that dnsmasq before systemd-resolved implementation could do the particular job without problems. So, let's analyze the pattern - before systemd component - shit worked. After systemd component ate dnsmasq - some particular shit stopped working properly.

its all about configuration. stick "systemd-resolved dnsmasq" into google and you'll find a world of help.

Ironclad logic tells us: user is at fault, right? smirk again

yes, if they haven't configured it correctly.

[rtfazeberdee]

Google query for "systemd dns issues" returns whopping 393 000 results.

Software has bugs ? or people can't configure stuff properly?? Good grief, that is shocking and unexpected.

[aht0]

Software has bugs ? or people can't configure stuff properly?? Good grief, that is shocking and unexpected.

Nah, but according to the people in raging denial Google should be lying..

[F.Ultra]

Software has bugs ? or people can't configure stuff properly?? Good grief, that is shocking and unexpected.

AFAIK this is more due to bugs in configurations. I.e on some upgrades of Ubuntu to 17.10 Network Manager still is configured to take control of resolv.conf and thus the 172.0.1.53 line that systemd-resolved needs there in order to service local requests are never added and suddenly DNS does not work. Lot's of the supposed systemd problems comes from that we are slowly moving away from a haphazardly connected system held together with duct tape where people have spent days creating their own special configuration in order to make things work.

[F.Ultra]

Like it or not System Services for Windows used properly in NT 3.5 was better than sysv init. People forget services in NT 3.5 could not open graphical windows because they were disconnected from the user session. Normal Microsoft they went for convenience over security and broke it. Even the introduction of session 0 in latter windows does not really fix it back to NT 3.5.

Key advantages the old NT 3.5 system services and Systemd have over Sysvinit.
1) The ability to tell if any process of a service is still running even if that process has forked off.
2) The ability to absolutely shutdown a service including any part that had forked off.
3) The ability that when you told system management to restart a service that it would because the system management could stop all the service then start it clean again where under sysvinit this could fail.

NT 3.5 did not have automatic service restarting instead of crash they just stayed down and also did not have dependency boot either.

Sysvinit was not design for the Linux kernel. Sysvinit is not design for a operating system that can recycle process id numbers what a true sysv OS did was just keep on increase PID number when it reached maximum kernel panic it was why fork bombs in them were so deadly. Linux kernel recycles process id numbers.

Reality is sysvinit should have been got rid of years ago. BSD init in fact has proper dependency boot.

Also the million lines of code. If you go back to 1990s Take a close look at all the part being used to init the system and provide key supporting parts you find over a million lines of code spreed over 500 projects that systemd in modern distributions replace. Next when you look at that over 500 projects you find that most were not being maintained properly where CVE bugs were left open for years to decades.

Now those who don't like systemd I am not going to say you are wrong. There is no question making the arguement to remain on sysvinit is wrong when it technically incompatible with the kernel in usage. I take my hats off to Gentoo and TrueOS developers who are working on openrc because they don't like systemd .

The reality is lot of the historic init systems used on Linux attempted to be operating system neutral. The result is they were all incompatible with the Linux/BSD kernel in different ways. Systemd lead developer did get that fact right. There are kernel dependant stuff that any init system need to be aware of if it not its broken.

Really there is no clear define of a list of tests a init system/ service management has to pass to be classed as production useful. Sysvinit was a defacto standard not a standard where we all sat down and wrote what a init system/service management must do.

Even systemd is still going the defacto standard route. At some point we will wake up and truly standardise the init and service management requirements.

While NT 3.5 didn't have service restart and dependencies but they implemented that sometime later (don't really remember if it was in Windows 2000 or if it came later) but it's definitely there now because I use it for the unfortunate customers of ours that refuse to use anything other than Windows.

While your second point is probably correct (I've never used fork on Windows), it's quite simple to completely hang the shutdown process of a service indefinably and also in such a way that you cannot even shut it down via the Task Manager since you can set the timeout to infinite in your application and then refuse to send the SERVICE_STOPPED or even not setting the SERVICE_ACCEPT_STOP flag when you init your system service.

My reasons for claiming that it's worse then even sysv is #1 that you have to add code to your application in order to run as a service since it does not call the normal main(), #2 that Microsoft never released any tool to add or remove services so every application had to write their own install-part and #3 that you could hardly edit anything about a service using the GUI so you had to instead dive deep into the not so lovely registry.

Not to mention the horror that is Windows Event Viewer where you for several years had to write your own resource compiler and where Microsoft tried to badly reimplement GNU gettext(). And until recently there where no built in way to export the logs to text leading to people sending millions of screen shots when trying to show logs...

[arokh]

Where did I state I am using it myself, smirk? So, fast to attack and insult. Credible pro-systemd arguments there.. Wait, there was not a single argument, just cheap demagogy.

The argument is that your so-called "bug" is just your own incompetence!

Fact: You being incapable of correctly setting up a VPN is not systemd's fault.

Let us ignore the fact that dnsmasq before systemd-resolved implementation could do the particular job without problems. So, let's analyze the pattern - before systemd component - shit worked. After systemd component ate dnsmasq - some particular shit stopped working properly. Ironclad logic tells us: user is at fault, right? smirk again

See previous fact.

If I and others don't understand then perhaps it's problem of the software itself. Why live in automatic denial? smirk

Hey, I don't know how to fly a plane. That means planes have faulty designs!!

Bunch of boyos here in Phoronix over the past couple of years..? Who kept pointing out how .bad and cumbersome sysV init and shell scripts combined are, and how systemd is supposed to make it all go away. Also it was one of the hard arguments for getting the systemd bandwagon initially rolling. Let's ditch the shell scripts, lets make it all easier..

Uhm, it did make SysV go away. Still repeating systemd was supposed to replace shell scripts? You really have no fkn clue do you?

Good for you. But you are not making up the whole world. Grow up.

Take your own advice and grow up. That means learning stuff.

Google query for "systemd dns issues" returns whopping 393 000 results.

I just googled "systemd perfect" and got 358 000 results. See where I'm getting with this? Like how absolutely ridiculous thing that is to say?

[sthalik]

The proper engineering solution is having multiple projects, each maintained by a separate group of people.

This way, user of a dependency will spot if the API is crap, or otherwise non-functional. Leaving a big blob of a project in hands of a monolithic group of committers creates an echo chamber. This is especially relevant given systemd's cases of refusing to acknowledge bugs or blaming the kernel for their own mess.

This isn't true in each case, but overall a separation of concerns is good. You get called out for BS you write. Ideally there's an alternative dependency you can fall back onto.

And wow, what the hell is that. This should never be a single repository!!! Make a central repository consisting just of git submodules, or not at all. Why not have sysvinit written in Visual Basic while we're at it.

See also the test subdirectory. It's smaller than for a typical single project including unit tests. Note that individual systemd projects don't contain their own "test/" subdirectories. Their tests are also short and useless, barely checking of anything works at all. Proper practice here is adding tests for bugs that just got fixed.

Compare this with Qt 5, which is a big project in its own right. I just build qtbase, qtserialport, and qttools. Only the former is "big" by any standard.

[pal666]

sorry, can't help you with a distro

it is not like fedora needs your help

[pal666]

I feel that maybe SystemD is not designed for embedded systems.

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

[pal666]

I don't think

thinking is hard. consider also don't posting shit