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 the problem radicate in the fact most people don't have the background needed to understand why systemd do what it does,

That and the traditional fear of changes.

Originally Posted by jrch2k8

facts:
1.) CGroups was declares a security bug by kernel devs: only systemd devs responded to the call to find a proper and secure solution (PID1 in 205+)

Too bad I cannot use systemd as they dont support my libc.

Originally Posted by jrch2k8

2.) consolekit is dead for more than a year!!! blame systemd because they are the only ones around proposing an far superior solution that even canonical has to accept for thecnical reasons

Too bad I cannot use systemd. Are there any other options, even if they are technically inferior? Oh, i should write my own consolekit implementation.. oh, i shoudl write my own logind too while at it. oh i will do that as soon I am done with my own udev implementation (which broke for me as a consequence of merging it to systemd build tree).

Originally Posted by jrch2k8

5.) Dbus in kernel OMG the heaven will fall!!! ohh, wait basically every linux app on existance uses dbus and the kernel didn't like the idea because lennart poisoned their corn flakes but because kernel IPC is quite obsolete and slow and porting dbus to a lower layer will allow for way more performance and security plus regular apps won't even notice and kernel deis can take that train and improve a lot of subsystem suffering from IPC performance issues, well WTH lets blame lennart either way

I disagree with this. The need of (userspace) dbus to boot anything is/was one of the motivators for me to stay away from systemd.

If xorg will depend on systemd like the article claims, do you have any suggestions how to run my XFCE who *cannot* use systemd? First udev, then GNOME now potensially xorg. Where will it stop?

oh.. i will have to write my own xorg implementation too. ok will do so as sson as I am done with my udev, consolekit, polkit and logind implementations.

I am not suprised that people (who have other values than systemd dev) get worried.

If xorg will depend on systemd like the article claims, do you have any suggestions how to run my XFCE who *cannot* use systemd? First udev, then GNOME now potensially xorg. Where will it stop?

oh.. i will have to write my own xorg implementation too. ok will do so as sson as I am done with my udev, consolekit, polkit and logind implementations.

I am not suprised that people (who have other values than systemd dev) get worried.

Where did you get the idea that you will need systemd for Xorg? As far as I can tell from looking at the patch set, this only adds the *option* of systemd socket activation.
But I guess we don't like choices in Linux, right?

If xorg will depend on systemd like the article claims, do you have any suggestions how to run my XFCE who *cannot* use systemd?

It's an optional dependency, so you should be fine, but one solution, if your system is working now, is to stop updating it. That way it will keep working regardless of systemd.
There are only two ways of dealing with some software A that is not compatible with a newer version of some software B (and it happens all the time): either you change A, or you don't update B, and A becomes "legacy".

Dummy packages can bypass unused "dependencies"

Originally Posted by prodigy_

Speaking of dependencies, does anyone here remember that Gnome 3 depends on pulseaudio? Well, Cinnamon developers said that in v2.0 they got rid of Gnome stuff but guess what? Cinnamon 2.0 still depends on pulseaudio. Nice, eh? It's very easy to add false dependencies but not so easy to get rid of them further down the road.

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.

Some of these dependancies make sense, some do not, and then there are the undeclared dependancies. I will not present examples of each.

Mountall uses Plymouth to talk to the user, so does Cryptsetup in Ubuntu. I don't know a whole lot about mountall, but I know a lot about cryptsetup and have written my own plymouth theme (greentree). To allow interaction of mountall or cryptsetup with Plymouth not installed as opposed to splash not shown would require writing extra code into the binary or scripts. I know this because I have my own program for starting encrypted disks, and I too used the Plymouth commands for handling passphrases, meaning my package also depends on Plymouth. I added echo alongside plymouth --display-message so the output is readable on console. Plymouth works fine for accepting output from console with the splash not showing. On the other hand, to accept passphrases with or without Plymouth would have required checking to see if Plymouth is installed (or if it is running), then case-switching the input mode between plymouth --ask-for-password and something else. The code would grow fast as I tried to include more options, and each possible case would have to be tested. Thus it makes sense to depend on plymouth rather than attempt to support both cases. A splash screen need not be running and no theme for one need even be installed.

Now I will discuss a false dependancy: Cinnamon and Pulseaudio. If you run Cinnamon with pulseaudio removed (or the binaries deleted/made not executable), the only things that don't work are the cinnamon volume control and cinnamon sounds. Those sounds depend for some reason on canberra-pulseaudio, but the DE as a whole does NOT need these sounds to be a good, functional desktop. Cinnamon-control-center depends on Pulseaudio, presumably to be able to control Pulseaudio. My guess is that with Cinnamon using Pulseaudio for sound events, plus the volume control applet being presumably a port of GNOME's PA-only volume control, they decided the easy way was to make the whole deal depend on Pulseaudio. Since I do not use Pulseaudio, I ended up making a dummy "pulseaudio-dummy" package that "provides" pulseaudio but is an empty package. I use Volti for a volume control, probably should list that as a dependancy. Cinnamon could split out sound into a "cinnamon-sounds" package and then depend on either PA or Volti, but that would be extra work for a small number of users. That being so, I fixed this myself for my own use.

I remove Pulseaudio because I need the utter maximum performance when dealing with cranky AVCHD files in video editing. Not having it on my netbook is a nusiance as that machine lacks hardware audio mixing, yet it also doesn't have enough CPU to run pulseaudio and decode 720P H264 video at the same time and video is the priority. I use JACK to allow mono sountracks to be played on it.

Making dummy packages to counter these sort of dependancies works so long as the package you are trying to get to install does not require the program you are bypassing simply to run. For instance, if Cinnamon-session waited for Pulseaudio to come up, then a custom session would become needed to run a Cinnamon desktop without Pulseaudio. Its package would need to "provide" cinnamon-session if you don't want to have two sessions, only one of which works, installed.

The flip side of this coin is undeclared dependancies, where a package installs just fine but won't run until another package is installed. Again there is an example in Cinnamon: Cinnamon recommends cinnamon-screensaver, does not depend on it. Beginning at about version 2.05, the cinnamon-session would not start if the screensaver was not installed, even though Cinnamon could be run by changing into it from another session (at least those that don't either respawn or kill X). Lots of people do not set the package manager to treat recommends as dependancies to keep out packages they do not use. The only reason I was ever able to find that one was that it is recorded in .xsession-errors.

The Cinnamon devs have a hell of a lot on their plate, having to revert all those tablet-style changes in GNOME that users of traditional desktops don't want, yet keep up with the backend side of everything. I'll take a little dependency hacking over perfect installer settings but a DE that is crashy from inadequate development and testing any time. I am quite happy with Cinnamon's performance on any machine that can handle gnome-shell.