Announcement

Collapse
No announcement yet.

Debian May Need To Re-Evaluate Its Interest In "Init System Diversity"

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

  • Originally posted by audir8 View Post
    elogind does what systemctl --user does. loginctl doesn't show me anything currently, so I don't think plasma uses it on Gentoo, but it could. https://github.com/elogind/elogind
    You really should have watched the video. Because elogind does not do what systemctl --user shows. Plasma and Gnome currently fall back and run using the system prior to systemd if "systemd --user" is missing or not usable at this stage.

    https://github.com/KDE/plasma-systemd-integration
    The kde work moving in the direction of systemd --user is here. Plasma can uses systemd --user but will run without it at this stage using the older system so not gaining you the advantages of cgroups and other security things around the different parts of the desktop environment.

    systemd --user/systemctl --user is something different to systemd-logind/loginctl.

    Basically you have not been on a systemd using distribution. Interesting enough replacing gnome-session with the same system used for the system wide service management running in usermode was not first done with systemd but first done with upstart.

    I will give you it simple to miss. There are two things that can be called session manager.

    1) login manager and login session this is logind and consolekit stuff.
    2) Desktop environment session manager. Gnome version is Gnome-session then you have ksmserver under kde as the older versions. This is what systemd --user is working on being used to replace.

    I really don't know why we have had to have a unique desktop environment session manager per major DE one thing systemd --user does possible promise is ending new windows managers creating their own unique DE session manager. Of course I would prefer a platform neutral solution over systemd --user for this that does support cgroups on LInux.

    Basically you have had your head dangerously in the sand about what is going on. Systemd based distributions have systemd piece by piece replacing the desktop environment session management with systemd --user.

    Openrc has focused on the service management getting that right. elogind is the login manager. DE session management is something where there is no fully functional competition on Linux to what systemd --user does.

    Yes a lot of the old DE session mangers work okish on freebsd due to being coded around BSD style logic of processes but they are not in fact working fine on Linux systems for the same process leak problems.

    Why okish is that is possible for gnome-session and ksmserver or some other DE session manager to both load on a user at the same time and decide to lock down the same device. Yes pulseaudio fixed sound server hell where two different DE sound server tried to get the audio device but other items remain where this disaster can still happen.

    Basically DE session management has been broken for over 3 decades now. Yes longer than Linux has existed and it really about time it gets fixed.

    Comment


    • Originally posted by Niarbeht View Post
      In the middle of watching this, this is fantastic.

      Comment


      • I wait for the day when Linux software stops resisting change and integrate better with systemd.
        It brings So Many features that Linux needs, especially when it comes to security...

        Comment


        • Originally posted by andrnils View Post
          Is the author of systemd any better than rms? Probably not, and neither is his view of "Linux or nothing". Systemd is completely the wrong way to go about compatibility, but what is required for the lackeys to realize that?
          Systemd is first about ease of management and application development, second about compatibility between the major Linux distros. It has never claimed to do anything for compatibility between Linux and ***BSD, or about making things easier for Joe Random's very own me-too-distro-without-systemd, because, like it or not, those are not the issues that worry those users that actually matter (i.e. those that pay for the development and/or contribute substantially to the Linux community).

          Comment


          • Originally posted by Alliancemd View Post
            I wait for the day when Linux software stops resisting change and integrate better with systemd.
            It brings So Many features that Linux needs, especially when it comes to security...
            To the former, Linux software is an epithome to a change. To the ridiculous idea of change for the sake of change itself. New features are more important than fixing older issues. Nature of the evolutionary software. You just keep forgetting that evolution itself is Darwinian in principle - mutate too far or specialize too deeply and your resounding success might become story of extinction when conditions change. Because you can no longer neither turn back or adapt yet more. It's also a path of spiraling history and making same mistakes over and over again.

            To the latter.. Lol what? Rule of thumb: less code, less potential bugs, more security. Few million loc internally interlocked APIs, kept intentionally obscure and in constant change - to make harder not to use systemd is somehow "secure" for you?? Holy naivety..

            Comment


            • Originally posted by aht0 View Post
              To the latter.. Lol what? Rule of thumb: less code, less potential bugs, more security. Few million loc internally interlocked APIs, kept intentionally obscure and in constant change - to make harder not to use systemd is somehow "secure" for you?? Holy naivety..
              There is a horrible reality here if you in fact totally up all the lines of code to make a sysvinit system have all the features that systemd provides its in fact 40 times the number of lines of code of systemd. Yes systemd is in fact smaller that what it has replaced. So less code, less potential bugs and more security is in fact in systemd favor over sysvinit solutions.

              Same with a lot of the other broken solutions. Openrc maybe able to be competitive when with the same features as systemd on lines of code.

              Of course I would like to see init system with better security design from the get go right down to using sel4 mathematically secured in code off the start line.

              Comment


              • Originally posted by oiaohm View Post
                There is a horrible reality here if you in fact totally up all the lines of code to make a sysvinit system have all the features that systemd provides its in fact 40 times the number of lines of code of systemd (a). Yes systemd is in fact smaller that what it has replaced. So less code, less potential bugs and more security is in fact in systemd (b) favor over sysvinit solutions.
                You base your argument first on a purely hypothetical guess (a), then proceed claiming that systemd has less code than this 'hypothetically equally functional' sysvinit would have (b).. And because of this, systemd is certainly more secure? That's one solid argument there.
                Question tho: do most people need most features by systemd? Or not? Because they do get all it's potential risks regardless.

                Originally posted by oiaohm View Post
                Same with a lot of the other broken solutions. Openrc maybe able to be competitive when with the same features as systemd on lines of code.
                Of course I would like to see init system with better security design from the get go right down to using sel4 mathematically secured in code off the start line.
                For some reason 'sel4' is not the path chosen by OpenBSD folks, who are chasing namely security. They are doing it by keeping code base minimal, auditing it relentlessly and REMOVING features they think either not needed or potentially risky. So, which approach is more secure?

                Comment


                • Originally posted by anarki2 View Post
                  Wait what? A single init system reduces maintenance burden? And multiple init systems actually increase it? Developer time is not infinite and free? Really?

                  Shock horror. We've been only saying this for like 5 years. The delusional guys at Devuan et al feel free to toy around for a few years more. Delaying the inevitable sure is a fruitful effort, time well spent. Let the duplication of efforts continue!
                  The one thing, and I won't be humble here at all, that most tech/nerd types lack is humility and they collectively seem to suffer from NIH, and I don't think it gets better with age either, they just get more coy about it.

                  Comment


                  • Wow, I've read some truly dumb shit in this thread, "the one true way", "deunixification", "systemd is a init", "security through complexity".... jesus fuckin christ! Are systemd zealots really this fuckin stupid??? Apparently yes...

                    Comment


                    • Originally posted by aht0 View Post
                      You base your argument first on a purely hypothetical guess (a), then proceed claiming that systemd has less code than this 'hypothetically equally functional' sysvinit would have (b).. And because of this, systemd is certainly more secure? That's one solid argument there.
                      Question tho: do most people need most features by systemd? Or not? Because they do get all it's potential risks regardless.



                      For some reason 'sel4' is not the path chosen by OpenBSD folks, who are chasing namely security. They are doing it by keeping code base minimal, auditing it relentlessly and REMOVING features they think either not needed or potentially risky. So, which approach is more secure?
                      Ok, but systemd makes -no- attempt to abstract internal interfaces. It's a horrible, completely incomprehensible mess of spaghetti code. Sure it has less lines of code, but it damn sure isn't elegant. It's a horribly complex pile of slop. Incomprehensible code has no chance in any hell of being secure. I would love to see some fuzzing results.
                      Last edited by duby229; 09-25-2019, 03:30 PM.

                      Comment

                      Working...
                      X