Page 6 of 8

Re: Why systemd is the way forward: technical arguments

Posted: 2014-11-27 11:27
by reinob
dilberts_left_nut wrote:
reinob wrote: But once Jessie becomes Stable I'd expect a consistent documentation of whatever is implemented (or not) in systemd.
Yes indeed.
Did you check for or file bug reports about what you found?
Bugs against documentation need squashing for release, just as much as bugs against applications.
I was waiting for 215-6, which we now have. I think the issues I've mentioned are resolved now -- except for MTUBytes and bonding parameters -- but at least for the latter there was some discussion that this problem only occurs with bond0. If you ignore bond0 and tell systemd to configure bond1 then it works as designed.

Still, I'll look into this, but my time is limited (and posting a bug without details is not that helpful). AFAIK systemd-networkd is still pretty much experimental. It might even be never used/supported in debian -- as ifupdown still works fine and is actually still partially required in combination with wpa_supplicant. systemd-networkd is still very limited and intended for server/container use. That I use it on my laptop just happens to be because I find network-manager, wicd and, to some extent, ifupdown ugly hacks. But this is a topic for another thread :)

Why systemd is the way forward: NON technical arguments

Posted: 2014-11-27 11:48
by edbarx
One's character is a collection of various natural tendencies that affect anyone's life, including work. It is clear that I am not the only person living on Earth, who claims that one's character determines one's attitudes towards work, at least, this should result in some correleration rather than none.

According to some dictionaries, a character is defined as:
edbarx@sid-inst:~$ dict character
6 definitions found

From The Collaborative International Dictionary of English v.0.48 [gcide]:

Character \Char"ac*ter\, n. [L., an instrument for marking,
character, Gr. ?, fr. ? to make sharp, to cut into furrows,
to engrave: cf. F. caract[`e]re.]
[1913 Webster]
1. A distinctive mark; a letter, figure, or symbol.
[1913 Webster]

It were much to be wished that there were throughout
the world but one sort of character for each letter
to express it to the eye. --Holder.
[1913 Webster]

2. Style of writing or printing; handwriting; the peculiar
form of letters used by a particular person or people; as,
an inscription in the Runic character.
[1913 Webster]

You know the character to be your brother's? --Shak.
[1913 Webster]

3. The peculiar quality, or the sum of qualities, by which a
person or a thing is distinguished from others; the stamp
impressed by nature, education, or habit; that which a
person or thing really is; nature; disposition.
[1913 Webster]

The character or that dominion. --Milton.
[1913 Webster]

Know well each Ancient's proper character;
His fable, subject, scope in every page;
Religion, Country, genius of his Age. --Pope.
[1913 Webster]

A man of . . . thoroughly subservient character.
--Motley.
[1913 Webster]

4. Strength of mind; resolution; independence; individuality;
as, he has a great deal of character.
[1913 Webster]

5. Moral quality; the principles and motives that control the
life; as, a man of character; his character saves him from
suspicion.
[1913 Webster]

6. Quality, position, rank, or capacity; quality or conduct
with respect to a certain office or duty; as, in the
miserable character of a slave; in his character as a
magistrate; her character as a daughter.
[1913 Webster]

7. The estimate, individual or general, put upon a person or
thing; reputation; as, a man's character for truth and
veracity; to give one a bad character.
[1913 Webster]

This subterraneous passage is much mended since
Seneca gave so bad a character of it. --Addison.
[1913 Webster]

8. A written statement as to behavior, competency, etc.,
given to a servant. [Colloq.]
[1913 Webster]

9. A unique or extraordinary individuality; a person
characterized by peculiar or notable traits; a person who
illustrates certain phases of character; as, Randolph was
a character; C[ae]sar is a great historical character.
[1913 Webster]

10. One of the persons of a drama or novel.
[1913 Webster]

Note: "It would be well if character and reputation were used
distinctively. In truth, character is what a person is;
reputation is what he is supposed to be. Character is
in himself, reputation is in the minds of others.
Character is injured by temptations, and by wrongdoing;
reputation by slanders, and libels. Character endures
throughout defamation in every form, but perishes when
there is a voluntary transgression; reputation may last
through numerous transgressions, but be destroyed by a
single, and even an unfounded, accusation or
aspersion." --Abbott.
[1913 Webster]

From The Collaborative International Dictionary of English v.0.48 [gcide]:

Character \Char"ac*ter\, v. t. [imp. & p. p. {Charactered}.]
[1913 Webster]
1. To engrave; to inscribe. [R.]
[1913 Webster]

These trees shall be my books.
And in their barks my thoughts I 'll character.
--Shak.
[1913 Webster]

2. To distinguish by particular marks or traits; to describe;
to characterize. [R.] --Mitford.
[1913 Webster]

From WordNet (r) 3.0 (2006) [wn]:

character
n 1: an imaginary person represented in a work of fiction (play
or film or story); "she is the main character in the novel"
[syn: {fictional character}, {fictitious character},
{character}]
2: a characteristic property that defines the apparent
individual nature of something; "each town has a quality all
its own"; "the radical character of our demands" [syn:
{quality}, {character}, {lineament}]
3: the inherent complex of attributes that determines a persons
moral and ethical actions and reactions; "education has for
its object the formation of character"- Herbert Spencer [syn:
{character}, {fiber}, {fibre}]
4: an actor's portrayal of someone in a play; "she played the
part of Desdemona" [syn: {character}, {role}, {theatrical
role}, {part}, {persona}]
5: a person of a specified kind (usually with many
eccentricities); "a real character"; "a strange character";
"a friendly eccentric"; "the capable type"; "a mental case"
[syn: {character}, {eccentric}, {type}, {case}]
6: good repute; "he is a man of character"
7: a formal recommendation by a former employer to a potential
future employer describing the person's qualifications and
dependability; "requests for character references are all too
often answered evasively" [syn: {character}, {reference},
{character reference}]
8: a written symbol that is used to represent speech; "the Greek
alphabet has 24 characters" [syn: {character}, {grapheme},
{graphic symbol}]
9: (genetics) an attribute (structural or functional) that is
determined by a gene or group of genes
v 1: engrave or inscribe characters on
I leave it to the readers whether one's character affects the quality of one's work. It is enough to download systemd's code to immediately realise its high quality. The most striking characteristics are the coding presentation (style) and how different source files are organised.

Since, style and source directory organisation do not affect the final compiled code, it means, Poettering et al, are paying extra attention for these 'unnecessary' characteristics. Therefore, it is more than justified to expect the coding quality to be of the same high standards. Furthermore, Poettering is not some amateur who codes for fun, but was competitively selected to code for Red Hat.

Now, I invite those who reject my claims to have a look at the code to start objectively criticising Poettering et al's work.

Re: Why systemd is the way forward: technical arguments

Posted: 2014-11-27 16:18
by golinux
edbarx . . . you are giving me whiplash . . .

Re: Why systemd is the way forward: technical arguments

Posted: 2014-11-27 18:04
by tomazzi
edbarx wrote:Now, I invite those who reject my claims to have a look at the code to start objectively criticising Poettering et al's work.
It would be easier to just rewrite systemd code rather than quoting hundreds of portions of its code and explaining or discussing what's wrong there...

However, let's try: (v217)

core/main.c.931:

Code: Select all

if (getpid() != 1)
   return -EINVAL;
else
   return 0;
:lol:

... just joking, systemd curently can be run as not PID1, but with very limitted functionality.

Seriously:
core/main.c.222: ()

Code: Select all

static void install_crash_handler(void) {
        struct sigaction sa = {
                .sa_handler = crash,
                .sa_flags = SA_NODEFER,
        };

        sigaction_many(&sa, SIGNALS_CRASH_HANDLER, -1);
}
now:
shared/util.c.2121:

Code: Select all

int sigaction_many(const struct sigaction *sa, ...) {
        va_list ap;
        int r = 0, sig;

        va_start(ap, sa);
        while ((sig = va_arg(ap, int)) > 0)
                if (sigaction(sig, sa, NULL) < 0)
                        r = -errno;
        va_end(ap);

        return r;
}
shared/def.h.40:

Code: Select all

#define SIGNALS_CRASH_HANDLER SIGSEGV,SIGILL,SIGFPE,SIGBUS,SIGQUIT,SIGABRT
Amazing.
Only this one portion of code has at least few serious bugs and exposes bad programming practices:
1. Installing several signal handlers for crash handling without checking return value. (!)
2. Vararg functions are bad practice in general - most known example is the printf() family of functions, which has one huge vulnerability: variable number of arguments can crash the program due to stack overflow. Not only critical function (sigaction_many()) is of vararg type, but also the number of args is hidden behind a preprocesor symbol : SIGNALS_CRASH_HANDLER : bad practice
3. SA_NODEFER allows nesting of signals, and thus nesting of stack frames used by the handler. Since level of nesting is unpredictable, then without special protection and care this flag can cause stack overflow and crash.

It's impossible to list even those flaws and bugs which are visible even without launching the program...

Regards.

Re: Why systemd is the way forward: technical arguments

Posted: 2014-11-27 21:16
by edbarx
To tomazzi:
Notwithstanding your analysis weakens my argument, it is the type of critical analysis that we need here, to discuss systemd in an educated and unbiased manner.

Thanks a lot and well done. I hope, other developers on both sides of the systemd issue follow your example to critically evaluate systemd's code from a coder's perspective.

You have set a good example worthy of imitation.

Re: Why systemd is the way forward: technical arguments

Posted: 2014-11-28 10:59
by mor
Exactly, well said Ed.

Re: Why systemd is the way forward: technical arguments

Posted: 2014-11-28 14:31
by schnuller
You don't think the packager has already checked that ? (let me add: as he should).

iow. I assume it is of sufficient code quality to be distributed by debian.

I mean: just check it. No one can hinder you. But in that case you have lost the trust you should have got. Because there is more than just one package to be found in Debian. And they really should be checked *before* they enter the debian repositories at all (which, like said, i assume has happened).

Re: Why systemd is the way forward: technical arguments

Posted: 2014-11-28 14:46
by schnuller
https://www.debian.org/doc/manuals/deve ... anitycheck
Install the package and make sure the software works
and
https://www.debian.org/doc/manuals/deve ... ner-duties
As a package maintainer, you're supposed to provide high-quality packages
There might well be more to be found, but it seemed like the general spirit to me (while i never cared to search where exactly such is stated).
Or can someone provide something where it is said " As long it is open-source, we don't care. Let's package and distribute it, no matter if it is crap or not. Let the users check what might be wrong with a package" ? It would sound like a very weird approach, at least to me.

Re: Why systemd is the way forward: technical arguments

Posted: 2014-11-28 15:12
by NkfzGx3ok
schnuller wrote:https://www.debian.org/doc/manuals/deve ... anitycheck
Install the package and make sure the software works
and
https://www.debian.org/doc/manuals/deve ... ner-duties
As a package maintainer, you're supposed to provide high-quality packages
There might well be more to be found, but it seemed like the general spirit to me (while i never cared to search where exactly such is stated).
Or can someone provide something where it is said " As long it is open-source, we don't care. Let's package and distribute it, no matter if it is crap or not. Let the users check what might be wrong with a package" ? It would sound like a very weird approach, at least to me.
If you're argument here is that anything with some bad coding practices should be thrown out because it's not high quality (or in your words: crap) then you may as well kiss goodbye to 95% of every piece of FOSS software that exists or ever has.
What would be interesting to see, is for tomazzi to post to the systemd mailing list bringing up his few findings in a polite/sociable/professional manner and see what responses he gets.

Re: Why systemd is the way forward: technical arguments

Posted: 2014-11-28 15:28
by schnuller
I didn't argue that anything should be thrown out,
but that it already is tested sufficiently.

Posting such to systemd mailing lists might be an idea,
but i sure got no idea why i should trust the users of a forum more than debian-devlopers (or maintainers).
you're argument
Say what?

Re: Why systemd is the way forward: technical arguments

Posted: 2014-11-28 16:56
by NkfzGx3ok
Apologies, I think my brain got mixed between asking "If your argument is..." and "if you're arguing that..." - almost 15 years I live in England and I can still make simple mistakes from trying to create sentences :oops:

Re: Why systemd is the way forward: technical arguments

Posted: 2014-11-28 23:04
by tomazzi
I'm staring to feel like I'm wasting my time here...
This is supposed to be a 'techical' thread...
schnuller wrote:You don't think the packager has already checked that ? (let me add: as he should).
iow. I assume it is of sufficient code quality to be distributed by debian.
I mean: just check it. No one can hinder you.
Reading with understanding appears to be a really a hard task for some people... - NO, maintainer is NOT resposible of what code is included...
NkfzGx3ok wrote:If you're argument here is that anything with some bad coding practices should be thrown out because it's not high quality (or in your words: crap) then you may as well kiss goodbye to 95% of every piece of FOSS software that exists or ever has.
Not true at all: 95% of the Free Software is maybe not perfect, but it holds and follows Unix principle of "doing one thing well"

And unless You're going to provide examples or proves, please just dont waste servers' memory. Im criticising systemd in this TECHNICAL thread because I have a reason AND I can prove my claims - If You have something interresting to say on this matter, then feel free to express Yourself....

No offense. Regards.

Re: Why systemd is the way forward: technical arguments

Posted: 2014-11-29 00:08
by schnuller
tomazzi wrote:I'm staring to feel like I'm wasting my time here...
This is supposed to be a 'techical' thread...
schnuller wrote:You don't think the packager has already checked that ? (let me add: as he should).
iow. I assume it is of sufficient code quality to be distributed by debian.
I mean: just check it. No one can hinder you.
Reading with understanding appears to be a really a hard task for some people... - NO, maintainer is NOT resposible of what code is included...
.
If you say "Reading", then it must be written somewhere.
Where?

Of course the maintainer is supposed to know the software he packages and make sure it doesn't do harm.

Re: Why systemd is the way forward: technical arguments

Posted: 2014-11-29 01:35
by Bulkley
One thing I notice on my Jessie desktop is that it is managing CPU usage better than Wheezy did. This is an older machine (Athlon processor). Wheezy kept CPU usage close to max most of the time. With Jessie, it is rarely over half. I can only assume that systemd is responsible.

Re: Why systemd is the way forward: technical arguments

Posted: 2014-11-29 02:17
by schnuller
Bulkley wrote: I can only assume that systemd is responsible.
You could also assume it has something to do with a newer (different) kernel. Or both. Or something different.
But, truth to be told, as long it works i don't care much why (or works better, in this case). You could install sysv, use that, and check it, in case you are different than i am.

For what it's worth: My CPU usage is less than 10% (with openrc. But as long i don't run VirtualBox it seemed to always be like that, hence with sysv and systemd too). model name : Intel(R) Pentium(R) CPU P6100 @ 2.00GHz

Re: Why systemd is the way forward: technical arguments

Posted: 2014-11-29 19:58
by twoflowers
CPU usage: wheezy takes ~ 5%. squeeze was ~ 3%. FreeBSD is about 3%. Statistics almost the same on all my computers, even ARM.

Re: Why systemd is the way forward: technical arguments

Posted: 2014-12-15 01:38
by drokmed
confuseling wrote:This is worth a read:

https://wiki.debian.org/Debate/initsystem/systemd
I just read that link... holy crap!!! Sounds like way much more than just an "init system replacement". Why does an init system need to take over the keyboard, console, user logins, and other operations AFTER the system is up and running? Where does it end?

Having been away, i'm just now coming up to speed on all this systemd controversy. It looks to me if you give systemd an inch, and it will take every last mile, and anything else after that.

If they just kept it as an init replacement, I could see that. But to keep growing like the blob, consuming all future functionality, that's not cool.

Re: Why systemd is the way forward: technical arguments

Posted: 2014-12-15 02:30
by golinux
+1, drokmed. You have seen the light!

Re: Why systemd is the way forward: technical arguments

Posted: 2014-12-15 08:09
by twoflowers
LOL ... I've seen the light and it was pitch dark :-)

Re: Why systemd is the way forward: technical arguments

Posted: 2014-12-15 12:47
by tomazzi
drokmed wrote:
confuseling wrote:This is worth a read:

https://wiki.debian.org/Debate/initsystem/systemd
I just read that link... holy crap!!! Sounds like way much more than just an "init system replacement". Why does an init system need to take over the keyboard, console, user logins, and other operations AFTER the system is up and running? Where does it end?

Having been away, i'm just now coming up to speed on all this systemd controversy. It looks to me if you give systemd an inch, and it will take every last mile, and anything else after that.

If they just kept it as an init replacement, I could see that. But to keep growing like the blob, consuming all future functionality, that's not cool.
This wiki has been written as if systemd was a stable software, while if fact it's not.
And definitely it was even less stable at the time when the text was written.

As a result, and unfortunately, the wiki contains mostly misleading informations, half-truths, if not just lies.
For example:
Sysvinit/insserv has very little C code, but the real code size must take shell scripts into account. These scripts come in huge numbers, contain bugs and are hard to maintain.

The above suggests, that on the contrary, systemd has a lot of C code (what happened to be true) and is easy to debug (to find where the problem is...)
I can't imagine what kind of an idiot have written this. For sure, he heve never even readed the systemd code, not to mention trying to debug it.
And systemd has tons of bugs, which are not a result of the current alpha development stage - those bugs are effect of bad design, bad coding practices and ignorance.

Even the first listed feature of systemd is simply a lie:
Systemd uses control groups to ensure that any service, regardless of its state, can be shut down properly.
It is obvious, that services which are dealing with databases or filesystems in general cannot be "shut down properly, regardless of its state"
But, this is only tip of the iceberg, problem with this kind of aproach is far more deeply rooted:
Those idiots are running sync() calls in several threads, to make in parallel - but unfortunately storage devices are "serial", calling sync() in parallel is simply stupid and pointless.
Things are even worse: those idiots are running sync() in detached threads - what means, that they are not waiting untill sync() is finished and are turning the power off. It is very likely that systemd can corrupt file system in this way.
This may not be visible on desktops, where usually filesystem is in sync long before the user will shut down the system, but on servers this stupidity may have serious concequences.

Regards.