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
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?
Posted Jun 8, 2016 4:37 UTC (Wed)
by drag (guest, #31333)
[Link] (1 responses)
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.
Posted Jun 9, 2016 6:17 UTC (Thu)
by NightMonkey (subscriber, #23051)
[Link]
God, I love Gentoo. :)
Posted Jun 8, 2016 4:43 UTC (Wed)
by error27 (subscriber, #8346)
[Link] (4 responses)
Posted Jun 8, 2016 5:50 UTC (Wed)
by rengolin (guest, #48414)
[Link] (3 responses)
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.
Posted Jun 9, 2016 9:33 UTC (Thu)
by Seegras (guest, #20463)
[Link] (2 responses)
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.
Posted Jun 9, 2016 14:10 UTC (Thu)
by johannbg (guest, #65743)
[Link] (1 responses)
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 ) .
Posted Jun 9, 2016 18:59 UTC (Thu)
by flussence (guest, #85566)
[Link]
If.
Posted Jun 8, 2016 7:44 UTC (Wed)
by rschroev (subscriber, #4164)
[Link] (23 responses)
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.
Posted Jun 8, 2016 8:21 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (19 responses)
Posted Jun 8, 2016 8:28 UTC (Wed)
by rschroev (subscriber, #4164)
[Link] (18 responses)
Posted Jun 8, 2016 8:32 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (17 responses)
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!
Posted Jun 8, 2016 22:43 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (13 responses)
It's the same with systemd - its interface is stable.
Posted Jun 9, 2016 4:35 UTC (Thu)
by xtifr (guest, #143)
[Link] (12 responses)
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.
Posted Jun 9, 2016 7:21 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (10 responses)
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.
Posted Jun 9, 2016 10:59 UTC (Thu)
by xtifr (guest, #143)
[Link]
On the other hand, neither this nor the fsync thing actually bit me, while the /dev changes did, so, good example. :)
Posted Jun 9, 2016 13:24 UTC (Thu)
by johannbg (guest, #65743)
[Link] (8 responses)
Which issues in systemd do you feel should have higher priority development priority?
Posted Jun 9, 2016 17:19 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (7 responses)
Posted Jun 9, 2016 19:17 UTC (Thu)
by viro (subscriber, #7872)
[Link] (6 responses)
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...
Posted Jun 9, 2016 19:26 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (3 responses)
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.
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).
Posted Jun 10, 2016 18:25 UTC (Fri)
by drag (guest, #31333)
[Link] (1 responses)
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.
Posted Jun 13, 2016 15:32 UTC (Mon)
by niner (subscriber, #26151)
[Link]
Posted Jun 9, 2016 22:20 UTC (Thu)
by johannbg (guest, #65743)
[Link] (1 responses)
Posted Jun 10, 2016 0:23 UTC (Fri)
by viro (subscriber, #7872)
[Link]
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...)
Posted Jun 18, 2016 16:29 UTC (Sat)
by Wol (subscriber, #4433)
[Link]
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,
Posted Jun 9, 2016 8:49 UTC (Thu)
by pflykt (subscriber, #2757)
[Link]
...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.
Posted Jun 13, 2016 8:23 UTC (Mon)
by Jluis (guest, #28564)
[Link]
Posted Jun 8, 2016 15:24 UTC (Wed)
by johannbg (guest, #65743)
[Link]
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.
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:
Posted Jun 9, 2016 21:21 UTC (Thu)
by mstone_ (subscriber, #66309)
[Link]
Posted Jun 8, 2016 16:06 UTC (Wed)
by lsl (subscriber, #86508)
[Link]
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.
Distributors ponder a systemd change
Distributors ponder a systemd change
Distributors ponder a systemd change
Distributors ponder a systemd change
Distributors ponder a systemd change
Distributors ponder a systemd change
Distributors ponder a systemd change
Distributors ponder a systemd change
Distributors ponder a systemd change
So, like, until 2056?
Distributors ponder a systemd change
Distributors ponder a systemd change
Distributors ponder a systemd change
Distributors ponder a systemd change
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.
Distributors ponder a systemd change
Distributors ponder a systemd change
Distributors ponder a systemd change
Distributors ponder a systemd change
Distributors ponder a systemd change
Distributors ponder a systemd change
Distributors ponder a systemd change
Distributors ponder a systemd change
Distributors ponder a systemd change
Distributors ponder a systemd change
Distributors ponder a systemd change
Distributors ponder a systemd change
Distributors ponder a systemd change
Wol
Distributors ponder a systemd change
Distributors ponder a systemd change
Distributors ponder a systemd change
Distributors ponder a systemd change
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
Distributors ponder a systemd change