Originally posted by Karl Napf
View Post
Announcement
Collapse
No announcement yet.
Debian To Seek A General Resolution Over Their Init System Policy
Collapse
X
-
- Likes 1
-
Originally posted by L_A_G View PostProbably 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.
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.
- Likes 2
Leave a comment:
-
Originally posted by F.Ultra View PostThe 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.
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.
- Likes 1
Leave a comment:
-
Originally posted by intelfx View PostNope. Maintaining both packages for alternative inits and alternative init scripts for other packages is trivial.
Originally posted by intelfx View PostThe 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.
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? :-)
- Likes 1
Leave a comment:
-
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:
-
Originally posted by mrugiero View PostAddendum. 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.
- Likes 1
Leave a comment:
-
Originally posted by ThanosApostolou View PostReading 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.
- Likes 3
Leave a comment:
-
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.
- Likes 2
Leave a comment:
-
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.
- Likes 2
Leave a comment:
-
Originally posted by andyprough View PostI 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
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 PostThere 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.
- Likes 2
Leave a comment:
Leave a comment: