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?
Or OS X.
Or OS/2.
Or Haiku.
Or MS-DOS.
Or FreeDOS.
OS X
I am Slashdot. Are you Slashdot as well?
Or FreeBSD.
Or OpenBSD.
Or NetBSD.
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."
Without Systemd Wiki: http://without-systemd.org/wik...
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.
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
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...)
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.
"First, only an idiot would want a monoculture, particularly in the Linux world..."
Like a monolithic kernel?
"So while I'm sure the systemd zealots..."
You are the only zealot. Everyone else who is actually a linux programmer and knows what systemd has to offer has already moved on.
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...
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.
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.
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.