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 danmcgrew View Post
    PulseAudio? Is my sound any better?
    Exactly as it was, but more usable.

    Wayland? Are my graphics any better?
    Yup.

    Systemd? Is my system more stable and/or boots faster?
    Immensely.

    Comment


    • "Stop caring about sysv init", lol. Like if someone has been really maintaining this, doh. It always gave nasty shit in Debian. And still does - for services that haven't gone systemd so far. I'm sorry but sysv scripts tend to backfire or misbehave and utterly lack diagnostic & reasonable management - which makes it quite frustrating experience. Somehow quality of sysv scripts in debian always been below of what anticipated.

      In case of systemd obvious advantage is that core complexity is pushed out to some project that more or less sorted things out - and there is privileged "core" that can create sandboxed "arena" for new processes.. Something that sysv approach never achieved - forcing everyone to reinvent the wheels here and there and struggle a lot if they're serious about e.g. hardening system security. So while I'll say systemd eventually being annoying with its unrestricted growth and some strange design decisions (e.g. dbus crash = whoops, it gets nearly uncontrollable) - I'm yet to see anything better than that.

      As for boot speed, systemd beats crap out of "usual" sysv init any day. And it also at least writes logs, so if something fails to start for whatever reason, I can get idea why. In sysv most scripts do not give crap about exit codes or process crashes and I had to write all debug logging myself. Sorry but is sucks too much. Especially when you need to start your own service that isn't packaged by distro.
      Last edited by SystemCrasher; 09-19-2019, 10:15 PM.

      Comment


      • Originally posted by jacob View Post

        I think a more fundamental problem is that the systems you mention (cron etc...) follow the "everything is a text file" concept which was perfectly fine... in the 1970s where computers were static, centralised, had a full time sysadmin and the concept of third-party user applications didn't exist. But today we need a clean break from that and move to an era where everything is an API instead. Cron for example has no API at all. With cron there is no way whatsoever the developer of an application (I'm specifically saying DEVELOPER, not the admin!) can say "I need this function to run every 6 hours" for example to update F/X rates and be sure that it's indeed going to happen as required. Note also the deliberate use of the word function as opposed to shell script. Plus the sacrosanct "choice" means that whatever clunky and inadequate ersatz the developer will implement to work around this stupid limitation, it may not (and probably will not) work anyway for totally arbitrary and unpredictable reasons.

        Put another way, Linux was born out of Unix which was a sysadmin's OS. It's imperative that it becomes a developer's OS instead.
        You're missing the point which is cron functionality doesn't need to be anywhere near something that is mainly managing boot configuration and services. https://stackoverflow.com/a/879022/1210336 You can put files in directories too with cron, and you can set it up so users can do it too.

        Linux already is a developer's OS, it's the reason WSL exists. I can see spstarr 's point about being scalable in the cloud and unit files accomplish this, but as a developer I embrace KISS and don't mind the occasional bash. Systemd's unit files are the API that can be improved or used by another init system.

        As somebody mentioned: http://www.ocsmag.com/2016/10/19/sys...gh-complexity/ I have a story too: I have maintained a single functioning install of Ubuntu since 8.04 (a couple minor upgrades, but then mostly LTS upgrades, running 18.04 now). Only ~half the times did it upgrade without issues. Almost every package is set to manual install and I'm sure there's some cruft I haven't removed, but I still use it as a backup laptop (10 yo C2Quad isn't too shabby). This wasn't that hard to do because Gentoo. The last problem I had with it was systemd related and it was every bit as obtuse to troubleshoot as the post lays out and implies. To newcomers, or those who learned about it before jumping in, I'm sure the experience of using systemd was better. I'm sure this accounts for a lot of the hate that systemd gets, that and the feature creep. Anyone can call it "system manager", but no one has to use it. Over time, my opinion hasn't changed. I prefer things that do one thing well, and not try to reinvent cron or inetd among other things. It's mostly all udev/dbus/kernel in the back anyway.
        Last edited by audir8; 09-19-2019, 10:15 PM.

        Comment


        • Originally posted by spstarr View Post
          Please don't assume you know me. I know more about both given I've been there from the very beginning of Fedora .... anyhow. I know about that history... it doesn't change the fact a lot of people I know personally in Red Hat or who were in Red Hat HATED systemd and refused to even use Fedora for their development... kernel development....
          So was I. The point is calling out the claim systemd was forced on Fedora/RHEL which is incorrect as majority of developers and administrators gladly got rid their old shell scripts and the fact sysemd is backward compatible with the old sysint script. Without the hard work done by the systemd developers to implement a real system management for the Linux kernel, we would remain in the same impasse that happened over nearly twenty years.

          Comment


          • Originally posted by jacob View Post
            I think a more fundamental problem is that the systems you mention (cron etc...) follow the "everything is a text file" concept which was perfectly fine.
            That is not the problem systemd is still a lot of text files.

            The problem is simpler. Linux is in fact a Unix like operating system. As in Linux behaves a lot like Unix but it has key differences to a true BSD based Unix or a BSD. Under Linux every property on a process associating it with other processes can be changed by process except of cgroup. BSD based like most Unix and freebsd/netbsd... you cannot change your parent association.

            Remember sysvinit has two incorrect presumes for Linux. sysv PID numbers were not recycled so when they are horrible things can happen. The other presume same mistake cron has that a process will not disconnect itself from parent.

            Please note things have changed for cron from the first version. First version of cron everything had to be in a single text file today you see /etc/cron.d and other .d directories. Yes file IO stuff is a API. What .d was for developers so they could put there own file in the .d directory and have the process pick configuration with having to mess with other parties configurations. So yes cron has a API written around file actions to configure cron. But cron depend on the process tree to remain correctly assembled to double check everything was working.

            cgroups added another section to files and when you use timers in systemd whey they are running they should appear as file access. Montoring a cgroup directory will tell you if the timer process is in fact running. Systemd has a lot of file API stuff.

            Having a API is no good if when you store settings you cannot tell who created what like Windows. How setting are stores on the file system is something very important to be right.

            Comment


            • Originally posted by audir8 View Post

              You're missing the point which is cron functionality doesn't need to be anywhere near something that is mainly managing boot configuration and services. https://stackoverflow.com/a/879022/1210336 You can put files in directories too with cron, and you can set it up so users can do it too.

              Linux already is a developer's OS, it's the reason WSL exists. I can see spstarr 's point about being scalable in the cloud and unit files accomplish this, but as a developer I embrace KISS and don't mind the occasional bash. Systemd's unit files are the API that can be improved or used by another init system.

              As somebody mentioned: http://www.ocsmag.com/2016/10/19/sys...gh-complexity/ I have a story too: I have maintained a single functioning install of Ubuntu since 8.04 (a couple minor upgrades, but then mostly LTS upgrades, running 18.04 now). Only ~half the times did it upgrade without issues. Almost every package is set to manual install and I'm sure there's some cruft I haven't removed, but I still use it as a backup laptop (10 yo C2Quad isn't too shabby). This wasn't that hard to do because Gentoo. The last problem I had with it was systemd related and it was every bit as obtuse to troubleshoot as the post lays out and implies. To newcomers, or those who learned about it before jumping in, I'm sure the experience of using systemd was better. I'm sure this accounts for a lot of the hate that systemd gets, that and the feature creep. Anyone can call it "system manager", but no one has to use it. Over time, my opinion hasn't changed. I prefer things that do one thing well, and not try to reinvent cron or inetd among other things. It's mostly all udev/dbus/kernel in the back anyway.
              That's simply not true. A user facing application should not have to handle the click on a button in its UI by generating and dropping some kludgey shell script in some cron directory. And it can't do it anyway if it's not running with root privileges. Are you suggesting that a user app should implement logic to somehow parse, update and save the user's crontab? How on Earth is that supposed to be... not even better, but simply acceptable?

              And what are you going to do with your cron job, by the way? How is it going to call back into the application's code to trigger whatever action needs to be taken? By using dbus? How dareth thou, you heretic! Joe Unix Maniac's Choice(tm) is not to ever have dbus "on his system", so that won't work. Does the app then need to somehow be running in the background all that time and listen on some socket? How is it going to achieve that (without ever assuming for one second that the user is going to start writing scripts or such), since we have precious Choice(tm) of two dozen desktops or so, each with its own incompatible session management semantics and every single one of them broken by design?

              So by now the idea of clicking on a simple button that says "do this every X hours" requires actually implementing a complex parser (with file locking and capable of handling all the various failure modes of POSIX IO), socket management and some form of self-managed daemon mode that tries to work around all the mutual incompatibilities that people insist on keeping? Yeah, no. I'll rather have systemd and dbus and not bother supporting anything else, thank you very much.

              Comment


              • Originally posted by jacob View Post

                That's simply not true. A user facing application should not have to handle the click on a button in its UI by generating and dropping some kludgey shell script in some cron directory. And it can't do it anyway if it's not running with root privileges. Are you suggesting that a user app should implement logic to somehow parse, update and save the user's crontab? How on Earth is that supposed to be... not even better, but simply acceptable?

                And what are you going to do with your cron job, by the way? How is it going to call back into the application's code to trigger whatever action needs to be taken? By using dbus? How dareth thou, you heretic! Joe Unix Maniac's Choice(tm) is not to ever have dbus "on his system", so that won't work. Does the app then need to somehow be running in the background all that time and listen on some socket? How is it going to achieve that (without ever assuming for one second that the user is going to start writing scripts or such), since we have precious Choice(tm) of two dozen desktops or so, each with its own incompatible session management semantics and every single one of them broken by design?

                So by now the idea of clicking on a simple button that says "do this every X hours" requires actually implementing a complex parser (with file locking and capable of handling all the various failure modes of POSIX IO), socket management and some form of self-managed daemon mode that tries to work around all the mutual incompatibilities that people insist on keeping? Yeah, no. I'll rather have systemd and dbus and not bother supporting anything else, thank you very much.
                At this point the only thing left to say, and what I realize is that Linux is a server and cloud focused OS. It's systemd's focus. Features offered by it are no different from the kernel/steam connectivity issue recently and causing problems like this: https://github.com/systemd/systemd/issues/13553 You don't mind the complexity or features because it helps you, but it can in fact be too complex for the average user. You can make it as easy as a drag and drop GUI, but the complexity is still there. The average web dev or backend dev like me doesn't care about init systems either, I'm fine with any sane API, and systemd unit files don't seem so bad at all once you learn about them.

                Yes, server shit does eventually come down to the desktops, but server shit bakes for ~10 years so until the bugs are gone and it usually takes another few years before being accepted by someone who doesn't manage a cluster. No average user using Ubuntu or Fedora is going to file such a systemd bug on github, but here we are. Hope the complexity all works out in another few years. Android doesn't use systemd, and others in an embedded environment that do get rid of the complexity before they do, probably just to reuse unit files.

                Comment


                • Originally posted by jacob View Post
                  That's simply not true. A user facing application should not have to handle the click on a button in its UI by generating and dropping some kludgey shell script in some cron directory. And it can't do it anyway if it's not running with root privileges.
                  /var/spool/cron pay to read on.
                  http://man7.org/linux/man-pages/man8/cron.8.html
                  So using cron was no root privilege required.

                  Reason why the crontab application would not work for users had been disabled by the distribution or administrator. Due to user created cron being disabled by default in most cases it never got updated with a .d option. Reason for crontab application being disabled is a stack of historic pranks and being hard to trouble shoot who was being the ass. This is the difference between Linux and Unix problem resulting in why cgroups have to be used.

                  Really this is kind of why systemd is not that bad for me that it consumed cron. Systemd user mode implements timers wrapped in users cgroup so you can trace to who is directly responsible. Systemd user timers by default have a really smart feature they don't run if the user is not logged in so cannot be used to prank a different user as simply.

                  This is area that been broken that systemd in fact provides a working solution to. There are some third party addons to systemd that bring crontab application back and it creates systemd.timer files in user account.

                  Originally posted by jacob View Post
                  Are you suggesting that a user app should implement logic to somehow parse, update and save the user's crontab? How on Earth is that supposed to be... not even better, but simply acceptable?
                  Lot of this problem would be solved for cron if .d had been implemented on /var/spool/cron allowing each application just to drop it own configuration file. Of course this does not change why user settable cron was being disabled by default being the lack of traceability.

                  Originally posted by jacob View Post
                  And what are you going to do with your cron job, by the way? How is it going to call back into the application's code to trigger whatever action needs to be taken? By using dbus? How dareth thou, you heretic! Joe Unix Maniac's Choice(tm) is not to ever have dbus "on his system", so that won't work. Does the app then need to somehow be running in the background all that time and listen on some socket?
                  Does not need to be running in background all the time cron just like a systemd timer can start basically what ever. Yes you can query if a user has X11 session running and then processed to run application with that display output from cron or a systemd timer. Lack of dependable session management now does come a problem where if you fail to detect that the application is running you have a growing number of that application running and worse with possible no record in the process table that it was cron doing it. Yes not using cgroups and it forked off the right way under Linux from cron so no record how application was started in process table and cron not required to log starting things have fun debugging this.

                  Of course gnome looking at systemd user mode idea of session managment does mean you could say timer depends on x service application being running so systemd would start the correct application only if required.

                  Session management and process tracking under Linux both to work come a use cgroup feature so we have sanity. Now does this have to be systemd long term no. Does it have to be something setting the cgroups up yes.

                  Cron being a ass to use is because it was broken. API really required for cron file based ABI would have been good enough. Lot miss why the .d feature did not come to the user cron configuration directory. Yes that security problem with lack of accountability. The .d directories come out of the Linux world so of course they did not appear anywhere where Linux was not functional. Yes having not functional sysvinit result in cron not being functional. This is not the only domino effect from sysvinit limitations to other parts in Linux.

                  Comment


                  • Originally posted by audir8 View Post
                    At this point the only thing left to say, and what I realize is that Linux is a server and cloud focused OS. It's systemd's focus. Features offered by it are no different from the kernel/steam connectivity issue recently and causing problems like this:
                    That one turns out to be mega screwed. This was kernel update and systemd caused trouble at the same time. Updating systemd udev to support future kernel change resulted in breaking it on prior kernels.

                    Some of these connectivity issues just turn pain in ass. It not like Linux is unique for it there are sometimes windows input driver issues that are caused the same way.

                    Originally posted by audir8 View Post
                    Android doesn't use systemd
                    That fairly much Android aversion to LGPL for anything more than they have to.

                    Originally posted by audir8 View Post
                    others in an embedded environment that do get rid of the complexity before they do, probably just to reuse unit files.
                    Embedded developers are very good to watch with systemd. You see systemd cut down to the point of insanity in embedded. No dbus, no journald, no logind. Things they are after is the unit based service management with cgroup controls on resource usage and systemd watchdog system everything else when they build systemd from source is basically disabled. So yes embedded do strip a lot of complexity out of systemd but what they use is build from the mainline systemd sources with no code modifications. Purely configuration.

                    Comment


                    • Originally posted by oiaohm View Post
                      Lot of this problem would be solved for cron if .d had been implemented on /var/spool/cron allowing each application just to drop it own configuration file. Of course this does not change why user settable cron was being disabled by default being the lack of traceability.
                      I think this is more or less the crux of the matter and what the systemd flamewars are really about. Many people argue that "you can set it up to do X", "It could do X if...", "You could just implement X" etc. But I look at it from the point of developing desktop applications: not cloud or server which I'm not really interested in, not system administration, not web apps running on electron etc... Actual desktop applications. And I believe that saying that you can set it up to do something doesn't solve anything. If the developer can't count on a feature being present, available and working 100% of the time for 100% of the users with zero additional user interaction required, then that feature simply doesn't exist.

                      Originally posted by oiaohm View Post
                      Does not need to be running in background all the time cron just like a systemd timer can start basically what ever. Yes you can query if a user has X11 session running and then processed to run application with that display output from cron or a systemd timer.
                      You do realise that we are now talking about 100s of lines of very error-prone and nontrivial code to accomplish a basic function that all modern and sensible OSes let you do with no more than, say, five?

                      Originally posted by oiaohm View Post
                      Session management and process tracking under Linux both to work come a use cgroup feature so we have sanity. Now does this have to be systemd long term no. Does it have to be something setting the cgroups up yes.
                      cgroups are an essential component of the puzzle to make it work but they aren't the solution by themselves. It's a very low level mechanism that doesn't manage application lifecycle, it doesn't make sure that time is accounted for during periods where your laptop is put to sleep, it doesn't give you the API to handle such essential but mundane functionalities using 1-liners. They are to this particular problem what the kernel's syscall interface at the assembly level is to the development of web applications. It's absolutely required, but you wouldn't want to target it directly.

                      Comment

                      Working...
                      X