Announcement

Collapse
No announcement yet.

Systemd Continues Getting Bigger, Almost At 550k Lines Of Code

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #91
    Originally posted by pingufunkybeat View Post
    This addresses a question I didn't ask, and addresses it badly.

    Why would a desktop application, like GIMP, care what the system daemon is doing? Why would Inkscape refuse to start if you run the "wrong" system daemon, or Gnumeric fail to compute if you are on a BSD?

    What sort of essential functionality is missing from them now, that must be added as a hard dependency tomorrow?
    Applications like the ones you mention don't and won't directly depend on systemd. But the DE as a whole has services that get started and need to continue running throughout the user session. KDE right now does this in their startkde script, but just like systemd replaces scripts during initial system bring-up, the KDE folks want to replace the startkde script with systemd --user. This will allow KDE to start faster and the services will be properly monitored to make sure they're running properly.

    Then there's system configuration GUIs, they make/want to make use of systemd services like timedated and localed. Until systemd, pretty much every distro stored this info (locale, timezone, etc) in their own distro-specific places, so system configuration GUIs need to be a mess of ifdef-erry, or are limited to a few distros. The systemd-blahd services allow simplification of these configuration GUIs.

    Further, there's logind. DEs also want that, because the session tracking logind provides interacts with polkit to give the user permission to do various stuff, like mount portable storage devices in the graphical file manager, shut down the system, etc.

    That's just off the top of my head, I'm sure there's more usage scenarios.

    Comment


    • #92
      Originally posted by pingufunkybeat View Post
      Can somebody explain to me why a desktop app should have a hard (!!!) dependency on a particular system daemon?

      Is there ANY technical reason for this?
      Its more because the desktop apps they are talking about (.app bundles like in OSX) are going to be fully 'virtualized' and sandboxed and they are going to put in an "Intents" system like in Android. Its a long read, but check out http://lwn.net/Articles/562138/

      Getting that in place requires a C-groups manager and a KDBUS frontend. Currently the ONLY (AFAIK) C-Groups manager and KDBUS frontend is the systemd project(s). So, until new, non-systemd, projects come along that handle those same jobs... you depend on systemd.


      Now, if you weren't following the train-of-thought that others were-- referring to "apps" being the apps discussed in the link above, and instead were referencing general desktop applications like how Gnome currently has a bit of a systemd-dependency then there's a different reason for that.

      Currently Gnome, and soon KDE, have a soft dependency on systemd/logind-- they will run without it but you'll be missing some functionality / get legacy codepaths. On the GNOME side, IRC, its because they let logind handle suspend/resume/hibernate. Now, a small correction to myself here.. Gnome doesn't depend STRICTLY upon --logind-- what it DOES depend upon is the DBUS API's that logind provides. IF another project were to be written that provided the same API's as logind and kept up with logind-compatibility then that project could be a drop-in replacement... So far no such project exists.

      KDE on the otherhand is not depending upon logind (AFAIK) they are instead shipping a .service file for setting up the KDE environment. Currently this is down through a rather slow, and fragile, shell script that gets run on boot/login. They wish to move to a .service file for an easier maintenance burden and performance reasons. If you aren't on systemd you'll get the old shell script and you can continue to pray to works.
      All opinions are my own not those of my employer if you know who they are.

      Comment


      • #93
        Originally posted by pingufunkybeat View Post
        This addresses a question I didn't ask, and addresses it badly.

        Why would a desktop application, like GIMP, care what the system daemon is doing? Why would Inkscape refuse to start if you run the "wrong" system daemon, or Gnumeric fail to compute if you are on a BSD?

        What sort of essential functionality is missing from them now, that must be added as a hard dependency tomorrow?
        Sorry, I had read "desktop" instead of "desktop app".
        I don't think gnumeric requires (in its source tree) systemd, however distro maintainers often put "unnecessary" dependencies between a desktop and its apps. But if you build it from source you should be clean!

        Comment


        • #94
          Thank you all for detailed responses.

          I understand why systemd is useful for login managers and starting the environment. I still think they should be soft dependency, but here the integration makes perfect sense.

          The previous poster strongly suggested that classic GNOME apps would refuse to run without systemd, and that seems ridiculous.

          Comment


          • #95
            Originally posted by pingufunkybeat View Post
            Can somebody explain to me why a desktop app should have a hard (!!!) dependency on a particular system daemon?

            Is there ANY technical reason for this?
            Desktop GUI programs like some system utilities and proper log-viewers are easy to make work across all systemd based operating systems, but are really hard to make work across non-systemd Linux distros, where utter chaos reigns regarding even small details like where to find the "os-release" file.
            The lack of structure in syslogd text logs also make it hard to make log-viewers that are anything more than glorified "less" pagers with windows decorations. I think several DE's like LXDE have such "systemd only" utilities.

            Then of course there will be sand-boxed Gnome apps. They are probably going to require systemd (and kdbus and much more) because no is likely to develop an alternative to that structure. In short, systemd makes it "easy" to sand-box apps because it already have many of the needed pieces and infrastructure, while no-one develops an alternative platform to support such app sand-boxing, except perhaps google, but their solution doesn't work on Linux desktops.

            So yes, some programs/apps will in the future require systemd, simply because they want to utilise the features systemd platforms provide, and because no-one seems to develop any proper alternatives to systemd that does what some upstream developers wants.

            However, most normal Gnome, KDE, LXDE programs and even their DE's will probably work on non-systemd platforms for a foreseeable future.

            Comment


            • #96
              Originally posted by prodigy_ View Post
              With systemd being the foundation of Linux userland and kdbus taking over the kernel there will be a lot less choice across the board.

              The windowisation of Linux is going full speed.
              And? People say "choice" like having 200 window managers are a good thing. Some standardization, some "guaranteed to be there" things, some consolidations are good things.
              All opinions are my own not those of my employer if you know who they are.

              Comment


              • #97
                Originally posted by lamawithonel View Post
                Is there a timeline or roadmap for stabilizing the APIs? When can we expect it will be possible to start writing up alternatives to journald, logind, etc.?
                Those API's are already stable and exposed for a long time as far as I can remember. But don't take my word for it, check the API stability promise (which, if you were serious about wanting to work on reimplementing these things, I guess you would have found by now...).

                Comment


                • #98
                  As a system admin who has experience with almost every modern UNIX with the exceptions of Oracle Solaris, NetBSD, QNX, AIX and a few obscure variants who's names escape me at the moment, I have to say systemd is not something I enjoy using. This is for countless reasons, but for consciseness I will keep it to three main points:

                  1. The performance gains of systemd are far outclassed by the complexity and insecurity drawbacks of it. Security has a multitude of approaches, but I like to approach it by taking a single point of failure caused by a monolithic program or process and break it up into several small programs. This reduces the attack surface from a huge monolith to a bunch of ants, more or less. The issue is, I don't like that systemd handles a good deal of unnecessary things in PID 1. This means a security exploit in those routines or roles can spread to the role of init, which means your machine or server is toast. BSD has an init system ( no, not BSD- style sysvinit ) which does the absolute bare minimum needed: starting and stopping the system from a set of run commands and handles zombie processes. Windows has the exact same issue, everything process related is handled by only a few programs, and need I say how many security exploits target their equivalent of init? Needless complexities are why OpenBSD and the other BEDs like FreeBSD would not want systemd even if it was portable.

                  2. It's completely unsuitable for servers and it is not even the above reason why. For a server everything is about fault tolerance, reliability, and ease of debugging. Shell scripts are easy to debug as they're basically a text file full of automated commands run by rc to start up and shut down By comparison systemd's .service files have a lot less of the code and basically contains parameters for start up and shut down, not the actual process followed by systemd. If there is a bug in a shell script I can easily run through it and review what it is doing and fix it right then and there. If you find its not a parameter issue with systemd then you have to learn C or hope that the error is in the logs, and even then you need to know what to search for. Its just a train wreck waiting to happen for a server.

                  3. Finally I think systemd is not the answer to the problems with process supervising in UNIX. Upstart was somewhat better, but an ideal system should leave init alone entirely, just using a standard BSD rc init is fine, and instead use supervision isolated from PID 1, and it should still use shell scripts, and have a modular design, meaning different packages for different applications.

                  So yes this is why I don't like systemd and why I am moving to BSD for most applications. I think if this systemd dependency BS continues then BSD will develop its own alternative. Look at LibreSSL and OpenSSH, both are forks or alternatives to inadequate solutions.

                  Comment


                  • #99
                    Originally posted by xeekei View Post
                    The biggest issue is that systemd-logind doesn't have an alternative. I thought it'd be one by now. ConsoleKit is abondened, last I heard.
                    Well, it's obviously *not* a big issue, because nobody cares enough to have made an alternative. Debian was looking as their systemd-shim package as a fork of one of the older logind versions, but interest in that seems to have dropped off after Debian and Ubuntu both opted to switch to systemd.

                    Comment


                    • I wonder if anyone has done a security audit of systemd. having pulseaudio as a precedent, I'm not sure I would trust systemd...

                      I want to really know: AFAIK, applications don't care about upstart, is the job of the packager to make apps it work with upstart. why should applications care about systemd? does, say, nginx need to be modified to work with systemd? does nginx depend on it, in such a way that it won't work with other init deamons? what about, say, mpv or konsole? Why does systemd seem to affect the whole system so much?

                      I dislike GNOME, so I don't care about it. Also, there is a U.S. military General in the board of directors of Red Hat, why should I trust them? I like the work of some of their devs, I don't trust the company as a whole.

                      Originally posted by Ericg View Post
                      And? People say "choice" like having 200 window managers are a good thing. Some standardization, some "guaranteed to be there" things, some consolidations are good things.
                      For me, as a user, Linux is about diversity. If I don't like something, I use an alternative. It's not a "choice" but a real choice. Now, if you are telling me that I will be forced to use systemd, because the applications I like depend on it and won't work without it, then THAT is a "choice", an illusion of choice from those who defend something. That's what prodigy_ meant with "Windowisation", I think: you have "alternatives", but they are not real alternatives.

                      Comment

                      Working...
                      X