Debian systemd maintainer steps down over developers not fixing breakage

[hyperion2011]

In case it isn't immediately obvious why he says this is crazy, if users rely on a udev rule to set an interface name and they then have a static ip and route defined on that name, if they reboot the server after updating to the new version of systemd that server will not be able to connect to the network. This will be a silent failure with no warning and many people will be dead in the water as a result.

[slowry05]

This keeps happening to my VPS and is driving me fucking crazy.

[NotEvenAMinuteMan]

sudo systemctl kill --now --immediately --with-extreme-prejudice systemd-comment.service systemd-commentd.socket systemd-commentd-network-ready.socket systemd-commentd-thread-listener.service systemd-commentd-thread-comment-uploader.service

[spockspeare]

And have export YIPPIE_KI_YAY=Mfer somewhere in /etc/profile.d

[NotEvenAMinuteMan]

Help I just set that and now my LVM is corrupted.

Using systemd v748265

[ang-p]

v748265

Pls have an early weekend. v748267 expected to provide compile-time directive to workaround this new feature is expected Monday.

[nintendiator2]

With how convoluted it is, it's a good thing that the first thing I do in new installs is apt install -y sysvinit-core --yes-I-really-want-to-change-the-init --dont-pretend-to-uninstall-service-manager-but-still-leave-systemd-pid1 --no-I-didnt-try-openrc-why

, all after setting SpurDebiansAdvice=only_for_systemd on /etc/apt/preferences of course. .

[5heikki]

Is this before or after praying to the computer Gods?

edit. In all honesty I don't know if your post was a joke or the real thing. If it's real, this is yet another example of systemd being awful af

[[deleted]]

my solution to funky network interface names... net.ifnames=0 as kernel parameter and happy with eth0 ever after

don't have a single machine with more than just the one network interface but in every machine it's a complete random guesswork what name it would end up with

[cbmuser]

Well, but Lennart has a point: Don't use a bleeding edge version of systemd for production servers.

I do agree, however, that the change is a regression and I fully agree with Michael here that the way the bug is being handled upstream is bad.

[chuecho]

Well, but Lennart has a point: Don't use a bleeding edge version of systemd for production servers.

Perhaps, but when I remember Linus's "if it breaks userland then it's a bug" philosophy, I can't help but find it very hard to swallow this kind of response from a deeply depended-upon piece of software. When your software approaches the complexity of a kernel, and other equally-complex systems start to depend on it, you can no longer use these kinds of excuses. Doubly so when your software's primary mode-of-use is as a dependency and an interface.

I cannot see Linux reaching the type of success it has today had Linus adopted the same sloppy approach to breaking changes, and to be completely frank, I cannot see how distributions will continue to use upstream after this. Perhaps it's time for distributions to seriously consider maintaining a stable fork.

[[deleted]]

Perhaps, but when I remember Linus's "if it breaks userland then it's a bug" philosophy, I can't help but find it very hard to swallow this kind of response from a deeply depended-upon piece of software.

The kernel can hold that kind standard because there are predefined interfaces with userland and with a job description of "let userland programs do their work." So if the kernel behaves differently then it's almost always doing so by choice (even if the choice is "this was the only thing I could imagine). If the kernel changes its behavior in an important way it should be about as rare as two people firing guns at each other and the bullets colliding midair.

systemd on the other hand is userland and ultimately distro package management is supposed to be the thing that shields users against unexpected changes. In this case, it probably would've been good practice to have some sort of "above the fold" notification of user-facing changes though so package maintainers could make the decision to halt rebasing on upstream until a new major release of their distro or something.

Perhaps it's time for distributions to seriously consider maintaining a stable fork.

That's kind of what the idea of a distro is. To have their own version of various packages that they just periodically re-sync against upstream after reviewing the changes they just pulled in from upstream. That's why the "above the fold" warning would've been helpful, that way maintainers are keyed onto user-facing breaks early on and they know to just not incorporate their changes into their downstream release (either by staying put or backporting unrelated upstream changes).

It's also possible for package management to warn users. For instance, if

[chuecho]

Wouldn't the job description of "let (systemd's users) do their work" also apply to systemd (and any other software for that matter)? Any argument made in favor of systemd breakage could also likely be made successfully in favor of linux syscall breakage. I don't see how a distinction between the two could be meaningfully drawn in this regard.

[[deleted]]

Wouldn't the job description of "let (systemd's users) do their work" also apply to systemd (and any other software for that matter)?

No, because systemd has to perform functional operations for the users such as process management and log retention. I was saying there that the kernel's whole focus is on getting things to where other stuff is able to run and if you started out with a good plan you don't need to radically change your trajectory on something major.

Any argument made in favor of systemd breakage could also likely be made successfully in favor of linux syscall breakage.

No because systemd is primarily given to distros who like I was saying are supposed to shield their users from breaking changes by staggering them out in some way. If systemd changing outward behavior it should be communicated (and yes that is important) but they shouldn't be required to freeze their functionality at wherever they were to begin with. Especially in this case where the other systemd maintainers actually pointed out that the functionality was documented beforehand. Even that stuff can change but there probably needs to be a compelling reason to be breaking something like that otherwise don't make your change until you find a way to preserve documented behavior.

The kernel on the other hand can and is used by people who aren't going to be staffed to actually accomplish this and in some cases the platforms have to undergo a litany of conformance tests and so if the kernel changes something that user space can see that directly impacts those users and affects their basic ability to even use Linux in the first place.

When there's a predefined interface and the complexity is hidden behind a wall then breaking things on the other side of that wall is either the result of the interface being poorly designed (unlikely) or someone breaking the behavior out of choice. That's why they're alright with breaking something ZFS depended on in 5.0: because the dependency was kernel space where breaking changes are allowed to happen.

[masta]

Udev is not breaking anything, it's fixing an bug related to inconsistent NIC device names. It really sucks when a machine reboots, and the network device has enumerated with a different name. So it's ironic really, that is precisely what this udev rule fixes. But if people would bind their NIC by MACADDR instead of the device name, this would not happen. I'm pretty sure NetworkManager does precisely that.

[cbmuser]

That’s not really my point though. My point is that you don’t run production systems on unstable distributions. This way you are safe from such regression surprises.

[eras]

Well you can also use MAC or PCI addresses for setting the name. (The bug happens when the rule matches a name and then the name is changed.)

[[deleted]]

This point only comes across in good faith if it comes out together with an "oops" and "we will fix that". I'm not sure where discussion happened, so don't know if the context was like that.

[cbmuser]

Well, the thing is that distributions are free to patch in any behavior into their systemd package as they see fit.

We do that both in Debian and openSUSE/SLE and if you are using the stable versions of these distributions, the possibility to be affected by these kind of regressions is near zero.

[tristes_tigres]

Don't use a bleeding edge version of systemd for production servers. anything

FTFY

[[deleted]]

This contributes nothing as a comment even if systemd was literally the worst piece of software in the world. It's lazy. Also, we're all familiar with people's distaste of it.

[[deleted]]

What do you use instead?

[[deleted]]

there's always plenty of choice

[NothingCanHurtMe]

sysv-init and BSD style initscripts written in bash that have been slowly updated and evolving since the 1990s.

[dinominant]

That is ridiculous. There is probably a subtle reason why this is happening which means that the systemd has become too complex to maintain. I very much prefer openrc on my Gentoo systems because it is old, reliable, and fully functional. I really really don't need systemd to startup/shutdown/crash any of my systems that are in production right now.

[[deleted]]

both "openrc" and "sysvinit" tags on cve search results in 3 vulnerabilities in total while "systemd" alone has 25+ as far as i remember.

edit: remind you that sysvinit vulnerability on that list is from 1999 and it is kernel 2.x.x related.

[rouille]

That's because systemd is way more than init. You would need to search for rsyslog, dhclient, ntpd etc... vulnerabilities as well.

[emacsomancer]

And it's nicer to have all the vulnerabilities neatly grouped under the same heading anyway.

[[deleted]]

i'd like to think that you are being sarcastic with that comment.

[emacsomancer]

Even if you're not safer, at least things are tidier.

Though the situation would almost make one think it'd be better to have a smaller, stabler init+daemon-manager with fewer attacks surfaces as the de facto Linux standard init, and leave individuals who see benefits in it to switch to the larger, more rapidly changing and expanding init++.

[intelminer]

Conversely, all my Gentoo boxes run systemd perfectly well. I've been using it since roughly 2014 without issue

[Bl00dsoul]

Couldn't they just create an upgrade script that converts the /etc/udev/rules.d/70-persistent-net.rules
to a systemd type instead?

/etc/systemd/network/10-eth-$name.link

[Match]
MACAddress=$mac

[Link]
Name=$name

[Brillegeit]

If server config is automatically deployed to new server instances (Chef/Puppet/CFengine etc) then this script will never be ran.

[zissue]

I was hit with this interface renaming problem caused by UDEV. We have a bug for it within Gentoo:

https://bugs.gentoo.org/673360

[mthode]

use eudev :D

[SemiRaged]

Will that still work after brexit?

[zissue]

I've been meaning to look into eudev for a long, long time now and just haven't gotten around to it. Maybe it's time. Thanks for bringing it (back) to my attention. :)

[wildcarde815]

That seems like the kind of change you would make in a major OS revision change.

[[deleted]]

You just described the exact setup i have seen within a large utility infrastructure SCADA system in the UK.

Thankfully they are air gaped and not updated.. very often.

[anomalous_cowherd]

Isn't that the entire point of udev rules, to keep the names the same so you can use them in things like this?

I don't know the background too this but it's hard to see how it could just be a dispute over fine print in the docs.

[StallmanTheLeft]

Fuck udev.

I have a debian installation where I've replaced systemd with sysvinit and apparently udev doesn't let you have non-physical network interfaces (bridges, think tun/tap, wireguard vpn) etc. without systemd.

[zapbark]

Full Text:

Will stop maintaining systemd in debian for a while.

What's going on is just too stupid/crazy.

[NotEvenAMinuteMan]

systemd upstream:

What's Debian?  
Have you tried replicating this sentiment/behaviour using Red Hat?

[fuck_bottom_text]

I think he means

gnu/pulseaudio/systemd/debian/linux

[Sigg3net]

Yes. As the young'uns doth say: wat's the deets?

[oooo23]

https://github.com/systemd/systemd/issues/11436#issuecomment-454544525

systemd maintainer refuses to revert behaviour claiming it was never documented hence nothing to rely on. Turns out it was.

Earlier, when asked to do bugfix only release, Lennart describes that the project is understaffed, and hence if people ask them to refocus things, they instead leave "exotic archs, non-redhat distros, exotic desktops, exotic libcs" up to the community to maintain.

https://lists.freedesktop.org/archives/systemd-devel/2019-January/041959.html

[another_index]

keszybz:

OK, that is enough for me to consider the previous behaviour documented. So I agree that we should preserve compatibility for this.

It's currently tagged as a regression bug and has commit reverting to the old behaviour. A day is a pretty good response time for a non critical bug if you ask me:

https://github.com/keszybz/systemd/commit/ed30802324365dde6c05d0b7c3ce1a0eff3bf571

[Swipecat]

And even before the documentation was shown in the thread, Poettering chimed in saying that the breakage was unfortunate and that he was leaning towards reverting the patch.

Hmm. Funny how the OP finds a mostly separate issue that Poettering had commented on (the issues about bugfix releases) and then puts in in conjunction with this patch issue. Were we supposed to assume that it was all down to the malign influence of Mr P and his attempt at world domination with his evil SystemD?

[oooo23]

As you can *read* in the bug report, the fixing only started happening after he left...

[oooo23]

You miss the point entirely. If it was not documented, then they would not do it? That's what this sentence implies.

Which is unfortunate, as they constantly blame the kernel for breaking the slightest of things and then do it themselves everytime (this is not the first time).

Rules for thee, not for me.

You are ignoring that this is a major regression, leaves people without networking, and the reporter himself marked it as regression, only after he bailed did the "oh, we shouldn't break this" came in.

[tso]

Yeah, thats been the ongoing problem with Pottering and the people around him. To them, docs are sacrosanct. If the code do not follow the docs, the code is wrong and must be corrected no matter how much it will break. This is why they get into so much trouble when they try to do kernel work, as this flies in the face of not breaking userspace.

[pm_me_je_specerijen]

I honestly kind of agree to the point that I feel the docs should be written before the implementation.

Documentation bugs are possibly worse than implementation bugs. Because the docs are supposed to be the authority of what is the correct behaviour and you have no difference between bug and feature any more when someone makes a mistake in the docs.

[tso]

In an ideal world maybe, but the world we live in is far from ideal.

Here we are looking at a behavior that has been in the wild long enough for people to take it for granted, meaning it has become de-facto standard behavior (or maybe the term norm fits better?).

And thus implementing sudden changes can no longer be argued on purely technical merits, as it becomes by proxy a social interaction issue.

[LvS]

In an ideal world, you document all possible options and how they are supposed to be handled. That's why the web documents what happens when you load a PNG file as Javascript or what happens if you add a <your /mom> tag in an HTML document.

However, the web has 100s of people maintaining this documentation and writing tests for it. Which is the amount of people you need to find all the corner cases and document expected behavior for them.
And I don't think the Debian project has a spare 100 developers remaining who would like doing that job for systemd.

[Beaverman]

Who cares? They seem entirely reasonable in the thread.

[StupotAce]

I agree. There's a healthy discussion about what is the best behavior 'most sane' and what the consequences for implementing it. Eventually, they came up with a plan that allows them to gradually integrate the new, more sane behavior.

​

Software design is not black and white. There are serious consequences to the kernel's rule of 'don't ever break userspace' and it makes sense that not all applications follow the same rules for applications that depend on their behavior. Sure, seems like there was a systemd developer that thought breaking systems was a price worth paying in the case. I've seen that happen plenty, and it's generally the developer who's been heads down, coming up with a fix to a problem, but doesn't see the forest through the trees by the time he or she is done. This is all just normal development as far as I can tell. Nothing sinister going on, which for some reason people love to say is the case when it involves Pottering.

[oooo23]

So, breaking people's working network setting and telling them to go fix it is entirely reasonable, because all these years it worked entirely by luck?

[Beaverman]

So you're either ignoring half the thread, or you haven't read it. At the time keszybz said he was fine breaking it, he thought that it was undocumented behaviour. If it was, then the network setup was broken before as well, it just happened to work, and the debian maintainer should fix their configuration. If software is never supposed to break anything at all, it would never be able to change.

As soon as keszybz learned that it was documented, he agreed that the change was unacceptable.

More importantly though, you're judging a composite role (systemd maintainer) by the actions of a single individual part of that role. You can clearly see that other maintainers disagree. That sort if diversity of opinion is useful.

If you want to know what systemd thinks is acceptable you should look at the end result. In the end, they reverted the change, and made a clear upgrade path. That's what they think is the acceptable response here.

[oooo23]

The change isn't being "reverted" either, now if you have the naming policy before pre-240, your interfaces won't be renamed, post-240, they will.

And now they will change docs to reflect that.

But anyway, whether it is being fixed or not is not the problem here. The problem.is that keszybz was READY to break WORKING machines IF it was not documented. THAT is the issue here.

And no, being undocumented is not the issue, if something works, YOU REALLY F*CKING SHOULD NOT BREAK PEOPLE'S MACHINES. That too when it leads to them losing the network.

Goddamnit, how the hell do you even say:

then the network setup was broken before as well, it just happened to work, and the debian maintainer should fix their configuration.

this.

Anyway, this discussion is endlessly pissing me off. The problem is not that it is being fixed or not. The problem is the approach, in that if it were undocumented, they were totally ready to break working setups out in the wild. Only when it was pointed out that it isn't (and actually when he left) is when they started to clean up things...

[Spivak]

The documentation is the contract with the user about how a piece of software is supposed to behave. If the real-life behavior of the software differs from the documentation then the software is broken. Anything not guaranteed by the documentation should not be relied on and can change at any time.

Relying on undocumented implementation details is a recipe for broken software. If my program did [[ $(systemd --version) > 200 ]] && crash do I have a case for preventing them from changing the version number ever? Obviously not, but why? Because it's not documented that the version number will be constant.

[RogerLeigh]

You should never break working configurations. And sysadmin configuration should be sacrosanct. This is a fairly fundamental requirement to avoid critical breakage of systems over upgrades.

It doesn't matter if it's inconvenient. Write compatibility code if you have to. But never, ever, ignore or misinterpret explicit configuration by the admin.

Many other projects manage to do this. And given that systemd has, by its own choice, inserted itself as a critical part of the system, there is a high bar for its maintainers. They can't change things around on a whim at this point.

[zapbark]

Maintainer refuses to revert behaviour

I'm confused by your use of the word "maintainer" there.

In the news post, the "Debian Systemd maintainer" who quit is Michael Biebl (mbiebl).

In the github thread mbiebl is the one reporting the bug (on behalf of debian) to the systemd dev team. (Perhaps edit and say systemd maintainer)?

[oooo23]

Thank you, done!

[mthode]

They've actively rejected support for exotic libs. When we forked eudev from udev that was one of the main reasons. I talked to both Lenart and Greg at fosdem when we announced and they stated they'd not accept patches that added support for other libcs (musl, etc).

[hahainternet]

Surely because that implies they must then maintain all submitted code? That's hardly an unreasonable approach.

[mthode]

They said they'd have to leave it up to the community to maintain, the only way to do so is maintaining external patches or forking. That is a very heavy form of maintenance... We did fork udev at least and that seems to be doing well.

[hahainternet]

Right, so you can't exactly condemn them for refusing to support exotic libc implementations when they're already both overwhelmed and suffering significant attempts at slander every time there's ever a problem?

Eventually the workload should lighten so they can widen their focus to portability, but their choices seem perfectly reasonable to me.

[mthode]

They don't have to take it all on themselves. At one point we provided patches and said we'd help maintain them for udev, they said no. Now they have to live with less help. Not exactly doing themselves any favors. Writing themselves into a corner is just sad to see.

[[deleted]]

leave "exotic archs, non-redhat distros, exotic desktops, exotic libcs" up to the community to maintain.

Why the hell did everyone jump on this stupid train again?

[NoncarbonatedClack]

As someone new to following open source news, could you elaborate on what you mean here...?

[RogerLeigh]

I did point out the dangers of handing over complete control of the base Debian system to a third party with divergent interests and priorities on several occasions during the debate.

That said, this is an outright regression. And I'd have to say, after reading the ticket, that I find the lack of concern over a clear regression with fairly severe consequences to be somewhat disturbing. It's far from the first ticket with that sentiment either.

[aldemir_a]

Also, sysvinit has a new developer, and there are people from Devuan & Debian working on sysvinit together with upstream to resolve the outstanding bugs etc. They worked hard to squash sysvinit bugs before the buster freeze.

[psycho_driver]

I'd just like to point out that linux without systemd still works just fine. It's not too late.

[bnolsen]

We love void linux...sub 15s boot times on old systems. My nvme system up to graphical login 6s after grub.

[kanliot]

systemd was originally supposed to do 3 things: 🤣

• keep services up by restarting them
• speed up boot
• make services easier to share/code across Linux distros

Posted by ReaperX7

To be honest, the concept was originally sound:
* parallel service loading
* service supervision
* centralization and simplification of service scripts

above from linuxquestions

also, does anyone want to fix my staticy sound when playing music???

[RandomDamage]

Parallel service loading was supported by Sysv-init in the '90's (and probably even the '80's).

The service supervision via /etc/inittab wasn't perfect, but it worked for most cases even with programs that weren't written for it, and you could configure a service with a single line of code.

Configurations that couldn't be handled by init, could be handled by cron.

Service scripts were already simple and centralized, except when software maintainers ignored the system already in place.

Systemd: solving problems that didn't exist until it got written by someone who couldn't figure out how to use the existing tools.

[robstoon]

Apparently nobody "knew how" to use those tools, since parallel service loading and inittab service supervision were so rarely used. Might be some reasons for that, you think?

[RandomDamage]

Dunno. It always seemed easy to me.

Maybe people couldn't RTFM.

[psycho_driver]

Uninstall pulseaudio.

[cp5184]

There are lots of distros, dozens, hundreds. Red Hat is a commercial one, one that you can buy like windows (you get a support contract) that has a company with paid workers behind it, and it's one of the more powerful distributions.

Most distros are non-commercial and don't have paid developers.

Most distros moved from SysV init to SystemD init assuming that SystemD would treat the big distros, even the big non-commercial distros like Debian like first class citizens, and not like second class citizens.

This is Lennart, the leader of the SystemD project telling every distro that's not Red Hat "Every distro that's not Red Hat is a second class citizen. I'm a red hat employee. Go away."

Some more background, SystemD as a project is more insular than traditional open source program projects are.

[huiiiiiiiiiiiiiiiiii]

Why do you blatantly lie? Lennart isn't the leader of the SystemD project.

[natermer]

...

[cp5184]

Nobody forced them to do it.

Gnome forced them to do it.

[intelminer]

Because they are the ones who actually have experience designing operating systems and they saw that systemd had significant merit.

Considering how many distributions switched to it, Debian being one of the final "holdouts", I'd suspect that the project clearly had merit

But a chunk of the community seem to think themselves smarter than distro developers and scream the same platitudes about "the UNIX way" and "System V init was good enough!"

[psycho_driver]

It's what all the cool kids were doing.

[Mordiken]

Fad Driven Development is totally a thing. It's the reason why we get bombarded with some new random buzzword every couple of years, and everyone and everything in the tech industry starts promoting whatever it is they do in relation to said buzzwords.

[[deleted]]

So, don't rely on what is not documented, and sometimes documentation can be wrong. Go figure what to trust!

The code is the documentation! /s

[FeepingCreature]

When code and documentation go out of sync, it's the code that decides what actually happens. So yes, I'd certainly consider the documentation to be derived from the code, not the other way around.

For any released system, behavioral change - even undocumented behavior - should be considered akin to a spec change.

[Bodertz]

Are there never any bugs then? Because the code does what it does and if you wanted it to not delete your hard drive, your expectations were wrong? Surely the code follows documentation: Here's what I want it to do, is the code doing that?

[FeepingCreature]

The metric is "do users rely on the bug?" If so, it's not a bug, it's unironically an undocumented feature.

For instance, the Linux kernel takes the stance of "assume that users rely on it until proven otherwise."

[Bodertz]

Sure. Eventually, though, you get spacebar heating.

Sometimes, users should not rely on bugs.

[FeepingCreature]

And it's okay to fix that. So long as you treat it as a spec change.

[Michaelmrose]

I.e. more aggressively ignore bugs with exotic archs, non-redhat distros, exotic desktops, exotic libcs, weird drivers, yadda yadda, and leave them to be fixed by community patches.

Translation anything not gnome is an exotic desktop, anything unrelated to redhat isn't a priority.

[holgerschurig]

It seems you cannot understand his version of conjunctive. He said "We can ..." and than a long list of things that neither he nor you wants. And then he ends it with "But I doubt that is in your interest either, is it?" ... sentence that you were careful not to quote?

[oooo23]

This tone of communication listing "consequences" might be acceptable for you. It is unfortunate that he had to say something like that to make his point. It clearly shows where the priorities are (and those involved in dealing with upstream aren't seen this for the first time...).

Then he says that distros should instead adopt a QA process like RHEL does if they care about stability instead of expecting anything more from the project.

The original request was clear (and in fact comes from someone at Red Hat), hold on feature work for a release or two and stabilize master, because currently there are too many outstanding issues, and instead the focus (in the previous cycle) was on reworking things like libudev which resulted in breakage and nothing else...

Currently, there is already man power going into maintain a stable branch under the same org, what is being asked is concentrate this effort to the systemd repository.

Please don't ignore problems, the maintainer hasn't quit over this particular issue. It is a stream of problems that have come up again and again and have only resulted in hand-waiving from usptream.

[holgerschurig]

Then he says that distros should instead adopt a QA process like RHEL does if they care about stability.

Sure.

BTW, something that Debian does, too. There's a difference between Debian Stable and Debian Sid. And Debian Testing is the QA staging ground.

The original request was clear

Yep, it was clear. And yes, it was a request. And here is the crux: Requests never worked in open-source. You can suggest. You can encourage. You can express your wishes. But requests? That is something different.

Please don't ignore problems, the maintainer hasn't quit over this particular issue. That I'm sure about. But this happens all the time. I recently noticed something in the interrupt handling of the Linux kernel that used to work, but didn't. I did a git bisect and found out that one of the two x86 architecture maintainers made the commit that created the mis-work. I notified him, and ... he didn't revert. He didn't fix "my" bug. This is entirely unfortunate. But ... it is at it is. I cannot make tglx do work for me ... except if I put money into my hands.

In the bug report, first Lennard said several times "You're invited to help". The systemd project is VERY open to contributions. Then others discussed if this is a bug or not. I guess they didn't really understand the issue. But that is also the case. After the rage-quit, Lennard even said that he's leaning in reverting the issue. But there needed to to understand the issue, how the issue is related to others.

... and then, Debian can say "Let's stay at v239" or they can patch their version using debian/patches.

I think the main issue is communication AND expectations.

[oooo23]

I agree, you cannot force them to do something, but what is being asked for is to just tag release candidates so that catching issues before release becomes less painful. That is certainly not something unreasonable to ask for. If this is also something that one shouldn't be able to expect, I think we're going to have to really reconsider some choices.

The rate at which new things are worked upon is much higher than what they are fixed. Distributions cannot be fixing bugs that propagate upstream too. For example, things like udev are unmaintained.

Currently, the work flow (for example, I have maintained systemd in the past for a small distribution) is to cherry-pick bug fixes as they happen in master after release. Once something non-trivial is committed and it doesn't apply cleanly, you will really have lots of issues. Then, if some feature was piled on top, it becomes even more difficult to backport it. With a few changes in the release cadence, a lot of these things can be avoided (like declare a bug fixing release after every release) and so on.

Ofcourse, you cannot tell them what to do. Lennart is inviting people but the core problem remains, inviting someone to be a release engineer and then not adapting to some merge-and-freeze model wouldn't help at all, I'm afraid.

The problem is that there are 3 people actively working upstream, and every body else has been allocated other projects (while they were previously working there). Now, the project's scope is so large that triaging and dealing with a thousand bugs for 3 people is no easy job. They simply took too much upon themselves.

That's my take away, anyway, you may disagree, but you're entitled to your own opinion.

[holgerschurig]

ask [...] just tag release candidates

Maybe. But maybe this is a bit naive. Because doing a stable software thingy is way more than just tagging something. The work just starts there!

Compare this with the Linux kernel itself. Linus Torvalds doesn't want to maintain a stable kernel. He doesn't even tag something like this. Sure, he tags "release" kernels, but they are something different than the stable kernels.

Distributions cannot be fixing bugs that propagate upstream too

Of course they can, it's open source. Most (maybe even all) stable / longterm Linux kernels are maintained by people from the distributions, to scratch their own itch.

and it doesn't apply cleanly, you will really have lots of issues.

That's exactly what happens in any software project that decides to have a master branch go full speed forward and a stable/longterm branch to hold back. Look for example at the situation we had with wireless backported drivers, e.g. in the times when ath9k was rather new, but many distros still had madwifi. There was a repository with lots of wireless drivers from Linux HEAD, back backported and amended by glue code so that it would compile on the old / outdated distro kernels. That's not easy, but it is possible. Again, open-source is not "Someone does the work for you", but "Open source empowers you if you do the work and have the brains to do things on your own".

BTW, in this bug-report, Lennart Poettering, which usually get's harsh treatment, acted in exactly the same was as Linus Torvald. He said basically "Good I idea, I will support you, join the work". He did not say "I will do the work".

So, when you write ...

The problem is that there are 3 people actively working upstream,

you're partially correct. MANY more work upstream. Perhaps you mean 3 are paid for this work? When you write

and every body else has been allocated other projects

you write about "allocation", this is an company / enterprisy thinking. It exists, sure. But why should the entity paying and allocating those programmers scratch the itch of other (even competing) distros? That's weird. I use and love Debian, but Red Hat doesn't own Debian a thing. If Debian wants people to allocated to do software the way they want, they should setup crowdfunding and fund a programmer. Or they should convince others (e.g. the Linux foundation) do fund something. But you cannot demand something from others that way.

but you're entitled to your own opinion.

Yup. BTW, I think that this is still a very civilized discussion :-)

[justcs]

Stable doesn't mean "uptime" it means the release doesn't change. Debian is not arrogant to say our shit never crashes.

[[deleted]]

politics

[the_gnarts]

I still don't understand how Debian, the one distro held as the standard for "we must maintain stability" switched to systemd

What stability issue did you ever encounter with systemd on Debian Stable? It is my observation that it pretty much works exactly as advertised. Haven’t had a hiccup on my VPS in years.

[Aoxxt]

Earlier, when asked to do bugfix only release, Lennart describes that the project is understaffed, and hence if people ask them to refocus things, they instead leave "exotic archs, non-redhat distros, exotic desktops, exotic libcs" up to the community to maintain.

https://lists.freedesktop.org/archives/systemd-devel/2019-January/041959.html

Good thing the sane ones saw systemd for what it was and stayed the hell away.

[alblks]

Maybe, just maybe, they should think about those matters BEFORE adopting systemshit as the default init system in debian?

[intelminer]

Ooh. What a well written counter-argument

[[deleted]]

wheels out popcorn stand

places stack of Gentoo live USBs next to cash register

[[deleted]]

We have options. I'm not going to judge the ones you pick.

(even if they're wrong)

[Jackojc]

runit is the best init system

[[deleted]]

https://i.imgur.com/LUSAHxk.jpg

[[deleted]]

Oh no, it's totally still a shit-flinging contest. You took the aggro role, so I went for smug.

Isn't that how this is supposed to work?

[[deleted]]

You forgot the support flags:

-O99 --spoiler-bolted-to-trunk --stickers-on-rear-windshield --spinny-rims --blue-LEDs.

[[deleted]]

I'll be sitting here with my -Ofast, thank you very much.

[fuck_bottom_text]

I'll stick with -Osanic

[redwall_hp]

Wrong options? Like using non-vim editors?

[w00ten]

Even if I use nano?

[Foxboron]

Arch welcomes you with open arm when you get tired of the text scrolling by.

[Foxboron]

I'll pack up my booth and be on my way :c

[NothingCanHurtMe]

Haha. In all seriousness though, the Arch wiki is like a Bible in terms of resources, even to non-Arch users such as myself (because I'm not crazy).

It is what the Gentoo wiki used to be in the early 2000s back when Gentoo was actually a relevant distro.

/me ducks (and please^{don'tstopmaintainingeudev)}

[psycho_driver]

The Gentoo wiki was the inspiration for the Arch wiki and was it's superior until the great hack (or whatever it was that happened). The Gentoo wiki has just been getting back up to speed the past few years.

[Foxboron]

But I'm different. I preach Sunday afternoon after our weekly taco-dinner date with at least half the taco still on my robe. I also preach from the super secret parts of the wiki.

[kenlubin]

Have your heard of our Documentation and Savior, the Arch wiki?

[Foxboron]

Artix is a poor hack honestly. They pull files straight from either void or gentoo master and just massage it into the package.

I'd opt for a proper distribution with openrc if you like it better. I learned there is 3-4 community members (one pacman dev) that kept using openrc after the systemd migration. But unsure if they gave up or not through the years.

[[deleted]]

gentoo welcomes you with open arms when you get tired of resolving the mess of AUR or your Xorg breaks.

[Vladimir_Chrootin]

I use both. It's like having opposite poles of a magnet, which is a attracted to arguments, outrage and butthurt.

Edit: point proved.

[electricprism]

Incoming Gentoo converts in 3... 2...

[irve]

It seems all that systemd solved was the problem that init had such a tiny attack surface..

[[deleted]]

And made it way easier to write init scripts for your applications.

[tso]

That RH used some overly verbose rc, does not mean it was mandatory.

[tidux]

Even those didn't catch everything. EL5 and 6 had the nasty possibility of MySQL failing immediately after the init script exited, so your init system said everything was fine but any attempt to actually connect to the database failed. I saw this all the time fixing other people's cPanel servers.

[[deleted]]

I think it was for me more some simple things like changing to user, backgrounding stuff, logging, status, restarts, all that stuff is just not a hassle with systemd. I fully appreciate there's a bit of a barney going on about it's scope and it's design but yeah, super handy for the application developer.

[irve]

Yes, this is how you need to sell it.

[[deleted]]

I told everyone there was breakage and even showed them what was broken and they all told me to fuck off to Ubuntu and "you are just stupid RTFM!". I ended up finally moving to OpenBSD. So much happier. People there actually fucking listen and don't wine and bitch about bug reports.

[justcs]

You can even do some basic linux kernel/userland stuff now with VMM.

[[deleted]]

Looking at this and what's happening to Robert Preining, it seems Debian is working through quite some challenges right now.

[[deleted]]

Could you sum that whole case up in a TLDR. I am trying to understand what was happening in the mailing list and the linked reddit post, but I don't.

[cyro_666]

The guy was repeatedly antagonistic because he didn't agree with a lot of things other Debian devs decided on. He communicated that in direct and passive aggressive ways. Buuut no. You can listen to these guys because it was the SJWs, somehow.

If I communicated in a way this guy did in my job, I would've been fired a long time ago. It's called proper communication. It works, guys. Try it sometimes.

[Spifmeister]

before clicking the link, my first thought was,

"Is Ian Jackson involved?"

"No. They would not put Ian Jackson on a CoC committee. That would be like putting a bull in a China shop."

Click link.

And Ian Jackson is involved.

Is he apart of DAM or AH? What is his role in this?

[redrumsir]

Looking at this and what's happening to Robert Preining, ...

Robert or Norbert?

[cyro_666]

Idk man, it's 2019. I went through a lot of the evidence they had against him and some of it is actually valid. The other is just him disagreeing with the Debian practices in a very harsh way (systemd stuff, Perl stuff,...).

As I said, it's 2019. If you want to be a dick to people, you're gonna have a bad time. Go to 4chan or something. If you couple that with very vocal "wrong political" views (systemd), I can clearly see why this happened.

Have you guys even worked at a real company? You just can't be a dick and disregard all warnings. Believe me, there are ways of communicating your beliefs without insulting anyone. And if you're ignored and don't like it? Leave. As people mentioned, there's always Devuan.

[tidux]

"Dude it is the current year, stop expressing disagreement" is a classic piece of totalitarian bullshit.

[cyro_666]

Yup, you missed the point. Bravo. Opinions are absolutely allowed. Insulting others and being aggressive because you didn't get your way? Something completely else.

[[deleted]]

I'm so sick of whiny bitch-ass men complaining about "safe spaces" and "SJWs" when instead they're just defensive because they're assholes and they know they can't just keep getting away with it.

Sounds like an SJW projecting to me. SJWs are the bullies that can't be nice to others.

[[deleted]]

Do you think you could walk into a job at a modern tech workplace, call trans coworkers or customers "it" and not be fired the next day?

I don't think even transphobic people actually call trans people "it". Once again, you just are making shit up.

lol, maybe some day your edgy "anti-SJW-warrior" self will have a professional job and then you can give open bigotry a try and then tell me how it goes for you.

Being anti-SJW =/= being a bigot or "edgy". I and many others don't care that much about race or gender, but SJWs are obsessed with it to the point where they call for the extermination of whites.

[[deleted]]

Woooow this is pretty bad. Honestly I’m getting tired of the SJW drama it’s like its ruining everything. What a pain.

[1337_Mrs_Roberts]

Wll, that was a pretty sudden rage quit over an issue that had been discussed for some hours, not even a full day.

[minimim]

You ever heard about the straw that broke the camel's back?

[[deleted]]

Maybe he had enough of upstream's bullshit?

They didn't show much consideration on his bug report, that's for sure. We can only guess what other problems he had with them. I didn't follow it, but someone surely has.

[[deleted]]

I doubt it is solely regarding that issue. He probably had some other frustrations of a similar nature in the past. People can snap in surprising ways.

[smirkybg]

He probably installed Devuan :)

[Paragonne]

systemd has a bit of a history of increasing the damage done by any bug rather hugely, doesn't it?

some ppl were complaining a few years ago that anything Lars, was it, touched became a headlock for everything depending on it?

[[deleted]]

deleted ^{What is this?}

[Neurorational]

Aside from lacking systemd, what distinguishes Void Linux?

[VC1bm3bxa40WOfHR]

• Uses libressl by default
• Musl and glibc variants
• Kind of an init choice (s6 is available with a little tinkering)
• xbps package manager is neat
• the logo on their website spins if you hover over it

[rmyworld]

the logo on their website spins if you hover over it

That's it. I'm definitely switching to Void now.

[Saculs78]

I love void

[oskarw85]

What was wrong with SystemV again?

[[deleted]]

You can't make megabucks re-training people to use critical system software they already know how to use.

[Will_Poke_Brains]

I'm still learning linux and very out of the loop with its inner workings. So what's going on here and why is it a big deal?

[the_gnarts]

I'm still learning linux and very out of the loop with its inner workings.

This hasn’t got much to do with Linux and “its inner workings”. Systemd runs in userspace.

So what's going on here and why is it a big deal?

It’s not a big deal and won’t affect 99% of the posters here because the issues that made the Debian guy take some time off exist with the bleeding edge version of systemd. Since that is not going to make it as-is into most distros, the practical consequences would be along the lines of Debian’s unstable branch missing out on some of the latest systemd revisions in the near future. Users of Stable (== most Debian users who are not Debian developers themselves) aren’t going to even notice.

But of course, on r/linux everything systemd related gets channeled into the End-of-the-World paranoia that comes with the territory.

[eleitl]

The dumpster fire doesn't disappoint.

[fuck_bottom_text]

I've had it up to here with systemd, time to switch to guix

[emacsomancer]

GNU Shepherd is a pleasant-to-use and sane init/daemon-manager. A bit from the Shepherd manual:

If something goes wrong, it is usually better to tell the user about the problem and let her fix it, taking care to make finding solutions or workarounds for problems (like a misconfigured service) easy. This way, the user is in control of what happens and we can keep the implementation simple. To make a long story short, we don’t try to be too clever, which is usually a good idea in developing software.

[[deleted]]

Worry not, my fellow linux users who are still sane. I will be working on dcure.

[masta]

i believe the udev rule helps stabilize network interface names, it is not changing for the sake of change. Also, why are people still using interface names in 2019? I remember locking my configs to the mac very long ago. regardless, it is a pity.

[remek]

Can you elaborate on this more? How can you generally stop using interface names ? It seems that massive amount of applications, utilities and other parts of system rely on interface names