Originally posted by Nuc!eoN
View Post
Announcement
Collapse
No announcement yet.
X.Org Server Systemd Integration Proposed
Collapse
X
-
Originally posted by rudregues View Post
Comment
-
Note in my previous post I somehow thought I was on the Debian voting init system thread. Still, change the point on Debian avoiding systemd for X.org rejecting the patches, assuming it's a build time option. If it's making it a hard dependency, then I agree that there is some serious problem here with invading. Specially as systemd doesn't run outside of Linux, and making X11 depend on it would involve not being able to use X11 outside of Linux.
Comment
-
Originally posted by rudregues View PostOk, I was being ironic criticizing systemd with my previous post... To note:
Systemd is written in C, where others are shell scripts of different sorts.
Mind you, each shell script causes shell process to spawn. Count that LoC for every instance together.
And uses different coreutils and linux-ng tools. Add this.
And they all use standard libraries.
In the end, unrolled within machine, they end up having similar or even more LoC, much more overhead, much less efficient integration.
Where systemd truly distances itself, is that it does not reuse same "universal" isles via lousy spaghetti of shell code, but instead creates linear, structured subsystem with distinguished configurable parts.
As what an init system does, is pretty much settled over years and ability to "rewire" just everything is hardly a use case, why not?
I came to understanding that if one needs more than several shell instances, especially in efficiency-critical places, then one does it wrong. Why spawn a mirriad of shell clones just for the reason of executing a few lines? Why limit ourselves to capabilities and inefficiencies of a shell?
Only BSD-init can concurrent with systemd in terms of overhead, but in terms of features BSD-init looses hands down.
Originally posted by rudregues View PostThe problem with systemd is some invasive politics of development. It is modular just internally.
Also, why not to join systemd developers as a "othersystem" crew ?
The only two requirements are: ability to keep the pace and to never ask for feature degradation via "legacy" argument.
My understanding is that current team focuses on "Linux" target, its their right to do so.
Comment
-
Originally posted by mrugiero View PostIf it's making it a hard dependency, then I agree that there is some serious problem here with invading.
Which brings us back to systemd that tries to usurp the entire userland, not just the DE. Of course Lennart didn't invent hijacking via false dependencies. I believe Canonical was the first to do that when they made plymouth a hard dependency for mountall in Ubuntu 10.04. Gotta give them credit, that was brilliant. Wanna uninstall crap we're forcing down your throats? Fine, but your system won't boot anymore.
The really hilarious (and sad) part of all this is that people will scream bloody murder - tomorrow when it's too late and Red Hat makes or influences all userland-related decisions. And you know who will cry the loudest? The same rabid systemd fanoboys who readily accept all the crap coming from Lennart & Co. today without even thinking of long-term consequences.
Comment
-
I wonder why all the systemd hate. Sometimes you need to politically force a technically superior technology. For example, without pulseaudio you can't switch from Hi-Fi near field monitors to headphones without shutting down apps. I don't give a s*it about latencies. Pulseaudio allows switching the audio device and it can also interface with proprietary protocols such as AirPlay. This is something worth enforcing, starting from kernel level.
Comment
-
Originally posted by caligula View PostI wonder why all the systemd hate. Sometimes you need to politically force a technically superior technology. For example, without pulseaudio you can't switch from Hi-Fi near field monitors to headphones without shutting down apps. I don't give a s*it about latencies. Pulseaudio allows switching the audio device and it can also interface with proprietary protocols such as AirPlay. This is something worth enforcing, starting from kernel level.
Comment
-
Originally posted by Vim_User View PostIf you want to be forced to have a single solution without alternatives you should rather go for Windows or OS X.
Comment
-
Originally posted by caligula View PostSometimes you need to politically forceLast edited by prodigy_; 28 January 2014, 03:18 AM.
Comment
-
Originally posted by prodigy_ View PostPlease go back to Windows. Because this is precisely the kind of crap we need an alternative for. The whole reason for Linux existence used to be that nobody could force anything upon the community. And now people talk about freedom in the FOSS more than ever yet somehow they're ready to surrender what's left of that freedom without a fight.
Comment
Comment