Slashdot Mirror
Will You Be Able To Run a Modern Desktop Environment In 2016 Without Systemd?
New submitter yeupou writes: Early this year, David Edmundson from KDE, concluded that "In many cases [systemd] allows us to throw away large amounts of code whilst at the same time providing a better user experience. Adding it [systemd] as an optional extra defeats the main benefit". A perfectly sensible explanation. But, then, one might wonder to which point KDE would remain usable without systemd?
Recently, on one Devuan box, I noticed that KDE power management (Powerdevil) no longer supported suspend and hibernate. Since pm-utils was still there, for a while, I resorted to call pm-suspend directly, hoping it would get fixed at some point. But it did not. So I wrote a report myself. I was not expecting much. But neither was I expecting it to be immediately marked as RESOLVED and DOWNSTREAM, with a comment accusing the "Debian fork" I'm using to "ripe out" systemd without "coming with any of the supported solutions Plasma provides". I searched beforehand about the issue so I knew that the problem also occurred on some other Debian-based systems and that the bug seemed entirely tied to upower, an upstream software used by Powerdevil. So if anything, at least this bug should have been marked as UPSTREAM.
While no one dares (yet) to claim to write software only for systemd based operating system, it is obvious that it is now getting quite hard to get support otherwise. At the same time, bricks that worked for years without now just get ruined, since, as pointed out by Edmunson, adding systemd as "optional extra defeats its main benefit". So, is it likely that we'll still have in 2016 a modern desktop environment, without recent regressions, running without systemd?
Recently, on one Devuan box, I noticed that KDE power management (Powerdevil) no longer supported suspend and hibernate. Since pm-utils was still there, for a while, I resorted to call pm-suspend directly, hoping it would get fixed at some point. But it did not. So I wrote a report myself. I was not expecting much. But neither was I expecting it to be immediately marked as RESOLVED and DOWNSTREAM, with a comment accusing the "Debian fork" I'm using to "ripe out" systemd without "coming with any of the supported solutions Plasma provides". I searched beforehand about the issue so I knew that the problem also occurred on some other Debian-based systems and that the bug seemed entirely tied to upower, an upstream software used by Powerdevil. So if anything, at least this bug should have been marked as UPSTREAM.
While no one dares (yet) to claim to write software only for systemd based operating system, it is obvious that it is now getting quite hard to get support otherwise. At the same time, bricks that worked for years without now just get ruined, since, as pointed out by Edmunson, adding systemd as "optional extra defeats its main benefit". So, is it likely that we'll still have in 2016 a modern desktop environment, without recent regressions, running without systemd?
As we've all learned from Apple: No half-assed shit. Do or don't do. No place for inbetween stuff.
systemd has downsided but it also has upsides. We should stick with the upsides and patch the downsides until they're basically a non-issue.
I don't do much init-fiddling although I do like the text based init/runlevel thing, and I would guess that plug-and-play - one of systemd's strong areas - should be a userspace problem, but that's just me not really know what's going on in the init process.
However, since all major distros have moved to systemd it can't be that bad as some people make it out to be. I trust the debian and ubuntu crew to know what they are doing at init-level.
If as a result the Linux community grows closer together and focuses more on consistency I'm all for the move to systemd - even if that moves Linux away from the rest of the unixes due to loss of posix compliance. Seriously, who cares? It's mostly Linux left, right and center these days anyway. The BSD people will be fine with whatever they choose as init process, as usual, and no one gives a damn about other non-FOSS unixes anymore anyway. Unix basically is Linux these days.
But, as I said at the beginning: There is no use going systemd, but only kinda so-so. If the community get's behind systemd, it works and is/becomes usable and apps start relying on it being there - so what?
My 0.5 eurocents.
We suffer more in our imagination than in reality. - Seneca
I chose. I went back to windows. I use BSD as a linux replacement where linux was best at the job (being a router and fileserver). However, with systemd, linux makes for a poor desktop environment, so I went back to the second best one (which is now the best).
I have free will. I just decided not to switch to BSD.
I hope that the influx of users to windows doesn't harm linux's chance at the desktop, but users have free will and aren't forced to run any certain software. Also, by that measure, nobody is forced to improve video drivers for linux or port video games there. Which will not happen when more and more people choose windows.
But hey, haters gonna hate, and I don't care about linux's ecosystem anymore. Let it burn. Perhaps the flames will get hot enough to drive the evil out? I won't know, I'm pretty happy with windows 10 and once again relegating unix to the servers. Yes, I'm being serious. I could be satisfied if it stays this way forever.
is no longer the ancient monolithic beast you learned to love
Don't you mean "is becoming the monolithic beast we moved away from when we first wiped our Windows install"?
Modularity with a standard interface and substitutable glue - i.e. small tools which each do one job well, always with alternative implementations - were the hallmark of Unix. Now the alternatives are Lennart's software or clones of Lennart's software, and a BUG is something which doesn't work exactly like Lennart's software.
No, the reason for systemd isn't that it's better. systemd has been chosen for the same reason almost everyone votes Democrat or Republican, spending ages arguing over minor details but failing to see that there's no real choice at all: if you boil the frog slowly enough and distract them hard enough with shiny, people stop paying attention to what's going on.
Linux the kernel goes from strength to strength, but GNU/Linux the desktop operating system is over, and Linux servers are fast becoming Lennartix. Is this good? IDK, is the cathedral model of software development good? It worked for OS X. But it's not the same system at all.
If you're allergic to trimming your neckbeard and running a modern init,
There's no reason a Window Manager should depend on a particular init system. Doing so is a clear sign of bad software architecture.
"First they came for the slanderers and i said nothing."
I disagree on the "full-throttle" part. That's be fine on consumer desktops. But Linux is mostly about production servers. Yes, yes... I know... mainstream Linux on the desktop is "just around the corner" and all that. :)
I have no great love for sysV init scripts. Getting rid of them would break a few things in my world. But really, those things could probably stand a new look and update anyway. But my second-to-main issue with systemd is that it's just somewhat half-baked and obtuse. There's a lot of "don't look behind the curtain, just trust us that it'll work" to it. That'd be tolerable in a consumer OS, or even in a consumer-targeted Linux distort like Mint, but not in bloody RHEL and Debian!
My biggest gripe about systemd, though, is its counterpart in crime: journald. Binary log files are the work of the devil and journald needs to die in a fire. And no one... not even a couple of Red Hat engineers I've spoken with... has been able to give be a non-hackish, production-worthy, way of ripping journald out of the thing and replacing it with syslog.
Imagine all the people...
Keep systemd, kick out Poettering.
The problem is that it's *not* a modern init system. In fact, I'm not really sure how to describe systemd apart from, "An overreaching solution to a problem that never actually existed". I don't think there is a single thing I can do with a systemd enabled system that I couldn't do in a 2008 version of Ubuntu. So, apart from complexity and a variation of vendor lockin, what has the linux world gained by moving to systemd?
If this is going to be the case, then we need a Systemd specification or RFC maintained by a widely respected committee and multiple implementations should be available.
All of your questions are easily answered by reading the link provided at the top of the article:
http://blog.davidedmundson.co.uk/blog/systemd-and-plasma
Why does the desktop care who's booted it up?
The Init System "We don't care. It doesn't affect us."
logind Allows KDE to provide user-switching features.
Device Management Allows KDE to have access to your mouse and keyboard without root access and without random applications being able to sniff your keystrokes.
Inhibitor Locks Allows KDE to react to notifications like "the system is about to go down" and delay until a condition is met (example: delay a suspend until the lock screen is displayed and all your desktop windows are hidden behind the lock screen).
timedated and Friends Allows KDE to set time and date without root; allows KDE apps to be notified if time and date gets changed. (KDE currently runs a daemon just to watch for time and date changes, and they would like to get rid of this daemon and simplify their code.)
User Units If KDE takes advantage of the "units" in systemd, then when any part of KDE crashes or hangs, systemd will restart the misbehaving part.
that implies they won't work on *BSD at all. Right?
"Projects like [SystemBSD] bring the interfaces we need to BSD and as it gets more stable we should be able to start distributing features."
So really, choice is being taken away clear across the board. Either that or I'm missing something really big which implies systemd is not a strict dependency.
I encourage you to read the whole article and see what big things you are missing.
I don't know about you, but when I read that article I didn't think "Man those KDE guys are idiots, why would they want any of that." It all makes sense to me.
It's easier for me to believe that SystemD has some merit than to believe that all the Debian core developers are idiots, plus all the Ubuntu developers, and now all the KDE developers and for that matter the Gnome developers.
My biggest concerns with systemd are the monoculture of it all, so projects like UselessD and SystemBSD sound great to me. Force the SystemD guys to document and justify everything, and provide alternatives.
lf(1): it's like ls(1) but sorts filenames by extension, tersely
Yeah and no. As pointed out in the article, the culprit is upower. But upower is mandatory for KDE power management. So it does not really matter whether it is Powerdevil that requires systemd or upower. ConsoleKit2 recently gained support? Was ConsoleKit2 actually been packaged? Does upower supporting ConsoleKit2 been packaged? If not, user experience wise, that is not palatable. And moreover, what to expect from upower? Did they not purposefully removed pm-utils support, that worked until then, in favor of systemd? Why removing support for a working solution (pm-utils) and, later, much later, adding support for some ConsoleKit2? What is the exact plan of ConsoleKit2? Providing some systemd-like interface without being systemd? Is that what ConsoleKit2 offers that pm-utils could not? If so, wow long will it work, to attempt to write a parallel to systemd, in order to make sure that all the software that in the past worked without systemd can now work with the systemd alternative? Just as a reminder, ConsoleKit2 exists "because there isnâ(TM)t currently a standard for system actions like suspend/hibernate anymore. We use these features in Xfce and it would be nice to keep the session manager and power manager in sync (i.e. you inhibit something and the session manager doesnâ(TM)t see it). Obviously thereâ(TM)s systembsd in the works, so this is a stop gap until that matures (however long that may be). But Iâ(TM)ll happily continue to maintain and support ConsoleKit2 as long as someone finds it useful". https://erickoegel.wordpress.c... The acknowledged benefit of systemd, as pointed out by Edmunson (link in the article) was to drop code. If ConsoleKit2 and al needs to write code to compensate from all the dropped code, following systemd, that unlikely sustainable. The stop gap project won't do. And it is really the funny thing now with systemd: if you dont want it, you need to write everything that it does because all the anterior/historical parts, good or bad, are getting deprecated and removed. So in order not to use systemd, you need to clone it. Bonkers. Hence the question: will KDE be still usable in 2016 without systemd.
And they don't - one of the main complaints people have, unless I'm mistaken, is that systemd isn't just an init system, it also wraps up a whole lot of things into a "low level system manager". You can certainly complain against that on grounds of ideological purity - but that's a completely different conversation.
So we have something-that's-far-more-than-a-window-manager depending on something-that's--far-more-than-an-init-system. There's certainly arguments to be had about design decisions, but they can't be had if you insist on using irrelevant terminology.
--- Most topics have many sides worth arguing, allow me to take one opposite you.
I disagree on the "full-throttle" part. That's be fine on consumer desktops. But Linux is mostly about production servers. Yes, yes... I know... mainstream Linux on the desktop is "just around the corner" and all that. :)
The question here is: What's with serverhosts these days? They are either embeded/integrated or virtualised. No one screws around (literally) with hardware anymore - not in a time where soc pcs cost less than 10$ a pop. So there is no need to fumble with init on that level. I haven't touched init or even runlevels for just about 10 years now - and I do lots of server stuff.
These days im running all my services in VirtualBox and copy, booting and ditching entire VMs at my whim. Fiddling with init would be a waste of time.
If you have a stripped down serverconfig that you have to distribute and scale, I doubt systemd will seriously get in your way. Yes, you have to hook your init stuff somewhere and yes you'll have to read about how systemd does things at this level, but on a dedicated server that might aswell happen in userspace or somewhere late in systemd boot. I'm sure systemd offers hooks for quick late-boot custom fiddling of some sort.
Bottom line:
If finally all the Linux proggers get on the same page I'm all for it. If that page happes to be systemd, so be it. Simply the benefits of all getting behind systemd will move Linux forward faster than ever - that's my newest prediction anyway.
We suffer more in our imagination than in reality. - Seneca
So why can't there be other systems that do the various parts that aren't init but systemd is doing?
Because the whiners don't have a use-case. systemd is modular, but it tends to come with all the modules packaged together. They could simply move the non-init functionality (which is the parts that these other packages depend on) into their own package, and just install that. But I guess their fingers would get contaminated by re-packing those parts of the source?
If you read the link in the post you responded to, it explains most of this stuff. It is modular, but the people managing it are using all the modules, so the default distribution contains them all. But you can use just the parts you need, and replace the parts you don't. It just requires simple grunt-work to manage packages the way you want. Thousands of loud whiners, but none that actually have a reason to need a different set of the modules, or the ability to do a simple repackage.
The only reason that the distros don't repackage those parts to be separate is that there is no reason articulated to do so. Whiners just whine, but they don't say words that would have any chance of convincing professionals that they have a differing use-case. We understand they're unhappy, but they don't identify reasons that are technical and real, but rather their reasons are aesthetic and arbitrary. By arbitrary I mean, everything they're doing with their computer still works; all their software still works; all their use cases still work, but they're unhappy for entirely optional reasons. They're choosing to be unhappy, but there is nothing actually wrong. Which from an engineering perspective appears to be entirely "user error." They're using it wrong; if they want to be happy while they use it, they just need to smile more. It is not actually biting them, or making them cold, or eating their cheesy poofs.
Systemd is the reason Linus is now using FreeBSD at home.
I would say an important question is, did the morphing happen before or after widespread adoption? And as I recall it happened well before. In which case I would argue that the starting point is really fairly irrelevant, and the actual "crimes" are:
1) calling an OS abstraction layer an init system when it clearly is far more than that (that seems to be perpetrated primarily by the detractors)
2) allowing a single party to tightly control the abstraction layer (though it does seem that such large-scale projects do need some sort of a singular "choke point" in order to ensure widespread compatability)
3) the discarding of lots of low-level components with large fan communities.
4) Having an OSAL at all? Though frankly, I think it's long overdue - one of my greatest annoyances with Linux is that practically every piece of nontrivial software seems to need to include explicit support and custom binaries for every major distro branch it runs on. That's a huge drain on developer time and energy, and one of the main reasons I've never done much Linux programming. Contrast to Windows where, with some fairly modest self restraint you can create a single binary that will run on everything from Windows95 to Windows10, and even Linux via WINE.
Frankly (2) is the only one I see as a real problem, and I'm uncertain how big of a problem it actually is. After all systemd is still fairly modular, just incompatible with most of the pre-existing modules already out there. And the individual modules are mostly under the control of other groups. And it's still GPL, so if the systemd group proves excessively abusive of their power there's nothing stopping the downstream distros from forking the project, provided they're willing to re-adopt all the maintenance headaches they adopted systemd to escape.
--- Most topics have many sides worth arguing, allow me to take one opposite you.
If the community get's behind systemd, it works and is/becomes usable and apps start relying on it being there - so what?
by taking over and forcing out all other options, it becomes a monoculture. and that, as we know from decades of experience where monoculture OSes have created cartels and monopolies, is incredibly dangerous.
i dedicated three years of my life - without proper financial recognition - to breaking the NT Domains monopoly, saving companies world-wide billions of dollars in the process. it is also not very well-known that i dedicated another year reverse-engineering the Exchange 5.5 protocol.
this dedication gave people a choice: they could choose to remain on monoculture monopolistic insecure proprietary and expensive per-seat-licensed servers, or they could choose to move over to software libre on any number of POSIX-compliant OSes including HPUX, AIX, Solaris, BSDs and GNU/Linux OSes - the *exact* opposite of a monopolistic monoculture. they could also choose to move to any number of proprietary solutions from companies such as Tarantella, Honeywell, Network Appliances and many more - all companies who got together because i pioneered the reverse-engineering (and wasn't murdered for doing so) which forced Microsoft to start doing proper documentation, and to sponsor CIFS conferences.
now i am witnessing a process by which everyone in the GNU/Linux community, by working in a totally dedicated way in "their corner" that has to be respected precisely *because* it is so dedicated, yet as a whole *all* of us have gone "hmmm, i'm working in my corner, the global problem isn't my problem: i'm making local decisions, here, which make my life easy and i'm doing what i think is best", totally forgetting that the overall consequences are like a shoal of fish: EVERYBODY has "flipped" - all at once - and the direction is a dangerous one that no one person has any responsibility or control over, because we are *not* a company, we do *not* have a "Board of Directors who can give us orders that we are required to follow or be fired", we are a bazaar - a self-organised group of self-organised individuals with independent free will and highly-focussed responsibilities.
the "flip" is to a dangerous monoculture position with, as we are now witnessing, absolutely zero choice (bad choices are no choice at all) - which i've warned about well over a year ago, and was told, basically, to "fuck off". well... now we begin to see the consequences.
i am running fvwm2 - i have been for 20 years - and i am using angband.pl's recompiled versions of critical dependencies (udevd and others) all of which have "--no-systemd" in the configure.ac files. so i will not be concerned about trojans that attack vulnerabilities in systemd, exploiting the new features such as allowing the firewall to be disabled and much, much more. but you - all you who trust the systemd authors and the desktop environments that now operate exclusively on systemd? you should be concerned.
OS X upgrades are cost free.
My old 10.6.8 runs just fine, no idea why you think I need special care from apple to keep it running.
That is a typical 'windoof user bullshit' attitude.
Never saw any cross platform problems for programs running under X-Windows. And no idea why there should be any. You usually simply compile and link ... thats it.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
I'm sorry to say that this is a typical systemd advocate answer to a much larger problem.
Having to reboot your operating system to enable text based logging for a specific service, or for all services is not reasonable. Hand-editing the boot modules to change the next reboot is _extremely_ dangerous manual editing capable of fracturing your system, and the boot console is not available on many virtualized or remotely managed systems nor without jumping through extraordinary hoops.
Root login access, or sudo access, does not mean a developer or programmer has console access. And even if console access is available, many server class systems take quite long periods to go through hardware scanning and present only a few seconds to manually modify the boot options, and some remote management systems that nominally provide remote console access take so long to restart or reconnect after a reboot that the necessary boot options have passed by before they could be selected.
On top of this, frequently rebooting Linux systems triggers the counters on the partitions that trigger an fsck at boot time after a specific number of reboots. An unscheduled fsck on a larger storage system can make the reboot take _hours_, and can also require console access to accept or reject the fsck options. This can cause a system without console access to fail to reboot, even if the boot loader has been manually loaded, and take the system online until manual keyboad and console access can be scheduled.
There were until recently, apparently. Powerdevil and pm-utils. Apparently KDE preferred the systemd way, for whatever reason.
Probably because almost nobody is working on non-systemd distros. Their entire OS plumbing layer from ConsoleKit to power-management has been bit-rotting for years with the non-systemd distros totally ignoring the pleading from upstream projects.
It is hard for upstream projects to support the non-systemd distros when they ignore or outright refuse to do any work.
I think there is roughly one non-systemd developer (the CK2 maintainer) that submit patches to KDE so KDE can have basic functionality on non-systemd distros.
But sure, just blame systemd for the non-systemd distros total apathy for maintaining their own software.