Lennart Poettering On The Open-Source Community: A Sick Place To Be In

[leiptrstormr]

Nobody talks about Lennart this way and gets away with it. I have put a hit out on your life XD

Wow I know you guys really like Lennart, but this has gone too far.

[nanonyme]

Wow I know you guys really like Lennart, but this has gone too far.

I'm starting to suspect this conversation is mainly run by one person with multiple nicks arguing with himself. Maybe Michael considers this a good FOSS conversation, who knows. At least it brings views

[Naib]

It's old news. Lennart has always been this way - his attitude may have marginally worsened over the years but only marginally. And I really dislike how it's all suddenly much more about him being an arrogant prick and much less about his projects being total crap polluting the ecosystem and undermining the very foundations of FOSS in Linux userland.

its a very convenient digression. Its like in politics... leak a bit of smear so the papers of politicians spend time arguing over who groped whom while the white elephant in the room which is the economy is getting worse...

[interested]

And at the same time, it is the biggest problem. You forego the possibility to use different components to do the job.

I mean, seriously, NTP support as part of the init system?!

Like what? The only core components in systemd is the init/process controller (systemd), udev, and journald. And yes, even those can be removed too, which is explained in the docs. The sNTP client isn't part of the init system, something you would have known if you have read the documentation, but is an optional super lightweight daemon added especially for supporting OS containers (look it up, it is really cool tech),

Same with the dhcp client; it is ultra lightweight and extremely fast, something that is important when you boot up many OS containers or computing nodes in parallel. The have all been added on request from systemd end users who made a user case for their inclusion.

If you want to use another sNTP or dhcp client it isn't a problem at all. Do you want old legacy style text logs, just use rsyslog as always, and journald will act as a syslog helper client. Insisting on starting your daemons with a SysVinit script? No problem either for systemd.

AFAIK, there are no serious maintained alternatives to udev or logind on Linux, except two code forks. There just seem to be almost zero interest in developing any alternative code to systemd's.

[Guest]

That wasn't LP, it was Kay Sievers.

My bad, I stand corrected. These guys are raising airbrows lately.

[asdfblah]

Yes, you missed the kickstarter-style web page which tracked funding progress etc. I remember it but can't find it anymore.

Well, try to remember it and show it to us. Otherwise, it will still be a random IRC joke overblown by aspergers sufferers.

A joke? Well there was no one laughing at it as far as I can see. I'd rather call it a felony. That's at least what it is in the civilized country I live in.

Health or death threats need to be always dealt with, with full force, this is not "fun" or "jokes", regardless of what anyone thinks. Though if someone says to your face that he is going to hurt you, there is a very high probability that he can't do that and is saying stuff out of spite (because if he could he'd just do it), but it never hurts to be careful and prepared for attack (and strike back when needed).

Of course instead of condoning lowly and unacceptable not to forget criminal behavior, we invent some conspiracy theory to blame the victim!? What you call "humorous", is called a felony where I live. There was no grin, no chuckle, no smiley, no "but seriously". There was just talk about hiring a hitman, cutting Lennart's hands off and having Lennart hit by a bus. That's no joke and nothing anyone has to put up with.

You are far crazier than the guys quoted in the text, if you really believe that (IRC) jokes must be punishable and punished. You are not better than those who back US wars against random, distant nations in defense of corporate interests.
Yes, I know there ARE crazy, obsessed people in the Linux community. But there are crazy people everywhere, and, you know, this is the www, you can't see who's behind the keyboard. If you don't take that as a given... well, you have learned something new about human societies, I guess.

It's right there: "[...]There have certainly been some problems [...]". How did you miss it?

My mistake. How terrible.

No, that's not right. And just repeating it will never make it right. udev does not depend on systemd in any way. udev source code is managed in the systemd source repository and it is built by the same build system as systemd. If you think this makes udev dependend on systemd in any way, please learn the first thing about software development before commenting any further on this.

This has been discussed many times, I guess you should ask distro maintainers about it... or ask Poettering himself.

So please explain to my how I can reliably stop a service without systemd. And I mean reliably, with all spawned child processes. And that means _all_. So I can be sure, that none whatsoever are left.
Yes, you could do it before: by rebooting the system. That I can do it now without having to reboot is a _new_ feature that alone is worth spending 10 minutes to learn systemd usage.

How does this relates to systemd itself? It does not, it's a completely different feature, from the kernel. And how come you don't know about killall or upstart (or any other init system, for that matter)? Is it you that is telling me to "learn the first thing about software development before commenting any further on this"? How new are you to linux, and do you understand how things are done in kernel land?

Two words: Eternal September

THIS, absolutely this. I blame Arch (and, in the past, slackware, or any distro for elitist 1337 h4x0r5).

[niner]

How does this relates to systemd itself? It does not, it's a completely different feature, from the kernel. And how come you don't know about killall or upstart (or any other init system, for that matter)? Is it you that is telling me to "learn the first thing about software development before commenting any further on this"? How new are you to linux, and do you understand how things are done in kernel land?

Wrong. killall cannot reliably kill a daemon. What do you do if the main process of a daemon is called httpd and it frequently spans processes called fcgid or perl or rsync or whatever? And what if those processes detach completely from the main process? Do you want to killall perl and just hope that between the time killall is looking through the process list and the main process getting the kill signal it doesn't spawn a new process? Remember, I was asking about _reliably_ killing a daemon. That's not reliable. That's failing workarounds for SysV init's lack of features. And yes, this created real problems on real drbd based clusters. Neither killall, nor upstart nor any other init system except for systemd-init can do this reliably.

[pininety]

Wrong. killall cannot reliably kill a daemon. What do you do if the main process of a daemon is called httpd and it frequently spans processes called fcgid or perl or rsync or whatever? And what if those processes detach completely from the main process? Do you want to killall perl and just hope that between the time killall is looking through the process list and the main process getting the kill signal it doesn't spawn a new process? Remember, I was asking about _reliably_ killing a daemon. That's not reliable. That's failing workarounds for SysV init's lack of features. And yes, this created real problems on real drbd based clusters. Neither killall, nor upstart nor any other init system except for systemd-init can do this reliably.

Funny, I was just about to right exactly this ^^
So +1

[Naib]

Wrong. killall cannot reliably kill a daemon. What do you do if the main process of a daemon is called httpd and it frequently spans processes called fcgid or perl or rsync or whatever? And what if those processes detach completely from the main process? Do you want to killall perl and just hope that between the time killall is looking through the process list and the main process getting the kill signal it doesn't spawn a new process? Remember, I was asking about _reliably_ killing a daemon. That's not reliable. That's failing workarounds for SysV init's lack of features. And yes, this created real problems on real drbd based clusters. Neither killall, nor upstart nor any other init system except for systemd-init can do this reliably.

*cough* OpenRC & cgroup segregation of daemons and cgroup cleanup...

[brosis]

No it hasn't and that's all bullshit.

You get 20 people in a room with 20 different opinions and nothing gets done.

20 different opinions and expertizes should implode into one result, not explode.