From the systemd source code

Here you can discuss every aspect of Debian. Note: not for support requests!

Re: From the systemd source code

Postby Head_on_a_Stick » 2015-07-22 17:41

millpond wrote:to save a few seconds at boot ime

viewtopic.php?f=20&t=120157
Black Lives Matter

Debian buster-backports ISO image: for new hardware support
User avatar
Head_on_a_Stick
 
Posts: 12612
Joined: 2014-06-01 17:46
Location: /dev/chair

Re: From the systemd source code

Postby tomazzi » 2015-07-22 19:24

ehh...

mor wrote:Fair enough, but it is not what NkfzGx3ok asked you.
It would be nice if you could answer to the merit of that question.

NkfzGx3ok wrote:So just for peace of minds sake before I waste my time at some point: If I have an ack through the sources of say... sysvinit, linux kernel, glibc as basic blocks for the system I will not find a single FIXME (let alone one containing ?'s) and certainly no "probably", "somehow" or "likely" in the comments because work-arounds and assumptions have had to have been made?

[answer]
Yes, it is obvious that almost all sources are containing comments marked as "FIXME", "TODO", "HACK", etc.
But, there can be a huge difference between importance/severity of problems/suggestions which are expressed in this way. It is especially important to know how particular problem or workaroud affects the stability or functionality of a program, where by functionality I mean: expected behaviour, described in the official specification.
[/answer]

Example:
wiki: "<systemd> Tracks processes using Linux cgroups"
wiki: "<systemd> can safely shutdown service, regardless of its state" (removed, after I've pointed out that this was simply a lie)
Now:
Code: Select all
/* FIXME: For now, we will not wait for the
* cgroup members to die, simply because
* cgroup notification is unreliable. It
* doesn't work at all in containers, and
* outside of containers it can be confused
* easily by leaving directories in the
* cgroup. */

What does it mean: It means, that actually systemd just can't track the processes, but also it can't even guarantee safe termination of a service process.

Now, if You'll read Fixme's listed in sysvinit, glibc, etc, You should be able to note one thing: they are mostly harmles side notes like f.e. "this can be done in a better way", and definitely none of the problems described there is affecting the stability or functionality of the code.
Can You see the difference?
------------
But there are even worse bugs, which are not even commented - they are silently ignored.
Systemd can be started without signal handlers installed - what means, that it can fall into undefined state (this is one of the bugs which I've reported). Apparently Lennart knew abut this bug, because he said that ~(more or less) "actually we don't know how to solve this, so we have decided to simply ignore it".
But: You won't find a single word about this in the related fragment of code.

Removing comments won't solve the problems.

Regards.
Odi profanum vulgus
tomazzi
 
Posts: 730
Joined: 2013-08-02 21:33

Re: From the systemd source code

Postby mor » 2015-07-23 07:52

@tomazzi
My bad, I should have been more clear.
I was not referring to that bit you quoted, since between that and the post of yours I addressed, there was already a reply from NkfzGx3ok and a counter reply from you.

In the post right above yours NkfzGx3ok asked this, which follows the reply from the bit you quoted:
NkfzGx3ok wrote:
tomazzi wrote:This is a *complete* list of Fixme's for sysvinit 2.88: (all from init.c)


That is good and I didn't expect much from it but the point is sysvinit or systemd-init are really peanuts in the system when compared to the kernel, glibc, gcc and a whole bunch of little things not worth listing when it comes to using and controlling our systems.

I speak English for ~10 years but still make mistakes in understanding so I apologise if I am wrong but it seems to me you have laid out a set of rules/conditions in which you single out systemd as being "dangerous crap", yet if you set out to apply these rules on other important softwares you find it there too! It seems quite unfair to single out systemd if other basic building blocks mentioned also pass these conditions you set against systemd. Will you also in this public forum declare them dangerous crap and vow to stop using them? Change OS? Stop using computers altogether? Where does it end?! That they too also have them is most certainly not an excuse for systemd to have them, it is however unfair to single out systemd on the matter in my opinion.

Emphasis addedd

This is what I was referring to. ;)

By the way, do you have a word or two for my question?

Bye
User avatar
mor
 
Posts: 970
Joined: 2010-08-28 15:16
Location: mor@debian

Re: From the systemd source code

Postby dasein » 2015-07-23 10:18

I am gonna hate myself for rising to the bait...

For the benefit of those who may have somehow missed it the first time around, here is a handy link back to the post where tomazzi already clearly articulated the key differentiator. Anyone who isn't just trolling might want to read that post as many times as required until s/he can answer the question of why someone might legitimately imagine that systemd should be held to a higher standard than, say, Xorg.

mor wrote:By the way, do you have a word or two for my question?

I do: straw man.
Image

To be abundantly clear, when you ask for:
mor wrote:...reliable statistical information about the supposed incidence on the field of systemd's dangerous proneness to failure?
you're asking for data that:
(a) you know don't exist (or you would have at least linked to it)
(b) wouldn't actually address the underlying question even if it did exist

Worse, you're subtly implying ("supposed incidence") that unavailability of data is somehow equivalent to nonexistence of the phenomenon. (See https://en.wikipedia.org/wiki/Argument_from_ignorance)

WARNING: Actual math follows

Edit: In the absence of systemd-specific data, it's still possible to come up with a statistically serviceable estimate of the "supposed" incidence of the kinds of issues tomazzi is focusing on. A few years back, researchers at UC Berkeley undertook an aggregate analysis of failures in exception-handling code across multiple authors and multiple FOSS projects (both small and large), totaling over 5MLOC. They found over 1,300 error-handling failures, equivalent to an average defect rate of roughly one per 4,000 lines of code.

Edit 1.5: For the benefit of those who wouldn't know a KLOC from a jelly doughnut, 5 million lines of code is equivalent to several centuries worth of development effort. Why does this matter? Because the Law of Large Numbers bestows a strong presumption of representativeness on any sample that large. Sampling error is always theoretically possible, but any such claim would have to be supported by extraordinary evidence.

Edit the Second: Extrapolating the research results to systemd as a rough, order-of-magnitude estimate supports an inference of several dozen similar points of failure within systemd. ("Supposed incidence" indeed.)

Edit #2.5: The estimate of "several dozen" actually gives systemd authors the benefit of a doubt to which they are almost certainly not entitled: that they are as conscientious as an average FOSS dev about error handling. In point of fact, most of the code in systemd comes from two developers who historically treat error handling as an unnecessary annoyance, or view it someone else's job. Not QFT, but it wouldn't be at all surprising, statistically speaking, if systemd contained over 100 exception-handling failures.

Edit the Third (and hopefully last): For the benefit of non-programmers, it's important to realize that exception handling is the single most crucial element in creating robust, trustworthy, crash-resistant code. In practice, less than half of production-quality code is devoted to its intended function; the rest is devoted to error prevention and handling.

Edit IV (long after the fact): It's worth acknowledging that not all exception-handling errors are created equal. Some are relatively benign, while others are potentially catastrophic. But it's important to realize that malicious intent is not required for code to be destructive; sloppiness is more than adequate to bork a system, particularly in operationally critical code.


It's sad, almost pathetic, that what started off as a funny, light-hearted attempt to use code comments to make accessible to nontechnical users some of the sloppiness in systemd has degenerated into yet another thread recycling the same old arguments and the same old fallacies from systemd apologists.

Now, to minimize my self-loathing, I leave this thread to the attentions of others.
Last edited by dasein on 2015-07-26 15:23, edited 7 times in total.
User avatar
dasein
 
Posts: 7775
Joined: 2011-03-04 01:06
Location: Terra Incantationum

Re: From the systemd source code

Postby mor » 2015-07-23 10:52

dasein wrote:
mor wrote:By the way, do you have a word or two for my question?

I do: straw man.

It would have been interesting to see whether tomazzi would have read in my question the same malice that you read in it.
But now it is not possible anymore, isn't it?

Anyway, it is interesting for me to see how you have absolutely no interest in understanding what I am saying and it is definitely not about the length of my posts.
You have your preconceived opinion of what I am saying, you have your own unshakable moral certitude that you have it all figured out and nothing can make you see beyond what you want to see.

It doesn't matter anyway because, you said it:
dasein wrote:Now, to minimize my self-loathing, I leave this thread to the attentions of others.

It would serve no purpose trying to explain or argue.

I'm happy to hear from you though.

Bye
User avatar
mor
 
Posts: 970
Joined: 2010-08-28 15:16
Location: mor@debian

Re: From the systemd source code

Postby spacex » 2015-07-23 11:45

Well, nice to see that we are tolerant, open-minded people with no tunnel-vision at all. No matter what side we're coming from :lol:

To be serious, we should be able to strongly disagree with each other and still treat each other with some kind of dignity and respect. People disagreeing is actually what drives Linux forward. It's a good thing. Where everyone agrees, there's no one thinking at all. If everyone loved Systemd I would be just as worried as if everyone hated it, and that applies to everything.

But as I said before, there is a time and a place for everything. Fight the battles than can be won, and accept the ones that are lost. The odds of actually making a difference, is better that way. Just my 2 cents.
spacex
 
Posts: 637
Joined: 2015-01-17 01:27

Re: From the systemd source code

Postby Randicus » 2015-07-23 11:46

mor wrote:it seems to me you have laid out a set of rules/conditions in which you single out systemd as being "dangerous crap", yet if you set out to apply these rules on other important softwares you find it there too! It seems quite unfair to single out systemd if other basic building blocks mentioned also pass these conditions you set against systemd.
In the interest of playing Devil's advocate, it could be argued that it is appropriate to hold systemd to a higher degree of quality demand, because it integrates and controls everything else. If systemd malfunctions it could be catastrophic to the system, whereas if individual applications, even big ones, fail, the system will still be operational (at minimum with CLI) and the user has a chance of repairing/hacking faults. It could be argued that the importantance of quality control increases with the importance of the software.
Randicus
 
Posts: 2664
Joined: 2011-05-08 09:11

Re: From the systemd source code

Postby somebodyelse » 2015-07-23 11:56

This is why it's important to log bugs in Debian. Let the project have visibility of whatever comes from testing. It's harder to argue against hard numbers.
somebodyelse
 
Posts: 231
Joined: 2015-05-24 17:15

Re: From the systemd source code

Postby somebodyelse » 2015-07-23 12:01

millpond wrote:This is a beast that must be killed in its infancy.


You cannot kill the work that someone else chooses to do. You can only do different work. This is the world of software freedom, not edicts from Redmond.
somebodyelse
 
Posts: 231
Joined: 2015-05-24 17:15

Re: From the systemd source code

Postby Randicus » 2015-07-23 12:29

millpond wrote:This is a beast that must be killed in its infancy.

No. It is a beast that should have been killed in its infancy. It is far too late. It is now a fact of life in Linuxland.
Randicus
 
Posts: 2664
Joined: 2011-05-08 09:11

Re: From the systemd source code

Postby mor » 2015-07-23 12:31

Randicus wrote:In the interest of playing Devil's advocate, it could be argued that it is appropriate to hold systemd to a higher degree of quality demand, because it integrates and controls everything else. If systemd malfunctions it could be catastrophic to the system, whereas if individual applications, even big ones, fail, the system will still be operational (at minimum with CLI) and the user has a chance of repairing/hacking faults. It could be argued that the importantance of quality control increases with the importance of the software.

And this can be an appropriate and satisfying enough answer to the question NkfzGx3ok (not me, those you quoted in your posts are not my words ;) ) asked tomazzi.
When I asked him to reply to that, I didn't understand he was still answering to something that was said before, this is because the flow of the discussion suggested he was answering to the post from NkfzGx3ok right above (I explained this already).

Still, I figured tomazzi may have wanted to give his answer to that question.

Bye
User avatar
mor
 
Posts: 970
Joined: 2010-08-28 15:16
Location: mor@debian

Re: From the systemd source code

Postby Randicus » 2015-07-23 12:36

mor wrote:And this can be an appropriate and satisfying enough answer to the question NkfzGx3ok (not me, those you quoted in your posts are not my words ;) ) asked tomazzi.

I was answering you. Hence why I chose to quote your emphasised statement. And I do not believe tomazzi addressed your concern.
Contrary to popular opinion, there is a method to my madness. :D
Randicus
 
Posts: 2664
Joined: 2011-05-08 09:11

Re: From the systemd source code

Postby mor » 2015-07-23 12:58

I understand, but that way it looks like those where my own words.
Regardless, I appreciate your effort.

Bye
User avatar
mor
 
Posts: 970
Joined: 2010-08-28 15:16
Location: mor@debian

Re: From the systemd source code

Postby Head_on_a_Stick » 2015-07-23 14:21

Randicus wrote:
mor wrote:If systemd malfunctions it could be catastrophic to the system, whereas if individual applications, even big ones, fail, the system will still be operational (at minimum with CLI) and the user has a chance of repairing/hacking faults

Code: Select all
init=/bin/bash

;)
Black Lives Matter

Debian buster-backports ISO image: for new hardware support
User avatar
Head_on_a_Stick
 
Posts: 12612
Joined: 2014-06-01 17:46
Location: /dev/chair

Re: From the systemd source code

Postby edbarx » 2015-07-23 14:33

Head_on_a_Stick wrote:
Randicus wrote:
mor wrote:If systemd malfunctions it could be catastrophic to the system, whereas if individual applications, even big ones, fail, the system will still be operational (at minimum with CLI) and the user has a chance of repairing/hacking faults

Code: Select all
init=/bin/bash

;)

That way, is one way to change the root password without actually knowing the old password.

Run:
Code: Select all
passwd


There is no need to su, as booting Debian in this way, gives automatic root access. Please be also aware that a system booted in this way, does not behave properly as daemons will not be loaded. The same issue happens irrespective of whatever OS-initialiser is installed.
Debian == { > 30, 000 packages }; Debian != systemd
The worst infection of all, is a false sense of security!
It is hard to get away from CLI tools.
User avatar
edbarx
 
Posts: 5401
Joined: 2007-07-18 06:19
Location: 35° 50 N, 14 º 35 E

PreviousNext

Return to General Discussion

Who is online

Users browsing this forum: No registered users and 1 guest

fashionable