If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
I think it's absurd that to run a DE you have to change your sysvinit, it's an artificial dependency and I don't like the idea not one bit, makes the whole " Linux is modular independent and promotes choice" argument void. As he said, this is the true reason systemd HAD to be chosen:
BTW, those of you that still think systemd was chosen over OpenRC for technical merits read the Debian page on it: https://wiki.debian.org/Debate/initsystem/openrc The only true disadvantage it had to systemd was lack of socket activation. Except for that OpenRC does all the shiny new stuff that systemd brags about and is still portable to non-linux platforms, that is essential for both Gentoo and Debian. So why did Debian choose systemd over OpenRC? POLITICS!!!!
as a gentoo user with around 10 years i call this post bullshit from the first letter to the last,
1.) OpenRC is faster than sysV for a bit since some time ago or so but is at least 5 times slower at everything with normal HDD and at least 10-20X on SSD compared to systemd
2.) OpenRC is not compatible with PID1 Cgroups/policy/etc as far as i tested
3.) OpenRC process tracking cannot be trusted at all, because like sysV and upstart fails a fucking lot specially if is not an direct child's forked process and emit signals or get circularly looped or stalled threads or ....
4.) If openrc supported or support some kind of service event triggering at all was hidden in the code or was included last week since i have ages asking how to do this to save resources on my clouds since forever and the answer was always the same shell/C trickery to fake it[ofc systemd solve it so i don't care anymore]
5.) im pretty damn sure openRC cannot detect that is running in a virtualized enviroment[in systemd works like a charm if anyone doing more than porn in their PC's was interested to know]
6.) openRC don't support timed services without some f/d/c/r/t/a/cron magic
7.) openRC stop logging after any init change and won't start until very late in the boot process with /ng/r/syslog ofc
8.) openRC don't provide any API to generate/track/follow/attach process programmatically
9.) openRC don't handle process separation or hardening at all[gentoo does it with externals tools if you have the guts to maintain it] but openRC itself don't give a damn about security or session trusts
etc,etc,etc,etc,etc, sure as an init system is good but never even in the same class systemd is, but anyway i doubt anyone in this thread will listen to technical reasons at all since lennart name was written this thread was sentenced to be taken by zealot and trolls that ironically can't even understand technical matters beyond "we hate lennart because of reasons"
This reminds me of end of Half Life 2: "Rather than offering you the illusion of the free choice, I'll take the liberty of choosing for you."
I can never remember a time when you really had a choice of Init system. For most of the last 20 years there has only been sysvinit. Upstart did come along but changing an init system isn't something that people do for fun so not many other distro's put the time and effort into making it work for them. By the time the all agreed they needed a new one systemd had come along and seemed to be more viable than upstart, who development seemed slow by comparison. OpenRC IS a choice but because there is little documentation it makes it harder for most distros to make any sort of argument for switch or including it as an option. Lastly though most users don't WANT to have to think of their init system and providing options would confuse most linux users let alone anyone switching from Windows or OSX
Probably not obvious to all readers, but the fact that all major Linux distros now run systemd means that it gets larger amount of testing and will be the best init system from now on. Security holes can be fixed one by one until they're all fixed. Event based init systems also work better with surprising events like usb hotplug, disk hotplug, hibernation, bluetooth device scan and wifi scan. Maybe at some points all applications start to enforce Systemd backend but by then it will be even faster and leaner and get modules for more functionality. The kdbus plugin might help quite a bit already.
This also makes it almost guaranteed that SteamOS will be using systemd in the future.
How do you know which programs will adopt systemd? Will GCC or LLVM need systemd? openssh? OpenMosix? FreeNX? Printing applications? What kind of functionality does systemd offer in general or is it meant to support all use cases with plugins?
Comment