Will You Be Able To Run a Modern Desktop Environment In 2016 Without Systemd? 785
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?
Yeah (Score:5, Funny)
Zips up flame-proof suit. Dons shaded goggles.
Re: (Score:2, Informative)
Or OS X.
Or OS/2.
Or Haiku.
Or MS-DOS.
Or FreeDOS.
Re: (Score:3)
Interesting list of alternative OSes, including some I'd never heard of.
http://www.howtogeek.com/19021... [howtogeek.com]
Re: (Score:2, Informative)
Or FreeBSD.
Or OpenBSD.
Or NetBSD.
Lumina (Score:2)
I use & like Lumina, but they recently made some changes to their user interface. The pull down menu for exiting was at the top right, and they suddenly shifted it to the top left. They need to realize that a consistent look & feel across versions is important. It's not that I can't go to the top left - it's just that after a habit is formed, to have to change it in a new version is disruptive.
I would like PC-BSD to own the Wayland implementation of FreeBSD, since the latter seems to be more
Re: (Score:3)
Or one of the many BSDs. Linux users will probably feel most at home with one of those.
Modern DE (Score:3)
Or one of the many BSDs.
That's going to be tricky.
The key point is that the poster wanted a *modern desktop environment*.
So probably Gnome 3, KDE Plasma 5, Unity 8, or whatever the newer versions that are going to show up in 2016.
And most of these desktop try not to reinvent the wheel, but re-use the building blocks that systemd (I mean not only PID1, but all the various other tools that are hosted under the same umbrella) provides.
(e.g.: Cgroups handling, automatic on-the-go creation of isolation silos, hardware management, etc.)
Re: (Score:3)
It is a desktop OS, although made by a company that doesn't sell or want you to run a traditional desktop computer. You know, those with cards, hard drives and memory DIMMs.
Silly me though, I should order the Macbook with the maximum memory configuration, use a monitor on USB, sound over bluetooth and the hard drive over wifi :-). That will be $2000 well spent to replace outmoded wires and local storage.
Re:Yeah (Score:5, Informative)
svchost.exe isn't analogous to systemd.
scm.exe is the windows equivalent to systemd. The Service Control Manager (scm.exe) is a process that starts during the boot sequence, shortly before control is handed off to the login and desktop manager process (lsass.exe). Windows' boot process goes from loader (ntldr) to kernel (ntoskrnl) to session manager (smss) to service control manager (scm) to Winlogon. Everything you interact with in Windows is hosted by the Winlogon process. The only exception to this is the services.msc control panel snap-in, which allows you to very indirectly poke at scm.exe.
svchost.exe is a wrapper host that handles service events for applications that don't behave like services. All Windows services must respond in a timely fashion to requests to start, stop, restart, pause, continue, and a few other events. If a process doesn't handle these, they can still be run as a service by running them inside the Service Host process.
Yes! (Score:2, Informative)
OS X
Re: (Score:2)
Re:Yes! (Score:5, Informative)
Re:Yes! (Score:5, Funny)
what exactly is OS X missing?
The troll's righteous indignation?
Re:Coren22's "APKolypse"... apk (Score:5, Insightful)
Mr. Steven Burn of Malwarebytes
Speaking of Mr. Steven Burn of Malwarebytes, he also said this in that same thread:
Thanks for letting me know. I'll have a word with him.
That's in regard to you spamming Slashdot comments, and he posted that in February. How did that conversation go? Because in this story from yesterday [slashdot.org], you posted this exact text [slashdot.org] 9 different times in those comments, and since it's the end of the day before a holiday and no one is getting anything done anyway, I went ahead and found no less than 39 comments from you in that one story alone. There are only 101 comments total, 39 of them are yours, and 9 of those are that same wall of text advertising your software. That is the very definition of spam. You also posted this text [slashdot.org], the one referencing Steven Burn, 4 different times in that comment thread. You are spamming a Slashdot comment thread with a link to a guy saying that he's going to talk to you about spamming Slashdot comment threads. What's going on here? Why is it necessary to go into the comments for certain stories and see tens of posts by you with either the exact same text or you arguing with other people about spamming? Why do we have to endure that on Slashdot? More importantly, do you think that makes you look good? Do you think it makes people want to try your software? What's the point? Why isn't it enough to post a single ad for your software, even though that would still be considered spam? Why do you need to do it 9 times? Can you give it a rest for the sake of everyone else?
Re:Yes! (Score:4, Insightful)
The ability to legally install it on any hardware I want.
Re: (Score:3)
what exactly is OS X missing?
The latest OpenGL and support for the latest GPU hardware. They also want to switch to a proprietary GL instead of Vulcan.
Re: (Score:3, Insightful)
Running on hardware of my choice?
My 2011 MBP is great, but I'm not looking forward to the day I have to replace it.
Re: (Score:3)
Lets see... POSIX compliant, bash shell, GNU tools, X Window.... what exactly is OS X missing?
It's missing Native XWindows for one. I can't use FVWM to manage the native OSX windows and that sucks---not to mention missing native remote windowing for individual applications. Oh and it has kinda cruddy performance too. Compared to Linux, the kernel, file systems etc just are a bit old and slow. Oh it's also missing a good package manager! Yeah, I've tried the various ones over the years. A good apt (or amazin
Re:Yes! (Score:4, Informative)
I switched to a Mac in 2012 for my personal shit and about 6 months ago went to a Mac for work too. With the release of Office 2016 for the Mac, I honestly cannot find a single thing I cannot do comfortably on my Mac anymore.
If you have a serious problem with it, Parallels has been running Windows apps for me better than any native PC installation since version 7 back in 2012.
I mean, I know you're probably trolling or trying to be funny, but it's a dead joke in 2015.
Re:Yes! (Score:4, Interesting)
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.
Re: (Score:3)
I don't know why this got +5 insightfull. ...
What is undecent at Mac OS X file system? You know you can pick between various FS?
What is undecent in memory management? I don't see a difference to any othe Unix.
What is undecent regarding networking? Macs use TCP/IP like any other computer
Are you a moron or is it just the guy who modded you up?
If we're going systemd, we should go full throttle (Score:5, Interesting)
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.
Correction (Score:4, Insightful)
That was a very nice post and all, but I really lost focus after reading "Do or don't do" instead of "do or do not".
Re: (Score:3)
I don't do much init-fiddling although I do like the text based init/runlevel thing,
It's pretty clear that if KDE depends on one particular init system, that systemd is no longer just an init system.
Re:If we're going systemd, we should go full throt (Score:4, Informative)
Re:If we're going systemd, we should go full throt (Score:5, Funny)
As we've all learned from Apple: No half-assed shit. Do or don't do.
I believe that was taught by Yoda, not Apple.
Re:If we're going systemd, we should go full throt (Score:4, Interesting)
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.
Re:If we're going systemd, we should go full throt (Score:5, Interesting)
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.
Re: (Score:3, Insightful)
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
And we also have decades of experience with Linux no-culture. It failed to gain more than 1% of the total market. Perhaps it's time to try something else?
Modern X11 Desktop Environments don't need Linux (Score:2)
My oldie-but-goodie Slackware Linux is still staying away from systemd, so I'm glad abou
OpenRC forever! (Score:2)
Re: (Score:3)
Die Systemd! I prefer my log files in text format.
The problem isn't binary logging. Some people prefer that, it's ok, they should be able to have binary logs on their system.
The problem is we already have a system for that.....syslogd. Instead of completely redoing the way logging works, if they wanted binary logging, then they could make small modifications to syslogd, and then everyone is happy. Switching between binary logs and text logs would be simple.
Instead, they made a completely new haphazard interface, trying obsolete the system that was alre
Re:OpenRC forever! (Score:5, Informative)
All systemd logging can be forwarded to syslog in plain text format, standard feature enabled by a single edit in: /etc/systemd/journald.conf
It can also be enabled on a per boot basis with a simple addition to the kernel boot parameters
ForwardToSyslog=, ForwardToKMsg=, ForwardToConsole=, ForwardToWall=
Control whether log messages received by the journal daemon shall
be forwarded to a traditional syslog daemon, to the kernel log
buffer (kmsg), to the system console, or sent as wall messages to
all logged-in users. These options take boolean arguments. If
forwarding to syslog is enabled but nothing reads messages from the
socket, forwarding to syslog has no effect. By default, only
forwarding to wall is enabled. These settings may be overridden at
boot time with the kernel command line options
"systemd.journald.forward_to_syslog=",
"systemd.journald.forward_to_kmsg=",
"systemd.journald.forward_to_console=", and
"systemd.journald.forward_to_wall=". When forwarding to the
console, the TTY to log to can be changed with TTYPath=, described
below.
Re:OpenRC forever! (Score:4, Interesting)
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.
Re:OpenRC forever! (Score:5, Informative)
I don't understand this. If systemd is so backwards compatible with the traditional way of doing stuff, why don't distros enable that?
Erm, some do. Debian forwards everything to syslog and throws away the journal by default.
antiX-Linux and MX-Linux (Score:2)
Take a look at antiX Linux [distrowatch.com] and MX Linux [mepiscommunity.org]. They are both modern distros with fairly modern desktops and they don't use systemd.
Feel Free (Score:2)
KDE is a modern desktop? (Score:3, Insightful)
Salomonic solution (Score:2, Interesting)
Keep systemd, kick out Poettering.
2016 the year of FreeBSD? (Score:2)
????
Without Systemd Wiki (Score:5, Informative)
Without Systemd Wiki: http://without-systemd.org/wik... [without-systemd.org]
Systemd "Spec" or RFC? (Score:4, Interesting)
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.
Much todo about zip--ConsoleKit2 is also supported (Score:5, Informative)
Sigh.
First, only an idiot would want a monoculture, particularly in the Linux world, so to those saying "just to systemd full bore or go to (someplace else)" the rest of us need to respond with a very loud and resounding: Fuck You.
That said, things aren't nearly as dire as this post implies. Reading from the responses to the bug [kde.org] he himself linked to, I find the following:
> Unless KDE is prepared to make a statement that it depends on systemd
of course not. Powerdevil recently also gained support for ConsoleKit2, see: http://commits.kde.org/powerde... [kde.org]
Which turns it into a distro problem. Your distribution configured the system in a way that suspend/hibernate is broken. It doesn't come with any of the supported solutions Plasma provides. Which makes it a distro problem. The distro integrates various parts of the software stack. This includes it's the distro's task to ensure that components work together. It failed here by ripping out systemd and replace it with well nothing.
So while I'm sure the systemd zealots would love to see KDE, Gnome3, etc. only work with systemd and drop support for all other distros, this doesn't appear to be happening. In the case of KDE, ConsoleKit2 is supported (and therefor Funtoo, Gentoo, Arch with OpenRC, etc. will continue to work just fine).
what should ConsoleKit2, the stop gap, do? (Score:5, Interesting)
Wrong way around (Score:5, Insightful)
The systemd team didn't create those dependencies, the DE maintainers did. All of these DEs ran just fine without systemd and they still could if someone was interested in doing so. In fact given the maturity of the old interfaces, and the code already existing in previous releases it should be much easier to maintain say, KDE or Gnome, without systemd that it is for the team trying to add it in. There is nothing stopping people from forking the existing code and running their own project, we have seen this happen in the open-source world dozens of times. If there is a lot of demand for systemd less distros, the community will make them.
The question isn't "Will You Be Able To Run a Modern Desktop Environment In 2016 Without Systemd?". The question is "Where are all the systemd-free projects?".
Linus said talk is cheap show me the code. So where is it? For all the complaining, flamewars, and cries of fleeing to *BSD you would expect systemd-free projects to be springing up left and right. So where are they? If Red Hat is making such a huge mistake switching to systemd, then surely their competitors at SUSE, Cannonical, and Mandriva will capitalize on that mistake in the name of profits no? It isn't surprising that seemingly everyone is adopting systemd. systemd is solving problems and implementing feature that people want. That is easy to explain.
What is remarkable here is the massive disconnect between the amount of outcry about systemd and the amount of code being written to avoid it.
Re: (Score:3)
The systemd team didn't create those dependencies, the DE maintainers did. All of these DEs ran just fine without systemd and they still could if someone was interested in doing so.
The systemd developers have been active in the DE mailing lists, encouraging them to make systemd a dependency. See here for an example [gnome.org].
Re: (Score:3)
Re: (Score:3)
The problem with systemd isn't the features it tries to provide, the features are good. The problem is the architecture of the software is really bad. There is absolutely no reason KDE should depend on a particular init system.
Fork it then (Score:3)
Torvalds on systemd: (Score:4, Interesting)
No systemd on Slackware (Score:5, Informative)
A question about the BSD's. (Score:3)
How hardware friendly are they?
The only thing keeping me on linux is the thought of going back to the days of having to check if hardware worked before buying it ( plus all the hardware I have now ).
It depends on somebody doing the actual work (Score:3, Insightful)
The problem the non-systemd distros are facing with running a modern desktop are entirely their own fault. Gnome and KDE developers pleaded for years that non-systemd distros or anybody else should start to maintain ConsoleKit which now have been abandonware for almost 4 years.
The non-systemd distros ought to realize that it is entirely up to them to maintain their own alternative software stack, and even help out upstreams projects like KDE to support them.
At the moment only a single guy is maintaining CK2 and sending patches to KDE so KDE will work with CK2.
People whine about "Linux is all about choice", but when it comes to maintain those choices they all shy away with a "I am not a programmer", "No time", "No money" etc.
So if you want to run a modern desktop in 2016 on a non-systemd distro, you better start contributing towards it.
The same thing goes for OS containers, the new cgroups API and what not. If you want that stuff, don't expect it to magically being made by benevolent pixies nor developers from systemd-distros.
Re: (Score:3, Insightful)
"If you want that stuff"
Funny thing is the question is not about getting new stuff, that stuff. Just keeping running what is there up. But what is there is removed because it is easier to have done by systemd people, which in turn are quite happy to be able to remodel everything according to their feeling.
And now, according to you, people should devote time or money not even to implement new stuff, but to write a systemd alternative that would do everything systemd does, in a similar and compatible way (bec
Re: (Score:2)
> Post the issue to your distribution not the systemd group.
It's a problem with almost every distro, right? Like what doesn't have systemd, slack?
Re: (Score:2)
> Post the issue to your distribution not the systemd group.
It's a problem with almost every distro, right? Like what doesn't have systemd, slack?
Yes, Slackware does not have systemd. And, as far as I know, has no plans to integrate it in the future (which is one of the reasons I love it).
On the other hand, OpenBSD systemd "shim" looks better every day, as it allows Gnome to work without systemd. Make of that what you will.
Re:Duh (Score:5, Insightful)
I keep saying it, systemd not an init system. KDE and GNOME should not depend on an init system. Why does the desktop care who's booted it up?
More specifically, systemd is Linux-only. The devs have explicitly stated that they are making good use of Linux-specific features. Fine, but if third party software becomes dependent on it then that implies they won't work on *BSD at all. Right? So now there's no Gnome or KDE on anything but Linux.
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.
Re:Duh (Score:5, Informative)
So now there's no Gnome or KDE on anything but Linux.
That is Lennart's plan. Here's what he says: [gnome.org]:
"I think we need to ask ourselves the question if we do ourselves any good if we continue to support all kinds of kernels that simply cannot keep up with Linux anymore."
Re: (Score:2)
I just uninstalled GNOME 3.16 from my system due to its systemd dependencies: it is too slow in loading in PC-BSD. However, KDE is usable, if resource heavy.
But I do think that PC-BSD should have a plan on Wayland.
Re: (Score:3)
Do you know what you're posting about?
I use both freebsd, and linux, and IMO, freebsd is superior in many ways.
Although, Linux works with more hardware.
Re:Duh (Score:5, Insightful)
its because systemd provides features that are normally root only, and delegates them through dbus and a permission system through to logged in users. This lets the desktop environments have more advanced features then they would with init systems that don't do this delegation. If they were to support all inits, they would have to reimplement a lot of the parts of systemd. They used to do just that. They have both decided to stop doing that and just let systemd do it. GNOME/KDE are doing the right thing IMHO.
If the other init systems want to gain support, they have to support this same kind of functionality somehow.
Re:Duh (Score:4, Insightful)
This lets the desktop environments have more advanced features then they would with init systems that don't do this delegation.
An init system shouldn't be doing that stuff. You know how sometimes people complain that "systemd is monolithic [0pointer.de]?" That is what they are talking about: you can't get that stuff separately from your init system.
Re: (Score:2, Insightful)
Re: (Score:3)
So why can't there be other systems that do the various parts that aren't init but systemd is doing?
There were until recently, apparently. Powerdevil and pm-utils. Apparently KDE preferred the systemd way, for whatever reason.
Re: (Score:3, Interesting)
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-syste
Re: (Score:3)
I had a quick look at the ConsoleKit2's git repo. I guess by "years" you mean 5 months.
Re:Duh (Score:4, Interesting)
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.
Re: (Score:3)
> Because the whiners don't have a use-case. systemd is modular, but it tends to come with all the modules packaged together
I'm afraid it's not. The dependencies among components are very strong, and it's quite difficult to segregate out one component for de-activation or non-installation unless you compile with that feature de-activated, in which case you must recompile to re-enable the future. It's very difficult to install only the components you want due to the interdependencies.
Re: (Score:3)
> Yes, it is too hard for the actual whiners we have, but it would be easy, beyond simply "trivial," for any Jr Sysadmin or even a Jr Software Developer if they've ever used make
I'm afraid that's not true. Take a look at the Fedora work going on right now to try to segregate systemd components, described at http://news.softpedia.com/news... [softpedia.com] .These are components that should never have been integrated into an over sized and aggressive systemd in the first place. I've taken a few stabs at segregating syste
David Edmundson answers your questions (Score:5, Interesting)
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 [davidedmundson.co.uk]
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.
Re: (Score:3)
SystemD is a collection of small pieces of software. Together it makes a big system but you probably haven't paid any attention to it.
Not this argument again.
It doesn't matter how many pieces something is if the pieces are more or less inseparable. There's a reason all of those things are developed under the "systemd" banner. If you decide that you absolutely must have systemd without the crap you don't want, your only option is to configure and compile it yourself. If that's "modular" or "not monolithic", then I guess Windows is too.
If it were truly not monolithic, then I'd be able to install systemd's non-init stuff on a sysvinit syst
Re: (Score:3)
> That is a good thing to keep in mind, since nobody is running systemd except by choice.
I'm afraid that's nonsense. systemd has been a penalty in work I do. If I could have more contemporary versions of Linux based daemsns and packages without systemd, such as entire LAMP stacks, I'd accept them in a moment. Debugging failed daemon startups with systemd has repeatedly proven painful, due to the binary log formats and the difficulty of deducing the actual daemon startup commands to run them in a debugger
Re:Duh (Score:5, Interesting)
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.
Re: (Score:3)
Correct. Systemd is not about a modern init system. There are tons of modern init systems being worked out now.
Systemd is pretty clearly an init system. It's just that if you don't use that system, you can't use a lot of other stuff.
The kernel is much more complex than an init system, and we've mostly figured out how to swap that out without difficulty. Swapping out an init system should be relatively simple in comparison.
Re:Duh (Score:5, Funny)
The kernel is much more complex than an init system
For now, it is. Just give the Systemd team a little more time, and that may change.
Re: (Score:3)
Bullshit. It merely required systemd to play nice and use similar interfaces to the perfectly-good existing software it's trying to replace!
Re: (Score:3)
kde or gnome as they are desktop environments not window managers.
What difference does that make to the current discussion? I'll happily concede that point if you stay on topic. Neither KDE nor Gnome should depend on a particular init system.
Re: (Score:2)
A Window Manager doesn't mess with power management, or sound, or input devices, or screen resolutions, or... it just manages windows. Once you want to start dealing with all that other stuff mandatory to a modern desktop environment, then you're way beyond "window manager". Or does the relatively miniscule window manager component of KDE or Gnome depend on systemd? I'll admit ignorance on that.
Re: (Score:3)
Re:Duh (Score:4, Interesting)
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.
Re: (Score:2)
If any other init system + provided the features necessary for the modern desktop environments, then I'm sure they would not hesitate to support it
The init system should not be providing those features. That is entirely the problem.
and no one other then systemd has bothered to create a viable solution to the destkop environments problems.
What was wrong with Powerdevil and pm-utils?
Re: (Score:3, Insightful)
The system was flexible, allowed for easy replacement and customization at every step. Only downside? Beyond basic use, you had to touch the config by hand. Now this option simply doesn't exist anymore, and a lot of people believe that whatever systemd does now, it's the only way and
Re:Duh (Score:5, Interesting)
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?
Re:Duh (Score:5, Insightful)
As I understand it, as someone who could care less one way or the other, systemd isn't a solution for end-users, which is why you don't see any substantial changes. Its a solution for *developers*, freeing them from having to deal with the mountain of hacks, kludges, and assorted ugliness necessary to provide modern desktop-environment features through the decades of cruft and "ideologically pure" compartmentalization provided by the lower levels of Linux.
It doesn't offer new functionality - it just removes a maintenance nightmare for Desktop Environment developers, allowing them to focus on actually working on a good DE, rather than all the ugly backend stuff behind the scenes. The big issue, aside from ideological purity, is that in systemd massively redesigning that backend stuff there was inevitably a lot of lost functionality - you can't replicate the functionality of decades of accumulated cruft overnight. And major DEs don't want to wait until there's complete functional parity to adopt it, for a couple big reasons (and probably many more I haven't thought of):
1) Waste: if they plan to adopt the project eventually, then the longer they wait, the more wasted work they do maintaining deprecated systems.
2) Momentum: you want to adopt a project when it's both "good enough" and has a thriving developer community in order to help maintain its momentum. A project no one uses is eventually going to start shedding developers, and may never reach functional parity at all (see GNU Hurd, etc.)
Re: (Score:3)
Re:Duh (Score:4, Interesting)
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.
Re: (Score:3)
You make good arguments and if I could, I'd mod you up even though I don't agree with you. One of the reasons that linux has been popular as a server OS is that you could easily distill it down to just the parts you needed. If you didn't like a particular component you could swap it out with a component more to your liking or even write a replacement. From a security standpoint, you were presenting a smaller attack surface by running a small number of heterogeneous components from different sources. Fro
Re:Duh (Score:4, Informative)
If you're allergic to trimming your neckbeard and running a modern init, just switch to *BSD where they adopted the features that people are whining about decades ago. ;)
Haters hate, but do they know why? Do they have a choice? Do they have Free Will, or were they born unable to tell the difference between choosing software they want to run, and being forced to run software that... they chose?
Let's run down the list of "why":
- Systemd contains an unchecked null reference pointer that segfaults PID 1.
Lennart Poettering states he won't fix it
https://bugs.freedesktop.org/s... [freedesktop.org]
- Systemd and Gnome allow bypassing gnome-shell password prompts granting root
Left unfixed for over a year
http://www.phoronix.com/scan.p... [phoronix.com]
- Systemd segfaults during upgrades of itself, combined with the new log files that can't be retrieved Mr Poettering says are required to fix the bug, but he will not provide any method for Systemd to generate the logs he demands from it.
https://bugzilla.opensuse.org/... [opensuse.org]
https://utcc.utoronto.ca/~cks/... [utoronto.ca]
- Systemd distros can not boot if no ethernet link is present
https://lists.debian.org/debia... [debian.org]
- Systemd distros can not boot if using certain DNS servers
https://bugs.debian.org/cgi-bi... [debian.org]
- Systemd distros can not boot if using certain NTP servers
https://github.com/systemd/sys... [github.com]
- Enabling the kernel "debug" command line option results in boot storage being filled with thousands of dmesg log entries per second from Systemd, and a non-booting system results
https://bugs.freedesktop.org/s... [freedesktop.org]
- Systemd disables SysRq keys to ensure data loss after any of the many many instances it is coded to fail under
https://lists.debian.org/debia... [debian.org]
Re:The cabal has won. (Score:4, Interesting)
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.
Re:yes (Score:5, Funny)
Shhhh, don't let Stallman hear you say that! Now repeat after me, Linux is just the kernel; GNU is the OS, Linux is just the kernel; GNU is the OS :)
FSF choices (Score:5, Funny)
Re:FSF choices (Score:5, Funny)
Speaking of which, if one can figure out a way to install emacs on systemd, one has the perfect system - no need to worry about linux vs bsd if all emacs needs to use are services provided by systemd
You'd still need to additionally install a text editor.
Re:FSF choices (Score:5, Funny)
Wait a week, I'm sure some of the systemd authors are working one now. It will only save its data in incompatible binary modes, will fracture the kernel on a regular basis, and will replace every file you edit with a symlink to /tmpfiles.d/. But hey, it least it will start fiast!
Re: (Score:3)
Re:yes (Score:5, Informative)
Re: (Score:2)
Re: (Score:3)
Systemd is not (supposed to be) part of the desktop environment either, it's supposed to manage starting system daemons like sshd, httpd, dhcp, networking services, access to your keyboard, graphics management, and many other things that a system daemon starting utility has no business being involved in. The problem is that a large number of current required services are no longer properly maintaining their "non systemd" startup config and code, and are instead relying on the half-baked garbage that is systemd. Anyone who disagrees with the switch to systemd is then countered with social pressure and "get with the modern world, loser!" type arguments, rather than actual technical reasons, since for the most part, there aren't any. (Cue systemd fans giving reasons like "if it wasn't good, then nobody would be using it! Everyone else is doing it, get with the modern world loser!" now...)
The reason why they're switching is usually due to logind, or at least, I believe it is for KDE. When PolicyKit was abandoned, there wasn't really a modern and secure way to handle logins, so for a while they stuck with the old solution. Logind is actively maintained, hence their desire to use it as opposed to PolicyKit. That being said, since logind is really just an interface for which systemd is currently the major implementation, it shouldn't be tied to just systemd; you should be able to write a shim t
Re: (Score:2)
Guess who wrote pulseaudio? Hint: initials are LP
Re: (Score:3)
The problem with going to LFS is that it's a huge amount of work to maintain it. I ran an LFS based laptop for a few years and even wrote my own package manager to help maintain a level of sanity. LFS is an excellent learning experience and can be a great hobby but, sometimes you just want to type, "sudo apt-get install" instead of spending an afternoon building a tool.
Re: (Score:3, Insightful)
This is cut and pasted from another comment as I do not want to retype. Init is serial and has trouble adapting to changes once a live system is up compared to more modern systems. Solaris, Ubuntu, and Apple all left init behind and NetBSD discourages writting init scripts by using a hybrid approach with macros that are event driven that you link instead.
My cut ....
The reason is init was not designed for desktops or servers with more than a dozen applications. What if your laptop goes to sleep and wakes up