Announcement

Collapse
No announcement yet.

GNOME 3.13.2 Temporarily Depends On Systemd

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

  • #16
    Originally posted by Luke_Wolf View Post
    Could someone please explain to me where this meme of it "being like MicroSuck" or "windowsizing linux" came from? If anything it's making Linux take on a BSD type development model, which can be argued for or against, but I don't see where Windows or MicroSuck come in as despite the obvious implication of it limiting choice, it's not limiting choice in a way that really effects users as opposed to distribution developers by creating standards for things like hostname and timezone placement. It's not like it's forcing you to say use gnome as your DE.
    First of all, I like systemd.

    As for your question: everything is being shoved into one piece of software. Windows could be viewed as a humongous base package with very little customization or choice (extending far beyond the current state of GNU/Linux including systemd). Systemd is being perceived as limiting people in choice as it seems to handle more and more features.

    Systemd is currently:

    sysvinit + udev + consolekit + cron + anacron + syslog + logrotate + various network scripts (+ dhcp client/server) + time server

    This kind of departs from the idea to have seperate daemon's / software handle specific and well definied tasks. And to handle these well.

    However, systemd can still be stripped to a bare minimum of sysvinit + udev according to it's developers.

    I *am* starting to wonder: when will it end? Eventually it might become too big and end up like HAL.

    Comment


    • #17
      Originally posted by Rexilion View Post
      ...
      Systemd is currently:

      sysvinit + udev + consolekit + cron + anacron + syslog + logrotate + various network scripts (+ dhcp client/server) + time server

      This kind of departs from the idea to have seperate daemon's / software handle specific and well definied tasks. And to handle these well.

      However, systemd can still be stripped to a bare minimum of sysvinit + udev according to it's developers.
      ...
      There doesn't seem to be any evidence that systemd handles that stuff any worse than "separate daemons". I'm not very knowledgeable about systemd's internals, but it looks like everything acts as a separate daemon anyway... The fact that the it's all in the same repository and branded with a single name "systemd" doesn't mean it's any less stable or capable than multiple different software programs.

      The way people talk about "windowzisation" make it look like they're saying standardization (which is what systemd is doing) is bad and not actually making a comparison to the way windows work. People are still free to use the linux kernel and build their own stuff on top of it. Don't complain if other people like standards and so are building on top of systemd.

      It's not that much different than Qt, GTK or even OpenGL. Their purpose is to create a standard layer that abstracts what's going under the hood for you. In the end what matters is that you're able to do everything you want, and if systemd isn't able to do that yet, lend a hand and contribute your patches...

      Comment


      • #18
        Originally posted by mdias View Post
        There doesn't seem to be any evidence that systemd handles that stuff any worse than "separate daemons". I'm not very knowledgeable about systemd's internals, but it looks like everything acts as a separate daemon anyway... The fact that the it's all in the same repository and branded with a single name "systemd" doesn't mean it's any less stable or capable than multiple different software programs.
        True.

        Originally posted by mdias View Post
        The way people talk about "windowzisation" make it look like they're saying standardization (which is what systemd is doing) is bad and not actually making a comparison to the way windows work. People are still free to use the linux kernel and build their own stuff on top of it. Don't complain if other people like standards and so are building on top of systemd.
        I'm not complaining. However, if you don't like how systemd is handling something on the sysvinit part you have to fork the entire tree to make modifications.

        Furthermore, I think that people are not charmed by the idea that many different components are now governered by the same group of people. This could explain the resistance against systemd as a whole.

        Originally posted by mdias View Post
        It's not that much different than Qt, GTK or even OpenGL. Their purpose is to create a standard layer that abstracts what's going under the hood for you. In the end what matters is that you're able to do everything you want, and if systemd isn't able to do that yet, lend a hand and contribute your patches...
        The big difference IMHO is that QT, GTK and OpenGL have a well defined purpose. QT and GTK provide widgets to build graphical user interfaces. OpenGL is a standard to facilitate 3D programming over a broad range of cards / configurations.

        What is the point of systemd in one sentence?

        - To provide reliable process management. (but what about the syslog and network capabilities?)
        - To provide a central place for system configuration. (didn't sysvinit do that already?)
        - To provide a standard way of configuring and handling system services. (what problem does it solve?)

        I see more and more functionality being concentrated into one project. That is not (IMHO) a bad thing by definition. It's just that sometimes the benefits are not clear to me.

        Comment


        • #19
          Originally posted by Rexilion View Post
          What is the point of systemd in one sentence?
          systemd starts up and supervises the entire system (hence the name...).

          It is what "void" is to the space.

          Comment


          • #20
            Originally posted by prodigy_ View Post
            Temporarily, my ass.


            No, R.I.P. Linux.
            No, R.I.P. crappy Linux, hello awesome Linux!

            Comment


            • #21
              Originally posted by nerdopolis View Post
              It's relying on a feature in systemd/logind (I THINK it's communicated with dbus but I am not sure) that allows an underprivileged program to get access to the input device files (/dev/input/event*), instead of relying on multiple instances of setuid helpers. This is useful for display servers like weston, and mutter, and I think possibly xorg could take advantage of that feature too.
              Actually, both weston and mutter link directly to systemd library due to using some sd_* functions., but looking at mutter patch, it mainly uses D-Bus to communicate with logind.

              Comment


              • #22
                Originally posted by Krejzi View Post
                Actually, both weston and mutter link directly to systemd library due to using some sd_* functions., but looking at mutter patch, it mainly uses D-Bus to communicate with logind.
                But if they link to a systemd library, how can this be temporary? Unless the GNOME developers pan to implement those functions themselves, of course.

                Comment


                • #23
                  Originally posted by Rexilion View Post

                  What is the point of systemd in one sentence?
                  "To provide central operating system functionality and management of those functions on Linux systems." Could be an example.


                  Originally posted by Rexilion View Post
                  - To provide reliable process management. (but what about the syslog and network capabilities?)
                  If you want first class process management, you also need first class debugging facilities for processes, and that means logging too. Systemd aims to manage all processes from "metal-to-metal", that is from the micro-second the kernel is bootstrapped, to the last microsecond possible before shut-down.

                  The only way to do that, is to make a new logging system like "journald" that can cope with that situation, because syslogd can't. Of course, one could just stop it there, and just have "journald" forward to syslogd, but in effect you would run with two logging systems, reducing syslogd to a mere logging sink that writes to the disk.

                  The step to provide "journald" with log-writing functionality was a small step, that reduced both system overhead and attack surface.

                  But the indexed journal solves many problems at the same time too;

                  1. it provides a proper API for log watching systems. Previously such systems would rely on grepping certain text fragments, and that in effect made the error messages an API in it self; if a program changed its error messages it would break thousands of homespun watch-scripts in the wild. Now those watch programs can rely on a stable API and logging structure to ensure that they work, even if an error message changes from "foobar terminated" to "foobar stopped".

                  Log-watching is within the larger scope of process management.

                  2. Multi language error messages (see above)

                  3. Secure logging: since the logging information is controlled by PID1 on the kernel level, it can offer kernel level protection of the logging info. On a systemd distro, one can distinguish between the real "cupsd" writing to the log file, and a bash script that mere claims it is "cupsd".
                  There is also log-consistency checks and even forward security sealing.

                  Secure logs is within the larger scope of process management.

                  4. It provides a proper API for upstream developers. It is extremely hard to make GUI logviewers with the old rather unstructured text dumps of syslogd. Most of those made were just glorified "less" pagers with windows decorations.
                  Simple things like sorting, or interleaving messages from two systems, or providing monotonic time lines, or even filtering, became major chores. With systemd and its journald, it becomes very easy to make log viewing programs that are full featured.



                  My point here is mainly to show, that there actually is some really sound design decisions behind systemd, and that things that may look apart, like process management and logging, actually have good reasons to be tightly integrated. There actually is both a good design and a design scope behind systemd, it isn't just growing in every direction like some people think.
                  It is admittingly a wide design scope, but at least there is one, that is much more than can be said for the competition.

                  Now, one can argue all day about whether such tight integration should be developed in unison in one umbrella project, or be spread out among totally different projects. But this remains a sterile theoretical discussion as long as there isn't actual tight integration between such projects outside systemd.

                  I like systemd, but I would love that it actually had some healthy competition, but it doesn't. Development outside systemd seems extremely fragmented with crucial pieces like user management (ConsoleKit), just bit-rotting away like no one cared.

                  It is a major selling point for systemd, that it actually exist and is quite mature, which is quite unlike its competition. Like it or not, it is there all the Linux integration seems to be happening.

                  Comment


                  • #24
                    Originally posted by Vim_User View Post
                    But if they link to a systemd library, how can this be temporary? Unless the GNOME developers pan to implement those functions themselves, of course.
                    For mutter, systemd will probably be used if wayland compositor is enabled, so the new code would need few #ifdefs not to compile systemd code unless wayland compositor is requested. weston already does that, it compiles systemd related code if systemd is detected, otherwise it falls back to using setuid wrapper and such.

                    Comment


                    • #25
                      Originally posted by Vim_User View Post
                      But if they link to a systemd library, how can this be temporary? Unless the GNOME developers pan to implement those functions themselves, of course.
                      I think the integration between Gnome/Wayland and systemd is permanent as long as there isn't any alternative to logind provided by the non-systemd distros. Consolekit have been bit-rotting for almost two years now. Gnome developers have warned about this situation for years, but nobody seems to care. They blog about how much they would love and support an alternative API to logind, but all they receive from downstream are endless insults and snarky remarks, like "RIP Gnome".

                      But at least they will offer Gnome/X using legacy code, at least for a while. It was that legacy support that have been temporarily removed. But offering Consolekit legacy support got to stop at some time in the future, since it is infeasible and unsound to support bit-rotting projects for years on end.

                      It is totally up to the non-systemd distros and their developers to help upstream projects like Gnome and KDE to function on their distros.

                      Comment


                      • #26
                        Originally posted by Vim_User View Post
                        But if they link to a systemd library, how can this be temporary? Unless the GNOME developers pan to implement those functions themselves, of course.
                        if it is dbus communication, then linking simply makes no sense at all. you provide connecting interface as part of your app and that is it. if it wouldn't be so, then whole point of dbus would make no sense. with dbus communication... YOU DON'T implement innards, that is up to server providing interface. so, if sysv somehow satisfied dbus interface for logind... why not? client should not notice any difference

                        so, yea this is surely temporary fast hack. it is simply faster to set up environment like that and later abstract it by defining connecting interface+remove dependancy. the only way where you would depend on original interface is if that interfaces definition would be abstracted from its owner in order to provide base for other implementors. i don't like gnome how it evolves, but that won't make me bash it where it doesn't deserve

                        Comment


                        • #27
                          It seems to me that this isn't a bad thing. I know not one person who uses GNOME on BSD, or on anything at all really, unless you count Cinnamon, and if I remember correctly as of version 2 that no longer relies on the GNOME package as a direct dependency - in other words - we're not going to lose much. All BSD projects are BSD-licensed and as GNOME is a direct part of GNU the effort is really sort of wasted to keep it BSD compatible, its only ever going to be a port or package and never included in base, unless you're PC-BSD.

                          I have to say I don't mind Wayland one bit, because it is indeed more UNIX way conforming to vs X11. The issue is that it currently depends on udev, a GNU/Linux dependency. It'd be nice if instead of relying on a piece of systemd that Wayland instead used a protocol which could map to udev, HAL, devd (FreeBSD's equivalent) or whatever the underlying system used for that role.

                          Comment


                          • #28
                            Originally posted by Rexilion View Post
                            First of all, I like systemd.

                            As for your question: everything is being shoved into one piece of software. Windows could be viewed as a humongous base package with very little customization or choice (extending far beyond the current state of GNU/Linux including systemd). Systemd is being perceived as limiting people in choice as it seems to handle more and more features.

                            Systemd is currently:

                            sysvinit + udev + consolekit + cron + anacron + syslog + logrotate + various network scripts (+ dhcp client/server) + time server

                            This kind of departs from the idea to have seperate daemon's / software handle specific and well definied tasks. And to handle these well.

                            However, systemd can still be stripped to a bare minimum of sysvinit + udev according to it's developers.

                            I *am* starting to wonder: when will it end? Eventually it might become too big and end up like HAL.
                            This is the point that keeps confusing people. the "systemd" application isn't really getting any bigger or accumulating features outside of its intended purpose. What is growing is the *project*, which like you said consists of a bunch of tools. The BSD comparison is quite apt... Claiming that "systemd does everything" is pretty much equivalent to claiming that init on BSDs does everything because it's part of an integrated base system.

                            Comment


                            • #29
                              Originally posted by Vim_User View Post
                              But if they link to a systemd library, how can this be temporary? Unless the GNOME developers pan to implement those functions themselves, of course.
                              one would have to guess this is more or less temporary. it is damn hard to predict interfaces and depend on interfaces only. once you see what you need to abstract you could simply expose those features over dbus and then any solution can satisfy them.

                              if there is one thing that i adore about systemd is the fact that they always define dbus interface for everything. don't like it? create service that hosts dbus server for that interface and not one client should notice any difference

                              Comment


                              • #30
                                Originally posted by Chousuke View Post
                                This is the point that keeps confusing people. the "systemd" application isn't really getting any bigger or accumulating features outside of its intended purpose. What is growing is the *project*, which like you said consists of a bunch of tools. The BSD comparison is quite apt... Claiming that "systemd does everything" is pretty much equivalent to claiming that init on BSDs does everything because it's part of an integrated base system.

                                There are differences Chousuke:
                                • The BSDs base software consists of applications that perform a limited, well definined function. They're also independent of each other, if something in your cat binary breaks its not going to affect any other binary unless cat is a specific dependency. In systemd, they're all tied together. udev is the main duct-tape, glue, whatever term you'd want to use for systemd-udev. If anything breaks udev, the entire monolith breaks apart.
                                • The BSD userland is mostly POSIX compliant and can be run on top of the Linux kernel, or the illumos kernel without much difficulty, unlike systemd on BSD, which will never happen at least for FreeBSD and OpenBSD, and I doubt illumos is interested either.

                                Comment

                                Working...
                                X