Announcement

Collapse
No announcement yet.

GNOME 3.13.2 Temporarily Depends On Systemd

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

  • #31
    Originally posted by TeamBlackFox View Post
    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.
    top - 16:54:30 up 9:03, 2 users, load average: 0,87, 0,70, 0,76
    Tasks: 2 total, 0 running, 2 sleeping, 0 stopped, 0 zombie
    %Cpu(s): 21,1 us, 26,3 sy, 21,1 ni, 31,6 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
    KiB Mem: 3915924 total, 2401508 used, 1514416 free, 412 buffers
    KiB Swap: 4192252 total, 0 used, 4192252 free. 1698380 cached Mem

    PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
    1 root 20 0 26440 3624 1832 S 0,0 0,1 0:07.74 systemd
    353 root 20 0 29744 1620 1028 S 0,0 0,0 0:00.54 systemd-udevd
    They *are* seperate daemons. Wouldn't know if systemd functioned on a static /dev (or DEVTMPFS for that matter).

    Comment


    • #32
      Originally posted by Rexilion View Post
      They *are* seperate(sic) daemons. Wouldn't know if systemd functioned on a static /dev (or DEVTMPFS for that matter).
      Well I meant not that systemd itself would fail if udev died, but anything depending on udev such as networkd or logind would die if udev died. systemd is the root of all processes and in an attack designed to take a server offline from a hacked user account, its the easiest target. Thats what I meant. In FreeBSD, init isn't a full blown process supervisor, and is much harder to get to, thats all.

      Not to mention, the systemd pantheon keeps mushrooming outward, violating the principle of a limited, well defined function.

      Comment


      • #33
        Originally posted by TeamBlackFox View Post
        ...
        Not to mention, the systemd pantheon keeps mushrooming outward, violating the principle of a limited, well defined function.
        You're missing the point. What you're calling "systemd" doesn't exist; systemd isn't a single executable.
        Systemd is a group of several components, and each one does a limited, well defined function.

        What you're saying is comparable to saying "a music band violates the principle of a limited, well defined function because it plays more than one instrument".

        Comment


        • #34
          Originally posted by justmy2cents View Post
          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
          I was replying to the post stating that they directly link to systemd libraries, which is not DBUS communication and therefore a hard dependeny, which can only be thrown out by either dropping the dependent code, switching to DBUS communication or implementing the needed functions yourself.
          Therefore the question which it is.

          Comment


          • #35
            Originally posted by TeamBlackFox View Post
            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.
            Why the heck would you want to put GNOME in base? Regarding persons that use it on BSD, since there are OpenBSD developers porting GNOME to their OS I guess that there is interest in running GNOME on BSD.
            Regarding Wayland, it is a protocol, it is not dependent on udev. You possibly mix that up with Weston.

            Comment


            • #36
              Originally posted by Vim_User View Post
              I was replying to the post stating that they directly link to systemd libraries, which is not DBUS communication and therefore a hard dependeny, which can only be thrown out by either dropping the dependent code, switching to DBUS communication or implementing the needed functions yourself.
              Therefore the question which it is.
              Nevermind, I misunderstood your post at first. Stupid edit limit, Michael should really throw that out or at least extend it to something reasonable.

              Comment


              • #37
                Originally posted by TeamBlackFox View Post
                Not to mention, the systemd pantheon keeps mushrooming outward, violating the principle of a limited, well defined function.
                Except.. Its not. Everything like hostname control, journal, networking, all of that are separate processes with their own functions and jobs and limited permissions. Only thing they have in common is they are in the same source tree and thankfully all follow the same Dbus / API guidelines so that there is some unity and standardization amongst low level control.

                Comment


                • #38
                  Originally posted by TeamBlackFox View Post
                  • 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.
                  This one always gets me. People are really upset about software using advanced features available in the kernel? If so, new features would be useless, the kernel stagnates.

                  This is really the sticking point. You really believe that everything has to work on a 1980s Unix kernel and nothing new is allowed beyond drivers. That's fine, but the rest of us would like to move forward.

                  Comment


                  • #39
                    Originally posted by TeamBlackFox View Post
                    Well I meant not that systemd itself would fail if udev died, but anything depending on udev such as networkd or logind would die if udev died.
                    Eh? No they don't. The only thing that happens if you kill systemd-udevd is that systemd restarts it. Also you can use systemd and systemd-networkd in containers without even having systemd-udevd. Nothing happens to systemd-logind if systemd-udevd crashes.

                    Comment


                    • #40
                      Originally posted by TeamBlackFox View Post
                      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 BSDs distributions themselves are fragmented. FreeBSD, OpenBSD and DragonFly differ from each other lacking standard. Systemd took inspiration from BSD model to properly standardize the Linux core system.

                      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.
                      POSIX is outdated and become irrelevant as long the consortium stall rather than taking account of modern technologies. Systemd is specifically designed for Linux kernel as a core, its developers clearly uninterested to BSD distributions free to port it as they wish.

                      Comment


                      • #41
                        Originally posted by Teho View Post
                        Eh? No they don't. The only thing that happens if you kill systemd-udevd is that systemd restarts it. Also you can use systemd and systemd-networkd in containers without even having systemd-udevd. Nothing happens to systemd-logind if systemd-udevd crashes.
                        Yes, that would be my guess as well.

                        Originally posted by TeamBlackFox View Post
                        Well I meant not that systemd itself would fail if udev died, but anything depending on udev such as networkd or logind would die if udev died. systemd is the root of all processes and in an attack designed to take a server offline from a hacked user account, its the easiest target. Thats what I meant. In FreeBSD, init isn't a full blown process supervisor, and is much harder to get to, thats all.

                        Not to mention, the systemd pantheon keeps mushrooming outward, violating the principle of a limited, well defined function.
                        The systemd executable is quite limited in it's functionality. I would not consider it *huge*....

                        Originally posted by terminal
                        20:18 gebruiker@delta /usr/lib/systemd
                        ==> ls -lah systemd
                        -rwxr-xr-x 1 root root 1014K 13 apr 09:07 systemd
                        20:18 gebruiker@delta /usr/lib/systemd
                        ==> ldd systemd
                        linux-gate.so.1 (0xb774d000)
                        libpam.so.0 => /usr/lib/libpam.so.0 (0xb76f9000)
                        libcap.so.2 => /usr/lib/libcap.so.2 (0xb76f4000)
                        libkmod.so.2 => /usr/lib/libkmod.so.2 (0xb76dc000)
                        libseccomp.so.2 => /usr/lib/libseccomp.so.2 (0xb76cb000)
                        librt.so.1 => /usr/lib/librt.so.1 (0xb76c2000)
                        libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0xb76a4000)
                        libpthread.so.0 => /usr/lib/libpthread.so.0 (0xb7687000)
                        libc.so.6 => /usr/lib/libc.so.6 (0xb74c5000)
                        /lib/ld-linux.so.2 (0xb772c000)
                        libdl.so.2 => /usr/lib/libdl.so.2 (0xb74c0000)
                        libattr.so.1 => /usr/lib/libattr.so.1 (0xb74ba000)
                        libz.so.1 => /usr/lib/libz.so.1 (0xb74a2000)
                        Originally posted by mdias View Post
                        You're missing the point. What you're calling "systemd" doesn't exist; systemd isn't a single executable.
                        Systemd is a group of several components, and each one does a limited, well defined function.

                        What you're saying is comparable to saying "a music band violates the principle of a limited, well defined function because it plays more than one instrument".
                        Systemd actually is a single executable if you want. There is like 39 executables in /usr/lib/systemd in Arch. Each with their own configuration. But I guess that people more wonder about the project as a whole...

                        Comment


                        • #42
                          Originally posted by Scimmia View Post
                          You really believe that everything has to work on a 1980s Unix kernel and nothing new is allowed beyond drivers.
                          ^^ I actually like the sound of this. Still leaves plenty of room to improve things in userland, having a dependable core system, then trying to fulfil every conceivable use case by extending it, toward a better user experience for everyone.

                          Originally posted by Scimmia View Post
                          That's fine, but the rest of us would like to move forward.
                          By throwing away the existing interfaces, on which years' worth of software was developed? Most of it still around for having proven itself, become well understood, well documented in literature?

                          Your idea of moving forward sounds like rewriting everything anew, to be buggy again, to be learned again, perhaps only advantageous in specific use cases. And rinse and repeat this process every couple of years...

                          Comment


                          • #43
                            Originally posted by stevenc View Post
                            By throwing away the existing interfaces, on which years' worth of software was developed? Most of it still around for having proven itself, become well understood, well documented in literature?
                            Unfortunately in reality, we have Xorg and Makefiles and sysvinit, each of which has proven itself to be a burden in its own special way, and not particularly well documented either. Almost nobody understands how Xorg works, or how Makefiles work and unless you've been writing sysvinit scripts for years it comes across as a completely batshit solution.

                            Originally posted by stevenc View Post
                            Your idea of moving forward sounds like rewriting everything anew, to be buggy again, to be learned again, perhaps only advantageous in specific use cases. And rinse and repeat this process every couple of years...
                            So you've seen the future? Or are you just trying to strawman the hell out of us?

                            Comment


                            • #44
                              Originally posted by stevenc View Post
                              ^^ I actually like the sound of this. Still leaves plenty of room to improve things in userland, having a dependable core system, then trying to fulfil every conceivable use case by extending it, toward a better user experience for everyone.
                              Heh, yeah. I also like this idea.
                              Admittedly the slow release rate seems to work extremely well for Windows and I notice that Mac OS X also mutates at a much slower rate than Linux. If I was developing a large project over a 10 year period, I would certainly think twice about using Linux (and I did. Thats why we are using FreeBSD).

                              That said, I believe Oracle might be seeing a market here in that their "Unbreakable Linux" project actually provides a standard (stable) RHEL6 userland but with their own kernel which is as modern as version 3.8.13. This is brilliant. All the modern driver support without all the stupid ignorant Linux bullshit of modern distros

                              Comment


                              • #45
                                Originally posted by justmy2cents View Post
                                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
                                Actually, mutter links to libsystemd for one and only one function:

                                Code:
                                src/backends/native/meta-launcher.c:  if (sd_pid_get_session (getpid (), &session_id) < 0)
                                From man page: sd_pid_get_session() may be used to determine the login session identifier of a process identified by the specified process identifier.
                                Last edited by Krejzi; 05-30-2014, 07:29 AM.

                                Comment

                                Working...
                                X