Announcement

Collapse
No announcement yet.

Debian To Seek A General Resolution Over Their Init System Policy

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

  • L_A_G
    replied
    Originally posted by Karl Napf View Post
    ...
    Security is all fine and dandy, but when the back and forth dependencies make it incredibly difficult to implement and maintain any other solution it's hardly the fault of anyone who isn't happy about it being forced upon them like this. In this instance systemD with it's back and forth dependencies really is the source of the problem and why I keep calling it functionally monolithic.

    Leave a comment:


  • Karl Napf
    replied
    Originally posted by L_A_G View Post
    Probably the best example of this is loginD, which has literally been forced upon almost every distro due to very heavy cross-dependencies and the herculean task of avoiding it's use.
    Logind is an essential piece of software that makes Linux more secure. Developers that want to write secure software need to use it, simply because nobody can be bothered to implement and then maintain a different approach to solve the same problem.

    Basically we have a bunch of people unable to provide any idea on how to address problems that developers have and then complain that everybody uses systemd's solutions. To make things worse: Rather often the people that complain the loudest do not even understand those problems in the first place.

    Leave a comment:


  • L_A_G
    replied
    Originally posted by F.Ultra View Post
    The problem is that this "rat's nest" of yours is still unsubstantiated claims since you after all this time still do not provide any example(s), which is why people (including me) keep asking you. Also it does not follow my own experience since I use systemd as pid 1 on all of our servers and desktops but not any of the other systemd utilities so "you have to use the whole bloated mess" is not true.
    It's only "unsubstantiated" in the sense that you rather conveniently forget every example and explanation given to you. You don't just forget then in between conversations, in literally the post you're replying I pointed out that the cross-dependencies force you to pull in all of the major components and make it near impossible for third parties to replace, fork or otherwise improve parts of it.

    Probably the best example of this is loginD, which has literally been forced upon almost every distro due to very heavy cross-dependencies and the herculean task of avoiding it's use. But I guess you're probably going to continue insisting that I'm not bringing up any examples or proof of my arguments seeing how I've seen you take part in arguments about this systemD module in question.

    I could go into how the constant feature creep is not only making it a bigger and bigger attack surface, it's also making it a more and more critical one at the same time. However it's probably a waste of time when you're going to do what you always do upon reading arguments against systemD and forget it as soon as you've finished reading it.

    It's a very different issue when talking about "the implementation" which was what you claimed and what I asked details about.
    So you didn't understand the analogue, then let me spell it out as plainly as I can; Technically it's a separate issue, but when it takes place in the context of all the other issues it makes them even more serious.

    Leave a comment:


  • Karl Napf
    replied
    Originally posted by intelfx View Post
    Nope. Maintaining both packages for alternative inits and alternative init scripts for other packages is trivial.
    At least a significant number of Debian developers seems to disagree or there would not be this GR proposal in Debian.

    Originally posted by intelfx View Post
    The real effort is dealing with packages and software with non-trivial dependencies on systemd (e. g. GNOME 3). It would appear their numbers is on the rise.
    Just to quote the void linux wiki: "Installing GNOME on Void Linux is very easy"

    I do see two dependencies of 3rd party software mentioned rather regularly:
    • libsystemd: A library that is there that wraps all the code that is needed to have its dependent software work with or without systemd. I doubt this would be any problem if that library would have been called libfoobar or something... in fact even Devuan rolled back their changes to remove this dependency once they figured out that the library does nothing:-)
    • logind: A stable and fully documented DBus API with several implementations that do not need systemd to be PID1. Ok, systemd devs do not recommend that to be re-implemented elsewhere, but what do they know? Their judgement can't be trusted for anything else, so why here? :-)
    Where exactly is the problem?

    Leave a comment:


  • audir8
    replied
    Originally posted by F.Ultra View Post

    The problem is that this "rat's nest" of yours is still unsubstantiated claims since you after all this time still do not provide any example(s), which is why people (including me) keep asking you. Also it does not follow my own experience since I use systemd as pid 1 on all of our servers and desktops but not any of the other systemd utilities so "you have to use the whole bloated mess" is not true.

    The "internal API" is also just a D-Bus interface and if you check the list at https://www.freedesktop.org/wiki/Sof...tabilityChart/ you can clearly see that "Covered by Interface Stability Promise" is "yes" on all except for "udev session switch ACL properties".


    Here's the patch not applied to current master: https://github.com/systemd/systemd/b...server.c#L2187

    It's up to upstream to provide modular builds. Unless you don't consider Chromium OS to be Linux in some way.

    Leave a comment:


  • andyprough
    replied
    Originally posted by mrugiero View Post
    Addendum. I forgot to check the Windows ones. Debian got consistently better results with exceptions here and there. Nothing big tho.
    Also, I didn't think of mesa, which is quite relevant in many benchmarks, including the Selenium ones I think.
    Which also supports our argument: there are many things that may change speed in applications that we should suspect before pointing at init scripts. They're for **INIT**. They generally don't do much, and if they do they're probably broken.
    You've worked hard on this today, bravo! Good answers, very useful. That should set some readers' minds at ease.

    Leave a comment:


  • intelfx
    replied
    Originally posted by ThanosApostolou View Post
    Reading the comments (those who are relevant to the topic), I guess we can all agree that maintaining just the packages for other init systems (like openrc) is not a big deal, but the real effort is maintaining all the init scripts for the packages that need them.
    Nope. Maintaining both packages for alternative inits and alternative init scripts for other packages is trivial. The real effort is dealing with packages and software with non-trivial dependencies on systemd (e. g. GNOME 3). It would appear their numbers is on the rise.

    Leave a comment:


  • mrugiero
    replied
    Addendum. I forgot to check the Windows ones. Debian got consistently better results with exceptions here and there. Nothing big tho.
    Also, I didn't think of mesa, which is quite relevant in many benchmarks, including the Selenium ones I think.
    Which also supports our argument: there are many things that may change speed in applications that we should suspect before pointing at init scripts. They're for **INIT**. They generally don't do much, and if they do they're probably broken.

    Leave a comment:


  • mrugiero
    replied
    Besides, I'd expect Debian to be running more systemd units and fewer init scripts on newer versions, when using systemd.
    I think that's the root of this conundrum: maintainers wrote systemd units to use with systemd and nobody bothered to maintain the init scripts, or at least nobody wants to keep doing it.

    Leave a comment:


  • mrugiero
    replied
    Originally posted by andyprough View Post
    I think nearly any 2019 benchmark comparisons on Phoronix that included Buster have shown a better performance than Ubuntu and certainly than Fedora. Here are a couple I spotted:
    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

    https://www.phoronix.com/scan.php?pa...01-intel&num=7
    OK, great, you got some of the aforementioned benchmarks. Now we can talk!

    So, let's start, test by test, what a way more relevant change may there be. Hint: it will most certainly be packages versions, I'll only look them up in the relevant (Buster wins by far) cases.

    1. Selenium: Firefox.
    Version on Buster[0]: 60.6.3
    Version on Ubuntu 18.04[1]: 70.0
    Version on Ubuntu 19.04[1]: 70.0
    Version on Fedora 30[2]: 69

    Sources:
    [0]: https://packages.debian.org/search?keywords=firefox
    [1]: https://packages.ubuntu.com/search?keywords=firefox
    [2]: https://fedoramagazine.org/firefox-6...ble-in-fedora/

    What should matter the most, here? The actual application that had quite a lot of room to change, or a script run at boot time?

    2. Compile Bench:
    I won't bother, since Buster loses hard.

    3. SQLite is more or less on par, except from OpenSUSE sucking for some reason.
    Same version for everytone, according to the graph's title.

    4. ParaView. Same version for everyone, the only cases where Debian comes up first are quite marginally so.

    5. DaCapo. Buster is on the middle, losing towards all of the ones you named.
    6. Renaissance, ditto, except from two being second to Clear Linux, although by a big margin.
    7. John The Ripper. Last.
    8. SVT-AV1. middle of the table, not much difference with the worst ones. Fedora doesn't appear, Ubuntu 18.04 loses, 19.04 wins.
    9. x265 v3.0. Second to Clear Linux by ~25%, with both Ubuntus head to head.
    10. Stockfish 9. Debian just after the SUSEs, but there doesn't seem to be a big difference in any case.
    11. LLVM Compilation. Debian is second to Ubuntu 19.04, so let's check versions again. This is unclear as to what compiler suite they use, so I guess I'll be checking GCC and Clang.

    Buster: Clang=1.70 GCC=4.8.3.0
    Ubuntu 18.04: Clang=6.0 GCC=7.4
    Ubuntu 19.04: Clang=8.0 GCC=8.3
    Fedora 30: Clang=8.0 GCC=9

    12. XZ Compression v5.2.4. Buster does better than the aforementioned (SUSE and Clear win, tho). I'm unconvinced that init script have any effect on this, since it's quite standalone. It's most likely related to either libc or faster IO.
    13. Hackbench. Buster is third to last. Fedora sucks hard for some reason. I have no idea what this bench is about, so I won't search.
    14. libjpeg-turbo. Fedora, Ubuntu 19.04 and Buster are first, within standard deviation of each other. Makes sense since most of it is manually optimized SIMD, and is the same version.
    15. Stress-NG. Buster is consistently at the middle of the table or below. I have no idea what it does, tho.
    16. IndigoBench. Buster does better than the previous. It seems to be some sort of rendering? I fail to see any reason why init scripts would affect this.

    From now on I'll just state results because I got severely bored.

    17. Blender. Middle tier.
    18. Appleseed. Middle and up.
    19. PHPBench. Done quite good, although not as good as Clear.


    The point of this long post is:
    1. Correlation does not imply causality.
    2. When lacking enough evidence, we should either avoid making any judgement at all, or at least go for the simpler ones first.
    3. I still don't see a "beats Fedora and Ubuntu easily" from these results. It's not like it's consistently 10% faster or anything.

    I recommend the following video on performance: https://www.youtube.com/watch?v=r-TLSBdHe1A

    Originally posted by andyprough View Post
    There are more if you want to look around the site. Clearly the sloppy/messy scripts that are complained about so much on this thread have had no negative effect, and in fact are probably helping the system as a whole to run better than the vanilla system-D distros.
    I'm unsure if this part is sarcasm.

    Leave a comment:

Working...
X