Linux Kernel Developers Fed Up With Ridiculous Bugs In Systemd

[droste]

I typed the three letters on my own...

And I'm not going to argue about this with you. There's is absolutely nothing I can say to change your mind and I don't want to. You don't like Lennart and systemd, fine.
I was just replying to curaga who stated that there are way more flamewars regarding systemd than upstart. Which is correct by my observation and it's also my observation that many attacks are against Lennart and not systemd. So it doesn't matter what he does, it will cause flamewars.

[gens]

I typed the three letters on my own...

And I'm not going to argue about this with you. There's is absolutely nothing I can say to change your mind and I don't want to. You don't like Lennart and systemd, fine.
I was just replying to curaga who stated that there are way more flamewars regarding systemd than upstart. Which is correct by my observation and it's also my observation that many attacks are against Lennart and not systemd. So it doesn't matter what he does, it will cause flamewars.

thank you for the civil response, it's refreshing
i thought it was a reply to me as mine was the last post
so my bad for confusion i guess

yes, it would be hard to change my opinion as it is about design (over engineering that is, a common problem)

also yes
another common problem
unfortunately critical thinking is not the strong side of the general public
generalization is no solution unfortunately (as it is double edged)

since i am pretending to be smart here, id like to point out that none of us know Lennart good enough to claim what we say
it could be just that sudden fame hit hes head for 15min and it got recorded (i seen him being "human" a couple times)
(i'l still keep my opinion as he once publicly interrupted a competent person that was explaining some obvious shortcomings(unrelated to systemd); hard to forget that for me)

[b15hop]

SystemD to me has always been a rocky boat. When it does work, it's lightning fast though. So they must be doing something right...

[Luke]

The fastest boats are often rocky

SystemD to me has always been a rocky boat. When it does work, it's lightning fast though. So they must be doing something right...

Perhaps systemd, especially when used with Dracut, is like those Polynesian outrigger canoes that were used to travel the entire Pacific. These were fast multihulls that were vulnerable to storms but could often outrun them. By comparison, SysVinit would be a round-bowed, deep hulled ship that always gets there no matter what the weather but takes nearly a month to cross the Atlantic. Maybe when Systemd matures it will be like a clipper ship, with the best attributes of each.

[b15hop]

Perhaps systemd, especially when used with Dracut, is like those Polynesian outrigger canoes that were used to travel the entire Pacific. These were fast multihulls that were vulnerable to storms but could often outrun them. By comparison, SysVinit would be a round-bowed, deep hulled ship that always gets there no matter what the weather but takes nearly a month to cross the Atlantic. Maybe when Systemd matures it will be like a clipper ship, with the best attributes of each.

A man of my own heart.

Off topic - I guess if this were like a space ship, we would all choose the reliable ship vs the one with the most cool features or fastest ETA time.

Otherwise on topic .. If SystemD is still this bad then maybe it should still be considered experimental.

[Nobu]

You can't expect software to work well when you abuse its features. This goes for systemd and the Linux kernel, and any software, honestly.

[doom_Oo7]

A man of my own heart.

Off topic - I guess if this were like a space ship, we would all choose the reliable ship vs the one with the most cool features or fastest ETA time.

Otherwise on topic .. If SystemD is still this bad then maybe it should still be considered experimental.

Why don't you just try it for yourself and make your own opinion? A VM is cheap....

[doom_Oo7]

You can't expect software to work well when you abuse its features. This goes for systemd and the Linux kernel, and any software, honestly.

This is blatant bullshit. If it's modular you can just have good tests and good continuous integration for everything you do... (Of course making them requires a good spec and time, lots of)

[Nobu]

So you're saying that using a feature for other than it's intended purpose is fine and you should be able to expect it to work, even when the tests that were written for it (if any) were written with the expectation that it would be used for something else?

I'm with you as far as testing your code to make sure it works the way it's intended, but you can't expect everyone to be able to read into the future and predict every way a particular function will be misused and abused.

Anyway, in this case it was more a case of two pieces of software using the same keyword to perform some function, not so much one piece of software abusing another's feature. I misspoke there.

[doom_Oo7]

So you're saying that using a feature for other than it's intended purpose is fine

I don't really see how a well-coded C function can be used for something other than it's purpose...
For instance, I just took a random function in one of the latest commits : http://cgit.freedesktop.org/systemd/...rtnl-message.c

Let's have a look at

message_new

. I'm not expert coder (and I really prefer the static correctness you can get from C++), but from what I can see :

• Every function call's return is checked
• There are asserts for case where it may go wrong

So there certainly might be corner case bugs or missing asserts, but to me the code seems good and the functions seems to have well defined invariants. I just find the documentation lacking however (but I looked on other files and it seems they prefer to document everything on the wiki : http://www.freedesktop.org/wiki/Soft...journal-files/ is referred in journal-*.h for instance)...

There are also good tests : http://cgit.freedesktop.org/systemd/...nl/test-rtnl.c
And I suppose it's the case for other modules.