Debian systemd maintainer "taking a break"

[Wheelerof4te]

The Linux kernel breaks all the ****ing time, they don't give a crap about b0rkage as long as they can cram their shiny new features in...

Arch Linux has an LTS kernel package for exactly this reason and they advise that is installed in case of upstream problems:

The Linux kernel often breaks kernel-space, it rarely breaks user-space. See https://en.wikipedia.org/wiki/Linux_kernel_interfaces
Kernel space being out of the tree modules, such as ZFS, Broadcom's wl driver, NVIDIA driver etc...
Kernel devs even say that they don't care what happens outside of kernel-space, it's beyond their control anyway. What would have happened if they suddenly started caring? Well, their development would come to a crawl.

Having more than one kernel is advisable in any case, not just with Arch Linux. Every good sysadmin knows that. But here's the thing: you can't have more than one systemd on one system.

One of the main advantages of Debian stable is that it insulates the user against rapid upstream changes.

But in order to get to the next Debian Stable, we have to have some rules or the entire thing will break apart and will need more time fixing. Software development moves fast, and people can't stick with one Debian Stable forever.

[Head_on_a_Stick]

The Linux kernel often breaks kernel-space, it rarely breaks user-space.

Why is it better than the b0rkage is in kernel space? Isn't that much more problematic than user space changes?

And no, "kernel-space" doesn't mean out-of-tree modules (although it does include them).

http://www.linfo.org/kernel_space.html

[golinux]

There are a few recent sysv reports their as well,
with a polite brushoff saying no sysv installed here to look at your issue.
There is a non-official way to handle debian sysv that is similar to LTS but again non-official.

The sysv bugs are being handled collaboratively by Debian, Devuan and upstream because that is the only way to keep it alive in Debian. If init freedom dies in Debian there will be an even greater exodus. Then init freedom in Debian will be forgotten because anyone who remembers will have left the building. Then the coup (as predicted) will be complete. Welcome Winix . . .

[Wheelerof4te]

Why is it better than the b0rkage is in kernel space? Isn't that much more problematic than user space changes?

I didn't say it's better, don't put words in my mouth.

I only said kernel-space breakage happens much more often than user-space because of the nature of out of the tree modules. If companies would upstream those drivers (like AMD is doing now), then the breakage would be less common and easier to fix.
Other kernel-space related breakages happen once in a blue moon. And when it does happen, it's recognized as a bug and a breakage, not a feature to which downstream must adapt.
BTW, in order not to derail this thread, I mentioned Linus and his #1 rule because he is adamant in enforcing it when he is being informed about it. In the case of systemd, we see that it's main developer is not as concerned, until Debian's maintainer decided to quit maintaining systemd. For a while, I hope, not forever.

[Head_on_a_Stick]

I only said kernel-space breakage happens much more often than user-space because of the nature of out of the tree modules.

I don't use out-of-tree modules and stuff still breaks, the ArchWiki recommendation makes no mention of tainted kernels either.

My point here is that the kernel devs do break stuff, I can't comment on the relative frquency of this b0rkage without conducting a formal study though.

when it does happen, it's recognized as a bug and a breakage, not a feature to which downstream must adapt.

Your linked bug report seems to show that the systemd developers are acting in the same way, Lennart & co. have acknowledged the problem and are actually trying to fix this.

In the case of systemd, we see that it's main developer is not as concerned, until Debian's maintainer decided to quit maintaining systemd.

Bullshit.

Lennart's first reply in that thread was an attempt to narrow down the cause of the problem in order to fix it:

https://github.com/systemd/systemd/issu ... -454515587

[Segfault]

I hear this "kernel upgrade broke my system" all the time. Never happened to me, custom kernels. Running 4.20.2 right now. Perhaps these "breaks" have more to do with distro than the kernel itself? After all it is a daunting task to provide a fit-it-all universal kernel and prevent conflicting modules from loading.

Re: Poettering fix. It is hard to believe everything was hunky-dory until now and NIC naming caused this upset. Much more likely it was just the final straw and this maintainer was growing unhappy over long time.

[Wheelerof4te]

^I just made a custom kernel using

Code: Select all

make localmodconfig

Took about 20 mins, no b0rkage here
But I guess I can't make my own custom systemd

[Head_on_a_Stick]

I guess I can't make my own custom systemd

Of course you can:

http://www.linuxfromscratch.org/lfs/vie ... stemd.html

Or use `apt-get source systemd` and modify that instead if you're feeling lazy...

[None1975]

https://lists.freedesktop.org/archives/ ... 41971.html
Debian's systemd maintainer decided he had enough of upstream's BS.

Nice regression. I'll quote one comment:

that's a regression compared to v239, and I'm inclined to add it to the v241 milestone, given that it can mean loss of network access.

[llivv]

I don't use out-of-tree modules and stuff still breaks,

liar

My point here is that the kernel devs do break stuff, I can't comment on the relative frquency of this b0rkage without conducting a formal study though.

feeling lazy lately?

when it does happen, it's recognized as a bug and a breakage, not a feature to which downstream must adapt.

Your linked bug report seems to show that the systemd developers are acting in the same way, Lennart & co. have acknowledged the problem and are actually trying to fix this..

I would hope so! It wouldn't be in anyones best interest if they issued a will not fix for that one.....

In the case of systemd, we see that it's main developer is not as concerned, until Debian's maintainer decided to quit maintaining systemd.

Bullshit.

Humm wonder what's eating pottering these days

Lennart's first reply in that thread was an attempt to narrow down the cause of the problem in order to fix it
https://github.com/systemd/systemd/issu ... -454515587

Yeah yeah we get it already -thanks for the update.....

@ golinux 100% agree - push and shove happens everywhere - business model and all
not much talk about corporate/political war room behavior these days, it's probably against the law to even mention it such secret procedings...

[Head_on_a_Stick]

I don't use out-of-tree modules and stuff still breaks,

liar

If you mean zfs I've wiped that system and I'm clean once more

My point here is that the kernel devs do break stuff, I can't comment on the relative frquency of this b0rkage without conducting a formal study though.

feeling lazy lately?

Always

EDIT:

thanks for the update

You're welcome

[golinux]

Humm wonder what's eating pottering these days

I'm hoping a pending pink slip! LOLOLOL!!!

[Danielsan]

I was going to open the same thread with this title:

The fortress of evil begins to crumble

Anyway it seems we are missing as usual the point, the point is always the same, the attitude of systemd devs towards the others. If you think you have reason for default and all the rest of the world is wrong this is what is going to happen.

By the way I found a very interesting article against systemd, probably the better, and I quote a paragraph that for me is quite significant:

Speaking about systemctl:
This is an "anti-scripting" solution. This solution was created by a person who knows C and nothing but C (some people call such programmer C-heads, distinguishing them from A-heads, who, in addition, know at least one scripting language). For this class of programmers, C is a universal tool that is capable to solve any problems like for a hummer everything is a nail: everything is better written in C and complied into binaries. That's the world he is living in and comfortable with. But from architectural standpoint it is pretty questionable to replace scripting solution with C solution when efficiency is not important. And here, in server space, it is definitely not (rebooting servers is operation performed, say, once a quarter or even with larger interval. Typically this is done for patching. And taking into account the time server BIOS initialization of various cards and services (ILO/DRAC) take, it does not matter if the whole process will last one minute more) . As such this solution is inferior to the use of scripting language and, BTW, you can use more modern language for interpreting custom functional language then shall.

I have been quite neutral about systemd it, I use it everyday I tried to do some stuff and it is easier for an inexpert person like me creating services, but actually it shouldn't me the main target of systemd, however the point is systemd is burying its own hole by itself. The frequency of the security issues is growing up so when fixing it will be cost more human work that creating a new init (or reusing a better one), finally we get rid off of systemd and this will happen very soon.

[Head_on_a_Stick]

The frequency of the security issues is growing up

[citation needed]

[Danielsan]

If you wait by the river long enough, the bodies of your enemies will float by.

[Pick2]

Humm wonder what's eating pottering these days

I'm hoping a pending pink slip! LOLOLOL!!!

Microsoft is going to Fire Him ???

[golinux]

Humm wonder what's eating pottering these days

I'm hoping a pending pink slip! LOLOLOL!!!

Microsoft is going to Fire Him ???

He's working for IBM now since they bought HatRed.

[Funkygoby]

I remember discussing systemd a while ago.
My opinion was that the vote was called too soon for choosing the default init. If it was to take place today we would have more context regarding systemd. Is it technically reliable? How about the community?
I have nothing against systemd but this is not the best init for a system such as Debian. The project just doesn't fit into Debian

[None1975]

The project just doesn't fit into Debian

Well said. +1!

[sjukfan]

Personally I think systemd has the same problem as Gnome these days, things are changing a bit too much, they'd both need a LTS to fit into Debian stable. And I'd be pretty miffed if firefox or something depended on either.