|
|
Subscribe / Log in / New account

Distributors ponder a systemd change

Distributors ponder a systemd change

Posted Jun 8, 2016 3:31 UTC (Wed) by pizza (subscriber, #46)
In reply to: Distributors ponder a systemd change by acollins
Parent article: Distributors ponder a systemd change

> Breaking an extremely common usecase and then telling everyone to fix their packages after the fact is not acceptable.

Assuming your distribution doesn't do it for you before you even get the update, the immediate solution is "flip the default back".

> This should have followed the kernel process, where a change like this is clearly communicated months/years ahead of time and the community given time
to make the transition.

This feature was in the very first public systemd release. How much longer should they have waited?


to post comments

Distributors ponder a systemd change

Posted Jun 8, 2016 4:37 UTC (Wed) by drag (guest, #31333) [Link] (1 responses)

I definately agree.

Systemd releases are not intended for end users. They are low-level Linux plumbing software. The intended audience are distributions and system integrators. Nothing systemd is doing here is forcing anybody to do anything at all.

If distributions don't like it they just switch it back. It's their job as distributions to be aware of these sorts of things and make these sorts of decisions. If the distributions are so clueless to miss this sort of thing or they abdicate their rights to make their own choices and just accept code carte blanche from upstream... then what is the point of distributions at all? Users would be better off just cutting out the middle man and just pull directly from upstream in some sort of automated 'linux from scratch' approach to installing Linux.

Distributors ponder a systemd change

Posted Jun 9, 2016 6:17 UTC (Thu) by NightMonkey (subscriber, #23051) [Link]

"Users would be better off just cutting out the middle man and just pull directly from upstream in some sort of automated 'linux from scratch' approach to installing Linux."

God, I love Gentoo. :)

Distributors ponder a systemd change

Posted Jun 8, 2016 4:43 UTC (Wed) by error27 (subscriber, #8346) [Link] (4 responses)

Until screen and tmux were updated for a start.

Distributors ponder a systemd change

Posted Jun 8, 2016 5:50 UTC (Wed) by rengolin (guest, #48414) [Link] (3 responses)

Aren't we picking favourites here? How much longer should people wait for those to change?

Any stable distro can protect you from this change (I use Arch), so I don't see this as a big deal at all.

The only slight problem I see is that they should have worked directly with those more affected (ex. tmux and screen) *before* defining what the interface looks like, to avoid long lasting design problems. Though, this is again, chicken and egg, as defining who you talk to first is not easy.

All in all, noisy and a tad inefficient, but nothing out of the ordinary.

Distributors ponder a systemd change

Posted Jun 9, 2016 9:33 UTC (Thu) by Seegras (guest, #20463) [Link] (2 responses)

You don't "wait for other to change" -- you implement.

And this means, if you want to change the default there, to PROVIDE A FUCKING FIX for afflicted programs such as nohup, screen and tmux. Even if it's your forked version of it, and furthermore ANNOUNCE IN ADVANCE to your (biggest) downstreams when you're changing the default.

I can see the reasoning behind what systemd did. But I absolutely object the way they did and communicated it.

Distributors ponder a systemd change

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

If component A exposes a bug in component B ( regardless if that bug was triggered by changes in that project defaults or simple encountered when used in conjunction with it ) then the community that makes up component B is responsible for fixing it ( bugs are fixed where they belong ) just like any other bug that get's filed yeah sure all patches welcome but there is absolutely no obligation from project A, it's community or developers or just reporters in general that discovered the bug and decided to report it, to fix it as well so you must be a very special individual if you really think or expect that an upstream that flips a switch in their own project defaults, run around the whole internet to fix every breakage and bugs in whatever corner of the software galaxy which are in no relation to their project o_O.

And with regards to announcements it's expected that a downstream package maintainer(s) are in good relation with upstream ( which all the major distribution Arch/CoreOS/Debian/Fedora/Gentoo/OpenSuse/Ubuntu etc are with systemd ) and follow upstream changes closely ( which they do ) to be prepared for changes like these ( which they where ) and start dialogs with downstream community should they feel necessary to do so ( which is far as I know all of them did, some before the official release of systemd 230 version, others after ).

So the question here is how come you missed that discussion in your community ( which usually indicates people that miss such discussions aren't active contributes in their communities or part of it at all as in just end users ) .

Distributors ponder a systemd change

Posted Jun 9, 2016 18:59 UTC (Thu) by flussence (guest, #85566) [Link]

>If component A exposes a bug in component B

If.

Distributors ponder a systemd change

Posted Jun 8, 2016 7:44 UTC (Wed) by rschroev (subscriber, #4164) [Link] (23 responses)

> How much longer should they have waited?

Until there is a consensus in the Linux community (not just in Poettering's mind or the systemd dev community) that this is the right thing to do.

Distributors ponder a systemd change

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

> Until there is a consensus in the Linux community
So, like, until 2056?

Distributors ponder a systemd change

Posted Jun 8, 2016 8:28 UTC (Wed) by rschroev (subscriber, #4164) [Link] (18 responses)

Well yes, or possibly even never. You simply don't make an intrusive change like this without some sort of consensus.

Distributors ponder a systemd change

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

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.

Distributors ponder a systemd change

Posted Jun 8, 2016 15:24 UTC (Wed) by johannbg (guest, #65743) [Link]

"consensus in the Linux community"

You do realize that there exist no such things as "consensus in the Linux community".

If someone as much as farts in the wrong direction he can have create 10 forks. 5 standards, 3 foundations and one distribution as an result of that because someone in some community did not like how that fart smelled.

Distributors ponder a systemd change

Posted Jun 8, 2016 15:48 UTC (Wed) by anselm (subscriber, #2796) [Link] (1 responses)

“Consensus.” You keep using that word. I don't think it means what you think it means.

See RFC 7282:

Engineering always involves a set of tradeoffs. It is almost certain that any time engineering choices need to be made, there will be options that appeal to some people, but are not appealing to some others. In determining consensus, the key is to separate those choices that are simply unappealing from those that are truly problematic. If at the end of the discussion some people have not gotten the choice that they prefer, but they have become convinced that the chosen solution is acceptable, albeit less appealing, they have still come to consensus. Consensus doesn't require that everyone is happy and agrees that the chosen solution is the best one.

Distributors ponder a systemd change

Posted Jun 9, 2016 21:21 UTC (Thu) by mstone_ (subscriber, #66309) [Link]

If there's ever consensus across the linux community, it must mean something other than what you posted.

Distributors ponder a systemd change

Posted Jun 8, 2016 16:06 UTC (Wed) by lsl (subscriber, #86508) [Link]

> This feature was in the very first public systemd release. How much longer should they have waited?

The feature itself is pretty useful and I assume no one has any issues with it. It's the flipping of the default setting that's the disruptive (and therefore controversial) change.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds