Some unreliable predictions for 2015

Posted Jan 19, 2015 17:45 UTC (Mon) by Baylink (guest, #755)
Parent article: Some unreliable predictions for 2015

The problem with systemd, as much as any other problem, is that Lennart and the distro managers who've drunk his FlavorAID decided that my time was theirs to allocate; I had other more important things to do than to spend time learning an entirely new core system component that gives me no measurable advantage.

That's *aside* from how thoroughly it violates nearly every precept of three decades of Unix design philosophy.

Some unreliable predictions for 2015

Posted Jan 19, 2015 22:18 UTC (Mon) by anselm (subscriber, #2796) [Link] (7 responses)

The problem with systemd, as much as any other problem, is that Lennart and the distro managers who've drunk his FlavorAID decided that my time was theirs to allocate

Which is of course a proposition that is entirely different from your deciding that the distribution managers' time is yours to allocate, by requiring them to keep the existing hodgepodge of accidentally-combined components on life support forever.

I had other more important things to do than to spend time learning an entirely new core system component that gives me no measurable advantage.

Great, so go use Slackware.

That's *aside* from how thoroughly it violates nearly every precept of three decades of Unix design philosophy.

That claim has been debunked so often it isn't funny anymore. The main distinguishing characteristic of the existing haphazard setup is that, unlike systemd, it has no discernible design philosophy whatsoever – it is a thrown-together mixture of components from a variety of unrelated sources, with lots of almost-duplication, a disparate zoo of configuration file formats, and dismal documentation.

As far as the famous and much-maligned “Unix design philosophy” is concerned, there can be no doubt that in the traditional setup there are lots of bits and pieces that each do one thing – but it requires quite a fanciful imagination to claim that they do that thing well.

Some unreliable predictions for 2015

Posted Jan 20, 2015 19:31 UTC (Tue) by flussence (guest, #85566) [Link] (2 responses)

> Which is of course a proposition that is entirely different from your deciding that the distribution managers' time is yours to allocate, by requiring them to keep the existing hodgepodge of accidentally-combined components on life support forever.

What a tactless insult to the people whose work you've been freeloading off of for years before systemd.

Some unreliable predictions for 2015

Posted Jan 20, 2015 23:02 UTC (Tue) by anselm (subscriber, #2796) [Link]

It's not the distribution maintainers' fault that the traditional setup is so terrible. It isn't even the upstream software authors' fault. They all had an itch and they scratched it. The problem is that the various bits and pieces arose over a period of 20 years or so, and that nobody really talked to anybody else. For quite some time, the traditional setup used to be the best available solution to the problem at hand, and the distribution maintainers did great and mostly thankless work integrating and improving it. That does not detract from the fact that seen as a complete software system the traditional setup leaves a lot to be desired, especially compared to modern approaches like systemd.

Many systemd detractors do not seem to appreciate that one reason why so many distributions fell over themselves to adopt systemd is that systemd actually makes a distribution maintainer's life a lot easier. It basically saves a distribution from having to implement and maintain a lot of (often distro-specific) basic plumbing that is a hassle to design, build, and keep going. People who instead prefer their Linux distribution to be untainted by systemd are free to do that work themselves, or (as the distribution maintainers have mostly done it for them already) at least shoulder the burden of maintaining it going forward once the original distribution maintainers have decided – as is their privilege – that systemd is a more worthwhile use of their time. In that sense something like Devuan is a great idea because it will hopefully soak up all those folks who would otherwise keep hassling the Debian maintainers about sysvinit.

Some unreliable predictions for 2015

Posted Jan 21, 2015 15:31 UTC (Wed) by judas_iscariote (guest, #47386) [Link]

Truth is a bitter pill .. matter of fact is that the old
stuff barely has any man power to keep it in a working state. the way it is integrated is also beyond terrible.

Some unreliable predictions for 2015

Posted Feb 2, 2015 20:30 UTC (Mon) by nix (subscriber, #2304) [Link] (3 responses)

I dunno. In the world after the horrible but astonishingly still not dead BSD networking so-called "API" and the Unix wars, the claim could be made that being a haphazard mess with no discernible design philosophy *is* the Unix design philosophy. It's just not the one envisaged by Ken Thompson and the early designers, alas :( systemd is definitely a step back towards that early vision.

Some unreliable predictions for 2015

Posted Feb 2, 2015 22:41 UTC (Mon) by raven667 (subscriber, #5198) [Link] (2 responses)

Is the lesson that those who don't understand Multics (and Plan9) are doomed to reinvent it badly and that for all the "bloat" that was removed from the Multics design to make a "simple" UNIX, every bit of it was eventually added back because it was needed but organically without any coherent design, leading to the most deployed, standard system which largely destroyed all others being a creeping inconsistent horror, that we all love dearly 8-)

Reminds me of http://mjg59.livejournal.com/136274.html

A bit of off-topic

Posted Feb 3, 2015 8:43 UTC (Tue) by dgm (subscriber, #49227) [Link] (1 responses)

I think Mathew missed it big time with this post. Firstly, LightDM is *still* Ubuntu's dm of choice (and working great, if you ask me). But more importantly, the main reason for GDM to start a full session is profoundly flawed. In fact, the idea that power management and accessibility belong to the user's session is flawed. And funnily, it's Mathew himself that gives the reason:

> Closing the lid of my laptop should suspend the system regardless of whether it's logged in or not.

Absolutely. That's why power policy should *never* be related to the user's desktop session.

A bit of off-topic

Posted Feb 3, 2015 15:55 UTC (Tue) by raven667 (subscriber, #5198) [Link]

I agree this is off topic but power management does interact with the console and requires communication with whatever is driving the console output, power management changes depending on whether the keyboard is being used or a video is being played or other factors that the UI program knows about and there should be UI elements which allow the user present on the console to suspend or power off the device. There may be a backend daemon which coordinates these changes but they are driven by policy encoded with the console UI itself.

Once you need to have software running to interact with the console present user then you need a context to run that software in, having a user session dedicated to the login screen allows it to have the same protections as any user and make it less of a special case.

I dunno, makes sense to me anyway.