Distributors ponder a systemd change

Posted Jun 8, 2016 8:32 UTC (Wed) by Cyberax (✭ supporter ✭, #52523)
In reply to: Distributors ponder a systemd change by rschroev
Parent article: Distributors ponder a systemd change

That's why I'm glad that actual Linux (kernel and userland) developers don't care much about "consensus".

Distributors ponder a systemd change

Posted Jun 8, 2016 21:19 UTC (Wed) by xtifr (guest, #143) [Link] (15 responses)

But the kernel developers at least claim to care about breaking working code. And in this case, we're talking about a change that has the potential to render a system completely unusable! If I background (as I frequently do) a system update, and then log out, this change means the update will be killed at some unknown point. If this happens while certain key files are being updated, the result can be catastrophic. And if I later log back in and use ps to see if the update is still running, and find it isn't, I may decide it's ok to shut down, destroying any remote chance I might have had at a simple recovery. (Assuming I can still log back in in the first place....)

If it's a remote system, staying logged in during the entire update process may not even be an option. My laptop and I may have places we need to be.

Compared to the potential for catastrophe this change brings, the (admittedly real and very annoying) problem of programs which fail to shut themselves down properly when asked to do so seems minor.

Now, I admit that sometimes, a potentially system-destroying change is unavoidable, for various reasons. But in a case like that, there really have to be bright, shining, neon lights that say "if you do X at this point, your system may be corrupted!" Quietly making such a change without warning is simply not acceptable!

Fortunately, Debian seems to have restored the older default, so my home systems, at least, are safe.

Distributors ponder a systemd change

Posted Jun 8, 2016 22:43 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (13 responses)

> But the kernel developers at least claim to care about breaking working code.
Kernel developers do a lot of stuff that allows breaking existing code. Kernel build option defaults are routinely flipped to change some parts of user-visible behavior.

It's the same with systemd - its interface is stable.

Distributors ponder a systemd change

Posted Jun 9, 2016 4:35 UTC (Thu) by xtifr (guest, #143) [Link] (12 responses)

I was going to say I couldn't think of a kernel change that has as much potential for widespread breakage, but then I remembered the fsync nightmares of a few years back. So...you have a point.

Still, that's the only recent example I can think of where the kernel folks did something with as much potential for catastrophic breakage as this has. If you have some other examples, which affected programs as widely used as screen, tmux, emacs-daemon, and nohup, I'd be curious to hear them.

Distributors ponder a systemd change

Posted Jun 9, 2016 7:21 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (10 responses)

Technically, this change does not affect them - they can work just fine if this setting is disabled. It's a simple default value switch - you could have used the autokill mode since when it became available in 2013. Still, it would be nice if systemd developers at least tried to fix other important stuff first.

If you want a comparable change in Linux, then remember the /dev/hda -> /dev/sda switch. That broke a _lot_ of stuff that was doing stupid things like detecting hard disks by checking for /dev/hd? devices.

Distributors ponder a systemd change

Posted Jun 9, 2016 10:59 UTC (Thu) by xtifr (guest, #143) [Link]

It doesn't affect them _if they notice_ before the system is trashed. In other words, if they're aware of it. Which is really my main complaint. The danger potential is very high, but the number of warnings that were given were near-zero. I actually had this version of systemd installed with the dangerous new default, for a little while, and had no idea. (Which, yes, I know, is the risk I take running bleeding edge software from Debian's unstable distro. Even so...)

On the other hand, neither this nor the fsync thing actually bit me, while the /dev changes did, so, good example. :)

Distributors ponder a systemd change

Posted Jun 9, 2016 13:24 UTC (Thu) by johannbg (guest, #65743) [Link] (8 responses)

"would be nice if systemd developers at least tried to fix other important stuff first."

Which issues in systemd do you feel should have higher priority development priority?

Distributors ponder a systemd change

Posted Jun 9, 2016 17:19 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (7 responses)

Sorry, wrong wording - they should have proposed fixes to other projects that might reasonably depend on the current behavior.

Distributors ponder a systemd change

Posted Jun 9, 2016 19:17 UTC (Thu) by viro (subscriber, #7872) [Link] (6 responses)

FWIW, the thing that Johann doesn't seem to be able to grasp is this: the world does not owe us to recognize the greatness of our ideas and apply whatever efforts it takes to make them work. Not to me, not to him, not to Linus, not to Lennart, not to *anybody*. No matter how great the idea really is. Most of us get it by the time we are out of our teens...

If distros decide, en mass, that reverting the change of default is less headache than doing urgent fixups to screen/tmux/whatnot, then the whole thing had been handled wrong. By definition. And responsibility for the choice of tactics that happened to backfire is upon those who chose it. Especially since the headache for distros had been easy to anticipate, along with the likely areas where that headache would come from. FWIW, simple search shows reports of screen(1) breakage *5* *years* *ago* on that very thing turned on on reporter's box. In fedora. With Johann directly involved in handling of that report, amusingly enough, so if systemd developers were unaware of the likely sources of trouble, a part of blame was actually his...

Distributors ponder a systemd change

Posted Jun 9, 2016 19:26 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

Sure. However, it is OK to propose changes that require some work from other projects.

If they fail to take off after many years of trying then the idea was obviously bad (see: Python 3) and probably should be adjusted and/or abandoned.

Distributors ponder a systemd change

Posted Jun 10, 2016 13:12 UTC (Fri) by vonbrand (subscriber, #4458) [Link] (2 responses)

Python 3 is slowly making inroads, held back by the still not complete fixup of key libraries. Usage stands at around 50% Python 3 and 70% Python 2 (the 20% overlap is code used with both).

Distributors ponder a systemd change

Posted Jun 10, 2016 18:25 UTC (Fri) by drag (guest, #31333) [Link] (1 responses)

If everybody refuses to accept that bad things happened in the python2 to 3 transition that caused problems and delayed progress then it's likely that it's just happen again, and again, and again.

There are two ways of screwing something up, or 'making mistakes'

1. No-fault. Based on information available at the time it seemed like it was a good idea. Unfortunately it turned out to have jacked everything up.

2. Fault. Based on information available at the time I knew it was a bad decision, but I thought I could get away with it. Too bad I got caught jacking everything up.

The first one is fine. It can't be avoided. It's part of how technology progresses and dealing with mistakes is just something we have to do. The second one is where you deserve to be removed from a position of trust.

Even if you have people disagreeing with you about choices you make it doesn't mean you fall into category 2, even if they are ultimately right. They just now have proof of their correct decisions. Doesn't mean they will be correct next time, though.

A lot of people see mistakes type 1 and then assign malicious intent in their minds to transform them to type 2, then go cry on the internet. A lot of people see people make mistakes type 1 and then try to erase the mistake because of a confusion that only type 2 mistakes exist, or they fail to realize the distinction.

Personally I like python3. I don't know what they could of done to improve the transition. Alternative seems to be what perl has done.

Distributors ponder a systemd change

Posted Jun 13, 2016 15:32 UTC (Mon) by niner (subscriber, #26151) [Link]

They could have improved the transition by providing backwards compatibility which would have been possible. It would even be possible still. Instead they required everyone to port their libraries and have all dependencies being ported before one can port one's own code. In hindsight clearly not the winning strategy and I wish they'd have used the chance to at least make a couple more steps forward (think graphemes and GIL) when they insisted on backwards incompatibility.

Distributors ponder a systemd change

Posted Jun 9, 2016 22:20 UTC (Thu) by johannbg (guest, #65743) [Link] (1 responses)

I have no problem accepting responsibility and taking blame when I deserve it so if that shit is on me, that shit is on me and I'll try to be better next time. I dont particularly take pride in having to leave project which left systemd only half integrated in the distribution ( and no one picked up that work and probably never will ) but I had no other choice so you can just as well throw that to the shit pile as well. A man is worthless if he cannot live up to his own standards and since I was unable to complete my work there I most certainly did not live up to mine...

Distributors ponder a systemd change

Posted Jun 10, 2016 0:23 UTC (Fri) by viro (subscriber, #7872) [Link]

Good sodding grief... seek professional help. Seriously. This kind of histrionics would've been over the top even in a teenager, and you are past that age.

a) left the project (fedora, I take it?) != lost all ability to contact systemd developers. Their list isn't closed, AFAIK.

b) whether you've failed to inform them about screen(1) breaking in such situation back then or not, they certainly could've looked themselves. Searching for bug reports mentioning that setting is not a rocket science.

c) I've no comment on the state of Fedora (before or after systemd transition - it's not something I use other than for testing and that only when I can't reproduce a bug on something saner; I sure as hell do not watch the politcs in it), and your choice of standards is up to you, but that amount of drama got to be counterproductive whatever those standards might be. I really, honestly have no fucking idea how you've parted ways with that project; judging by your postings years later it had to have been messy as hell and at a guess hadn't been any calmer than said postings (BTW, as an aside - what the hell _is_ in phoenix? You keep refering to it, and by the context it sounds like a center of some Evil Corporate Cabal(tm), presumably RH-related one. I'm fairly sure that RH headquarters are still in Raleigh and AFAIK there's no office in Phoenix - AZ or otherwise...)

Distributors ponder a systemd change

Posted Jun 18, 2016 16:29 UTC (Sat) by Wol (subscriber, #4433) [Link]

> Still, that's the only recent example I can think of where the kernel folks did something with as much potential for catastrophic breakage as this has.

Not recent, but it was a deliberate decision by Linus and it caused chaos ...

Who remembers him ripping the swap optimisation code out of kernel 2.4? Leading to a spate of linux systems crashing as sysadmins discovered "swap should be twice ram" was NOT an old wives' tale ...

Cheers,
Wol

Distributors ponder a systemd change

Posted Jun 9, 2016 8:49 UTC (Thu) by pflykt (subscriber, #2757) [Link]

> Fortunately, Debian seems to have restored the older default, so my home systems, at least, are safe.

...and which is the correct action for a responsible distribution to take, considering what its users think is the intended behavior, if I may add. This, and figuring out how to address the initial problem, is where the distributor really adds value.

Distributors ponder a systemd change

Posted Jun 13, 2016 8:23 UTC (Mon) by Jluis (guest, #28564) [Link]

But kernel makes a true effort to no break userland.