Page 9 of 10 FirstFirst ... 78910 LastLast
Results 81 to 90 of 99

Thread: X.Org Server Systemd Integration Proposed

  1. #81

    Default

    Quote Originally Posted by jrch2k8 View Post
    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.

    Quote Originally Posted by jrch2k8 View Post
    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.

    Quote Originally Posted by jrch2k8 View Post
    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).

    Quote Originally Posted by jrch2k8 View Post
    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.

  2. #82
    Join Date
    Nov 2012
    Posts
    210

    Default

    Quote Originally Posted by ncopa View Post
    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?

  3. #83
    Join Date
    Sep 2012
    Posts
    781

    Default

    Quote Originally Posted by ncopa View Post
    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".

  4. #84
    Join Date
    Mar 2011
    Posts
    396

    Default

    Quote Originally Posted by ncopa View Post
    do you have any suggestions how to run my XFCE who *cannot* use systemd?
    Maybe you should start by telling why your XFCE can't use systemd. My XFCE uses systemd just fine, example:
    Code:
    $ emerge -pv xfce4-session
    
    These are the packages that would be merged, in order:
    
    Calculating dependencies... done!
    [ebuild   R    ] xfce-base/xfce4-session-4.10.1  USE="systemd udev xscreensaver -debug" 0 kB
    
    Total: 1 package (1 reinstall), Size of downloads: 0 kB

  5. #85
    Join Date
    Jan 2011
    Posts
    1,287

    Default

    Quote Originally Posted by Daktyl198 View Post
    Would it even be an optional "dependency"? From what I can tell, it only provides integration if you use systemd, it doesn't try to force it on you or allude that X works better with systemd.
    That's the definition of optional dependency, having an optional feature depending on having systemd installed. You can't use systemd integration without systemd, I thought it was pretty obvious.

  6. #86
    Join Date
    Jun 2013
    Posts
    115

    Default

    Quote Originally Posted by TAXI View Post
    Maybe you should start by telling why your XFCE can't use systemd. My XFCE uses systemd just fine
    Because he's on Alpine Linux. Basically trying to run linux on 20 year old hardware so it uses things like uClibc and BusyBox

  7. #87
    Join Date
    Jan 2011
    Posts
    1,287

    Default

    Quote Originally Posted by Scimmia View Post
    Because he's on Alpine Linux. Basically trying to run linux on 20 year old hardware so it uses things like uClibc and BusyBox
    In that case, he just have to make sure the Alpine folks don't adopt systemd, which they probably won't. What's the matter?

  8. #88
    Join Date
    Jun 2013
    Posts
    115

    Default

    Quote Originally Posted by mrugiero View Post
    In that case, he just have to make sure the Alpine folks don't adopt systemd, which they probably won't. What's the matter?
    That's the whole point of why he doesn't want X to have a hard dep on systemd.

    Of course, running X on Alpine systems seems foolish to me anyway.

  9. #89
    Join Date
    Jan 2011
    Posts
    1,287

    Default

    Quote Originally Posted by Scimmia View Post
    That's the whole point of why he doesn't want X to have a hard dep on systemd.

    Of course, running X on Alpine systems seems foolish to me anyway.
    Yes, but he's also reading the article wrongly. The article never claims X will depend on systemd.

    EDIT: Why would it be foolish to run X on Alpine systems? Running an older machine doesn't have to involve using CLI only interfaces. X11 exists since the '80s, after all.

  10. #90
    Join Date
    May 2013
    Posts
    618

    Default Dummy packages can bypass unused "dependencies"

    Quote Originally Posted by prodigy_ View Post
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •