Debian To Seek A General Resolution Over Their Init System Policy

[andyprough]

Oh I'm totally against Devuan myself, I can only be happy if they blow up.

And I wouldn't mind seeing some core services of Debian actually switch to proper systemd units.

Debian Buster is beating Ubuntu and Fedora performance in benchmarks pretty easily these days. Have to wonder if there's some performance issue with how different systems approach the system-D problem.

[mrugiero]

Debian Buster is beating Ubuntu and Fedora performance in benchmarks pretty easily these days. Have to wonder if there's some performance issue with how different systems approach the system-D problem.

Which benchmarks? Testing what?
Unless otherwise proved, I'm inclined to believe Ubuntu just takes most of it as-is from Debian.

[starshipeleven]

Debian Buster is beating Ubuntu and Fedora performance in benchmarks pretty easily these days. Have to wonder if there's some performance issue with how different systems approach the system-D problem.

That's a load of bullshit. Init systems have no relevance for application performance.

[F.Ultra]

Apparently you either missed or don't seem to understand the word "functionally" as I've used it every time I've described my issue with the way they have loads of unnecessary dependencies back and forth across the project. So while it technically isn't monolithic, the back and forth dependencies means that you have to use the whole bloated mess and as they're suffering from an ongoing case of feature creep the mess is only getting more and more bloated as time goes on. Also, as I've explained to you before those internal APIs are what's known as "unstable" APIs, i.e they're subject to constant change meaning that they're useless to any outside projects that may want to replace, fix, de-bloat or extend functionality.

In outer words; While it's not technically monolithic, the way it's implemented as a rat's nest of back and forth dependencies using unstable APIs it may just as well be because from the perspective of anyone on the outside, it's what's known as a "Distinction without a difference".

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".

It's about as separate an issue as a regular drunk driver driving on bad tires. Both are bad, but when combined they only make each other worse.

It's a very different issue when talking about "the implementation" which was what you claimed and what I asked details about.

[andyprough]

That's a load of bullshit. Init systems have no relevance for application performance.

It's not the init system itself. It's all the work-arounds that have to be in place to keep running despite the system-D problem. That's probably where the performance regressions lie.

[starshipeleven]

It's not the init system itself. It's all the work-arounds that have to be in place to keep running despite the system-D problem. That's probably where the performance regressions lie.

That's a load of bullshit. Init systems have no relevance for application performance.

[mrugiero]

It's not the init system itself. It's all the work-arounds that have to be in place to keep running despite the system-D problem. That's probably where the performance regressions lie.

Provide the said benchmarks and then we can have an informed opinion.
Otherwise, provide examples of such workarounds that may cause performance regressions.
I don't expect many differences in IO or network, since systemd mostly do setup for these (except resolved, but I believe none of those distributions use it by default), so it shouldn't interfere in operation.
I also tend to believe Ubuntu uses most of it as is, simply because the whole point of being a Debian derivative is to avoid pointless duplication of effort, which removing the workarounds would probably be, and even in this case, Debian is the most likely to work around things because Debian is the one that doesn't explicitly tie to one particular system, and I'd expect workarounds to slow down things, not to speed them up.
Point being, just asserting "it did better on benchmarks" without linking to them won't convince anybody.

[starshipeleven]

Provide the said benchmarks and then we can have an informed opinion.
Otherwise, provide examples of such workarounds that may cause performance regressions.
I don't expect many differences in IO or network, since systemd mostly do setup for these (except resolved, but I believe none of those distributions use it by default), so it shouldn't interfere in operation.
I also tend to believe Ubuntu uses most of it as is, simply because the whole point of being a Debian derivative is to avoid pointless duplication of effort, which removing the workarounds would probably be, and even in this case, Debian is the most likely to work around things because Debian is the one that doesn't explicitly tie to one particular system, and I'd expect workarounds to slow down things, not to speed them up.
Point being, just asserting "it did better on benchmarks" without linking to them won't convince anybody.

in case this was too long to read, here is a tl;dr of what he said:

That's a load of bullshit. Init systems have no relevance for application performance.

[andyprough]

Provide the said benchmarks and then we can have an informed opinion.
Otherwise, provide examples of such workarounds that may cause performance regressions.
I don't expect many differences in IO or network, since systemd mostly do setup for these (except resolved, but I believe none of those distributions use it by default), so it shouldn't interfere in operation.
I also tend to believe Ubuntu uses most of it as is, simply because the whole point of being a Debian derivative is to avoid pointless duplication of effort, which removing the workarounds would probably be, and even in this case, Debian is the most likely to work around things because Debian is the one that doesn't explicitly tie to one particular system, and I'd expect workarounds to slow down things, not to speed them up.
Point being, just asserting "it did better on benchmarks" without linking to them won't convince anybody.

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:

https://www.phoronix.com/scan.php?page=article&item=linux-july-2019&num=7

https://www.phoronix.com/scan.php?page=article&item=win10-debian101-intel&num=7

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.

[mrugiero]

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:

https://www.phoronix.com/scan.php?page=article&item=linux-july-2019&num=7

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

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.