Announcement

Collapse
No announcement yet.

X.Org Server Systemd Integration Proposed

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #76
    Originally posted by dee. View Post
    Well that sounds nice and all but in practice it's just not happening.

    PA can definitely be used as a frontend and backend for casual desktop use, like video/music playback, desktop sounds or such. But it will never be useful as a frontend for actual, serious audio applications. Because the needs are just too different.

    In fact, the Jack webpage explains this difference quite well:
    Fully agreed.
    I think PA makes sense as the default, and if you have niche needs, there are better alternatives.
    So I think the situation is pretty good all in all.

    Comment


    • #77
      Originally posted by Vim_User View Post
      This! They didn't make a hard dependency for systemd in Wayland, so why should they do that in Xorg?
      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.

      Comment


      • #78
        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.
        Well, X does work better with systemd, by virtue of being able to operate without root privileges.

        Comment


        • #79
          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, so they tend to whine about thing they probably won't ever touch in their life for whatever reason they read for any random troll here and there which 99% of the time are totally wrong.

          so in the end they blame systemd for the lazyness of other init systems devs.

          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+)
          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
          3.) network init at early boot stages is a bloddy hell of a mess/bonding is like calling satan to your home!!! blame systemd ofc for fixing it and then lay control to networkmanager later in the boot process, blame you lennart you so evil
          4.) journal is binary OMFG, lennart is the devils spawn!!! ohh wait syslog still works perfectly fine(give lots less info than journalctl) and it never started that early in the boot process or stay alive during shutdown process or have a nice dbus API or give easy search functions(without 2 pHD in grep/sed engineering) and never played well with other log Systems like rsyslog and never was standard among distros(rsyslog/syslog/syslog-ng/etc)
          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
          6.) etc,etc,etc,etc blah blah blah lets go political besucase i can't understand any of the above, just to not look stupid
          7. The purpose of the ingration between Xserver and systemd is to run Xserver without root privileges. So, if the problem is choice, blame systemd for offering this choice.

          Edit: I didn't see the post of GreatEmerald.

          Comment


          • #80
            Originally posted by GreatEmerald View Post
            Well, X does work better with systemd, by virtue of being able to operate without root privileges.
            X can be run as a normal user
            it only requires KMS to be used, that binary drivers don't support

            edit: more about it
            https://wiki.ubuntu.com/X/Rootless
            Last edited by gens; 01-29-2014, 07:08 AM.

            Comment


            • #81
              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.

              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.

              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).

              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.

              Comment


              • #82
                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?

                Comment


                • #83
                  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".

                  Comment


                  • #84
                    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

                    Comment


                    • #85
                      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.

                      Comment


                      • #86
                        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

                        Comment


                        • #87
                          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?

                          Comment


                          • #88
                            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.

                            Comment


                            • #89
                              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.

                              Comment


                              • #90
                                Dummy packages can bypass unused "dependencies"

                                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.

                                Comment

                                Working...
                                X