Announcement

Collapse
No announcement yet.

systemd 255 Released With A "Blue Screen of Death" For Linux Systems

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

  • i said non-trivial and correct. For instance the lnd autostart service i talked about earlier in my posts. Yes, it worked, it autostarted. But it was not correct, because it had to be done in a special way for systemd to communicate with the started process

    Comment


    • Originally posted by Barley9432 View Post
      You honestly have to love systemd. Their product is incredible. It shows what can be accomplished when people work together well.
      Embrace, extend, extinguish.

      Comment


      • Originally posted by gotar View Post

        Still waiting for your SysV script proving me wrong.



        Anything to back this statement up?



        Oh, they were surely experienced. Developers. Any link? I'm very curious about the problem details!
        Since my previous answer did not satisfy you, now if you are fast you can show your superiority by going and teaching arch linux developers how to tell systemd that one unit replaces an older unit. Simple, right? They failed and took a bigger hammer with drawbacks into use instead.



        Making dbus-units an empty package depending on dbus-broker-units and setting up replaces to install either dbus-broker-units or dbus-daemon-units on existing systems. This would avoid asking the user on a new installation, but I could not get the replaces to work properly.

        The status quo is that dbus-broker has to be installed and its services enabled manually.
        ‚Äč
        such simplicity and elegance that manual hacking is REQUIRED. An init script would work by default.
        Last edited by varikonniemi; 11 January 2024, 01:02 PM.

        Comment


        • Originally posted by varikonniemi View Post
          Since my previous answer did not satisfy you, now if you are fast you can show your superiority by going and teaching arch linux developers how to tell systemd that one unit replaces an older unit. Simple, right? They failed and took a bigger hammer with drawbacks into use instead.
          You seem to imply, that the init system entirely lacking dependencies is superior over a more sophisticated, because in the featured one there is a dependency problem when one of the dependencies is going to change during upgrade.

          This resembles "Windows XP is superior to Linux, because it just works, and under Linux you need to manage permissions and after su to root there's no X11 cookie and my program cannot run".

          such simplicity and elegance that manual hacking is REQUIRED. An init script would work by default.
          No - an init script doesn't have ANY reasonable way of specifying, checking or enforcing dependencies, as ANY level of hacking required to acomplish this reliably is insufficient.
          There is no such problem in SysV only because it's so hard to implement, that everyone gave up a long time ago.

          If you try to use the LSB headers for such dependency rename/replace (Required-Start: dbus-daemon) you'll fail miserably, as there are no logical operators (two optional "+" dependencies are still optional) nor any way to substitute one service for another ...unless you create some $dumb_dbus insserv, which is in principle the same as systemd solution, just more cumbersome.
          So basically in SysV world you have no choice over no dependencies at all, or even more "hackery".

          Once again you're comparing spear hunting with canned food, complaining about more sophisticated process needed (and refrigerators!)
          Last edited by gotar; 12 January 2024, 08:15 AM.

          Comment


          • No, i'm showing you how systemd is so complex, as was my first argument in this thread, that very very few people know how to use it. And usually end up wishing for the best or working around it, like here.

            Comment


            • Originally posted by varikonniemi View Post
              No, i'm showing you how systemd is so complex, as was my first argument in this thread, that very very few people know how to use it. And usually end up wishing for the best or working around it, like here.
              Don't you get or just ignore that POSIX sh (the /bin/sh) is much more complex, and any orchestration using it is virtually impossible? The number of people capable of writing correct systemd unit is several orders of magnitude larger than the same using sh. Most sh scripts in the wild as a user-provided content contains serious mistakes. Many professional project have such bugs as well. I haven't seen properly written non-trivial sh code in years. Trying to write my own reveals more and more errors as time passes. It is much easier to write reliable code in perl, even so noone tries, because this programistic approach is simply inferior to declarative syntax.

              I gave examples, you haven't related. Thus I assume you're not capable of either, especially POSIX sh.

              And you still don't understand, that this problem here was unrelated to any systemd complexity, but dependency management, which in sh is much more intricate, up to the point that noone cares. There is no systemd-workaround here. Going SysV-way would be to remove the dependency on dbus entirely and hope for things not to break, and if (when) they do - just throw a bunch of `sleep 5` stanzas wherever this seems to mask the underlying issue.

              Comment

              Working...
              X