Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?
Get HideMyAss! VPN, PC Mag's Top 10 VPNs of 2016 for 55% off for a Limited Time ×
KDE Programming Linux

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?
This discussion has been archived. No new comments can be posted.

Will You Be Able To Run a Modern Desktop Environment In 2016 Without Systemd?

Comments Filter:
  • Yeah (Score:5, Funny)

    by Nemyst ( 1383049 ) on Wednesday November 25, 2015 @03:13PM (#51003493) Homepage
    Just use Windows.

    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.

      • Interesting list of alternative OSes, including some I'd never heard of. []

      • Re: (Score:2, Informative)

        by Anonymous Coward

        Or FreeBSD.
        Or OpenBSD.
        Or NetBSD.

      • by AmiMoJo ( 196126 )

        Or one of the many BSDs. Linux users will probably feel most at home with one of those.

        • 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.)

  • Yes! (Score:2, Informative)

    by OzPeter ( 195038 )

    OS X

    • There needs to be an FOSS version of either Quartz or if GNUSTEP dependent, Display Postscript before a systemd replacement can happen.
  • by Qbertino ( 265505 ) <> on Wednesday November 25, 2015 @03:22PM (#51003589)

    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)

      by SuperKendall ( 25149 ) on Wednesday November 25, 2015 @03:37PM (#51003721)

      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".

    • 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.

    • by nuckfuts ( 690967 ) on Wednesday November 25, 2015 @03:42PM (#51003785)

      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.

    • by SvnLyrBrto ( 62138 ) on Wednesday November 25, 2015 @03:59PM (#51003909)

      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.

    • by lkcl ( 517947 ) <> on Wednesday November 25, 2015 @06:34PM (#51004979) Homepage

      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's recompiled versions of critical dependencies (udevd and others) all of which have "--no-systemd" in the 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 Cyberax ( 705495 )

        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?

  • 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 abou
  • Die Systemd! I prefer my log files in text format.
    • 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)

      by CronoCloud ( 590650 ) <> on Wednesday November 25, 2015 @04:17PM (#51004065)

      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_console=", and
                            "systemd.journald.forward_to_wall=". When forwarding to the
                            console, the TTY to log to can be changed with TTYPath=, described

      • Re:OpenRC forever! (Score:4, Interesting)

        by Antique Geekmeister ( 740220 ) on Wednesday November 25, 2015 @06:57PM (#51005149)

        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.

  • Take a look at antiX Linux [] and MX Linux []. They are both modern distros with fairly modern desktops and they don't use systemd.

  • To fork or write your own desktop environment if you don't like it, that is the point of open source; not the ability to force other people to kowtow your arbitrary system choices.
  • by QuietLagoon ( 813062 ) on Wednesday November 25, 2015 @03:58PM (#51003899)
    It makes sense that KDE would like systemd. They both are bloated and do far more than they need to.
  • Keep systemd, kick out Poettering.

  • Without Systemd Wiki (Score:5, Informative)

    by dissy ( 172727 ) on Wednesday November 25, 2015 @04:08PM (#51003993)

    Without Systemd Wiki: []

  • by kervin ( 64171 ) on Wednesday November 25, 2015 @04:14PM (#51004029) Homepage

    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.

  • by FreeUser ( 11483 ) on Wednesday November 25, 2015 @04:20PM (#51004081)


    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: []

    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).

    • by yeupou ( 785585 ) on Wednesday November 25, 2015 @04:53PM (#51004371) Homepage
      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.
  • Wrong way around (Score:5, Insightful)

    by inhuman_4 ( 1294516 ) on Wednesday November 25, 2015 @04:29PM (#51004159)
    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.
    • 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 [].

      • Better explanation:

        sysvinit is widely considered awful by most distro maintainers.

        How do we know this? Well, because distro maintainers have been trying to get away from it for years. Even when everything was run from 'init' there have been multiple refactorings of /etc/*.d to try to produce a better start up environment.

        At some point, some distributions, notably Ubuntu, switched to an initd replacement called Upstart. Because they were desperate to get away from sysvinit. ChromeOS, possibly the most

        • I investigated in detail why Debian adopted systemd, and wrote about it here []. It largely agrees with your post, that people mostly want to get away from sysv init, and of course sysv init has been controversial since it was created, which is why BSD never used it.

          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.
  • by DrXym ( 126579 ) on Wednesday November 25, 2015 @04:53PM (#51004363)
    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.
  • Torvalds on systemd: (Score:4, Interesting)

    by Drunkulus ( 920976 ) on Wednesday November 25, 2015 @05:46PM (#51004723)
    Systemd is the reason Linus is now using FreeBSD at home.
  • by Your Anus ( 308149 ) on Wednesday November 25, 2015 @06:53PM (#51005111) Journal
    Slackware runs KDE or xfce and stays up to date. They are working on a new release, no systemd in sight.
  • by MouseTheLuckyDog ( 2752443 ) on Wednesday November 25, 2015 @07:48PM (#51005425)

    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 ).

  • by Peter H.S. ( 38077 ) on Wednesday November 25, 2015 @08:08PM (#51005555) Homepage

    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)

      by yeupou ( 785585 )

      "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

"All the people are so happy now, their heads are caving in. I'm glad they are a snowman with protective rubber skin" -- They Might Be Giants