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?
Just use Windows.
Zips up flame-proof suit. Dons shaded goggles.
OS X
I am Slashdot. Are you Slashdot as well?
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
They don't. If you don't like the way Linux distros are evolving, then try out another OS that uses X11. Who knows, maybe a push towards FreeBSD will help speed up support for more hardware there. There's of course some certain apps (GParted for example) or limited features in a Desktop Environment that depend solely on Linux, but I find that to be generally rare, especially when looking at what FreeBSD Ports supports.
My oldie-but-goodie Slackware Linux is still staying away from systemd, so I'm glad about that.
Die Systemd! I prefer my log files in text format.
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.
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."
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".
"There is more worth loving than we have strength to love." - Brian Jay Stanley
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.
"First they came for the slanderers and i said nothing."
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.
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.
"First they came for the slanderers and i said nothing."
It makes sense that KDE would like systemd. They both are bloated and do far more than they need to.
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...
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 :)
So now there's no Gnome or KDE on anything but Linux.
That is Lennart's plan. Here's what he says::
"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."
"First they came for the slanderers and i said nothing."
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.
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.
"First they came for the slanderers and i said nothing."
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?
Without Systemd Wiki: http://without-systemd.org/wik...
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.
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 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...
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).
The Future of Human Evolution: Autonomy
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?" That is what they are talking about: you can't get that stuff separately from your init system.
"First they came for the slanderers and i said nothing."
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...)
Again, the point under discussion is neither KDE nor Gnome should depend on a particular init system.
"First they came for the slanderers and i said nothing."
The questioner has it the wrong way around.
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.
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
Systemd never was, and never will be, just an init system. The init system is just a small part of systemd. The init system isn't the part the desktops are depending on. It's the interfaces to other subsystems the desktops are depending on, such as the power management interface and the hotplug interface.
This is your sig. There are thousands more, but this one is yours.
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.
"First they came for the slanderers and i said nothing."
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.)
--- Most topics have many sides worth arguing, allow me to take one opposite you.
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.
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
If someone doesn't want their modern desktop to run with modern underpinnings they should fork it. I'm sure KDE wouldn't mind - in fact they might welcome it since it simplifies their code base. They can make systemd a core dependency on Linux, remove heaps of cruft and refer the objectors in the direction of the fork.
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.
This would be acceptable.
In fact, start over from scratch without Poettering.
I understand there are some legitimate needs for a "modern" desktop that systemd is attempting to fill. I've also heard that it will allow Linux to run on devices like phones and tablets with far fewer headaches.
But yes, kick out Poettering, and give me something designed and written by competent developers.
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.
Go on, citizen, stamp the vote card. R or D, your choice.
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...
- Systemd and Gnome allow bypassing gnome-shell password prompts granting root
Left unfixed for over a year
http://www.phoronix.com/scan.p...
- 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/...
https://utcc.utoronto.ca/~cks/...
- Systemd distros can not boot if no ethernet link is present
https://lists.debian.org/debia...
- Systemd distros can not boot if using certain DNS servers
https://bugs.debian.org/cgi-bi...
- Systemd distros can not boot if using certain NTP servers
https://github.com/systemd/sys...
- 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...
- 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...
Mod this guy up. Finally, somebody who knows what they're talking about.
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 think you missed the simple fact that everything was working fine before, without cramming everything in the init process. Power management, in this case, existed before systemd came, and everyone was using that just fine.
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 that without them nothing would work.
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.
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, you posted this exact text 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, 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?
"Our two-party system is like a bowl of shit looking at itself in a mirror." - Lewis Black
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.
> 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.
> 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.
Slackware runs KDE or xfce and stays up to date. They are working on a new release, no systemd in sight.
In the USA, we like stuff watered down, like beer, television, and freedom.
> 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... .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 systemd components myself, and it's a very large octopus of dependent code.
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. From a maintainability standpoint you could easily read and understand the impact that updates might have. Sure, there were kludges and hacks and, if you wanted to argue that X-Windows is the most prolific kludge in the history of computing, I probably wouldn't argue with you.
The small, modular, "do what I want" nature of linux is basically the thing that makes linux, linux. If you wanted an opaque box that included everything but the kitchen sink, you could just use Windows. And that's what people hate about systemd: It's starting a trend to make linux more Windows-like and that is rightfully seen as a horrible direction to take things.
You might argue that I'm making an ideological argument but, linux has gained its popularity from sysadmins; not from developers or desktop users. Sysadmins value stability, simplicity and the ability to understand the system they are running. Systemd effectively removes all those features from the OS. Yes, it might make it easier for desktop environment developers to implement certain features but, the number of people that use linux as a desktop environment is laughably small compared to the number of servers running linux. So, basically, systemd is undermining the primary use-case of linux to appeal to an unlikely to ever grow user base (desktop users). Which is made even more bizarre in that it's primary developed by Red Hat: Practically the champion of linux as a mainstream server OS.
Basically, linux users don't want the OS to become a giant opaque monstrosity that can be prodded and observed but never really understood (like Windows).
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 on a different network? How can init with 200 lines of if/fi scripts handle something liek this? WHat if your network goes down on your server? What if your web server is hacked? What if your Oracle RDMS takes a dive?
Writting every possible conceivable combination of events with nested if/fi statements is luducrious! An event driven system makes sense.
FYI Init is not a glorified autoexec.bat for starting up. Something needs to tell the kernel which daemons to start and which arguments to pass on. Those who say otherwise do not know what Init does or it's intended use.
So Apple went 1st and everyone but Linux followed.
http://saveie6.com/
Bullshit. It merely required systemd to play nice and use similar interfaces to the perfectly-good existing software it's trying to replace!
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
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 ).
Shower first.
Contribute to civilization: ari.aynrand.org/donate
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.
I use Linux because I am free to use it the way I want and it is trusted because source is available.
I expect DRM will get wedged into systemd so you can't avoid Big Brother.
Linux will then be a "Trusted OS" because proprietary DRM code will be running underneath everything we do.
You will not be able to stop it without breaking all the applications which play video, music, download files, etc.
I do not trust Hollywood to be in my system, watching my every move.
If everything is tied together in a binary it can't be avoided.
Go well
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.
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 that does it, and in fact, I believe that's exactly what Debian uses if you don't want the whole thing. Unlike GNOME, I think the KDE developers do care about portability, so I find it rather suprising they would want to depend on systemd, given their stance.
"Set a man a fire, he'll be warm for the rest of the night. Set a man afire, he'll be warm for the rest of his life."
Well I bothered to check your first bug, "Systemd contains an unchecked null reference pointer that segfaults PID 1"
Executive summary, systemd does not work on kernels without cgroups. Well duh.
Don't install it then, you have an ancient unsupported Linux kernel.
I stopped checking after that.
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.
I had a quick look at the ConsoleKit2's git repo. I guess by "years" you mean 5 months.
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?
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.
No. powerdevil uses upower to do that. upower now uses systemd. KDE has made no change whatsoever (that's why the KDE devs don't see this as a KDE bug).
Watch this Heartland Institute video
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.)
Linux is much more than plain old POSIX. It provides tons of really useful advanced features (containers, capabilities, etc.) that where'nt part of posix. Systemd (project umbrella) provides tons of tools to leverage these function, that where simply completely underused back at the era of "cobbled together convoluted shell scripts". These functionality are useful, and together with the level of automation that systemd provides, makes life of desktop environment maker much easier.
BSD is also much more than plain old POSIX. But it's *differently* more so (jails instead of containers, different API for capabilities, etc.)
Handling these OSes would require either tons of API-specific code and wrappers, next to the simple systemd-leveraging (i.e.: what TFA complain against)
or requires that BSD also progressively migrates toward some higher level tools the simplify the handling of these functionnailties (i.e.: the various systemd alternatives that some time pop out. But still nothing concrete as of yet).
So probably, in 2016:
- you could either use Linux with KDE/Gnome/etc. but have a hard dependency on at least a dozen of deamons handled by the systemd project.
- or you could use one of the niche Linux distro with a unusual very geeky desktop environment (e.g.: some obscure tiling windows manager, and emacs with tons of plugin as the default browser/email client/file manager)
- or you could use BSD but you'll get an oldish release of MATE / KDE sunset.
And only the first of the three above get the best hardware (and, e.g., suspend/resume) support, due to having the most paid developpers working on it.
But, probably around 2018:
- you could use BSD with their very own "systemB" (project that give the same kind of abstractions) with the latest Gnome 4, KDE Plasma 6, Unity 9 (now running on Wayland), etc.
- or you could one of the less mainstream Linux distribution that swaps the component of systemd project with component of alternatives giving the same advanced features.
- or actually hope that by then systemd will have been reviewed enough and cleaned. (One of my hopes, given how widespread it is going to be. On the other hand openssl *WAS* widespread when Heartbleed happened)
- or cheer for the OpenBSD guys as you follow them on a "Valhalla Rampage" blog about "LibreSyD" (like systemd, but with all the weird pieces of code removed).
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]