Announcement

Collapse
No announcement yet.

Systemd 199 Has Its Own D-Bus Client Library

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

  • #46
    Originally posted by frign View Post
    Strict separation of configuration and shell-scripts means that you have two folders for either configuration (/etc/conf.d/) and shell-scripts (etc/init.d). This is unique and is actually a feature systemd doesn't have, because it has a different approach (I don't want to evaluate this in any way).
    Eh? systemd doesn't have shell scripts to begin with, and all the unit files are in either /usr/lib/systemd/system or in /etc/systemd/system, depending on whether they shipped with the software or manually defined by the user.

    Comment


    • #47
      Originally posted by frign View Post
      I also don't quite grasp how PulseAudio is supposed to save energy when it builds upon the ALSA-interface anyway. How can a sub-element of something be less efficient than it? Please tell me.
      Buffers, zero-copy architecture, efficient CPU usage. A few months back someone ran a few tests using Pulseaudio vs whatever Android's audio layer is (im blanking on the name.) Pulse had fewer wakeups during audio thanks to efficient buffer management and the fact it was more memory efficient, therefore more power efficient. Its not a matter of the drivers themselves and the HARDWARE power management, its the effect on the CPU and how often its causing wakeups and making the CPU kick up from idle. You can look up the full article on how the tests were run and what each test measured / showed on lennarts blog.

      Comment


      • #48
        Originally posted by Ericg View Post
        I'll go back and look, must've just missed your post.


        One point I want to specifically address is point 2), because it is in my opinion a very important one: udev is thought to be the user-space implementation of the device-filesystem of the Kernel. A few years ago, udev was all in-kernel and managed in the kernel.org repositories, until being eventually factored out for external development.
        In the last few months, udev has seen the dramatic development of dropped backwards-support and systemd-specific behaviour, rendering it a systemd-project right-away and covering up the real intention of this project: To be one suitable for general userspace, and not a sub-project of _one_ init-system.
        There is actually a heated debate to merge udev and eudev into a new Kernel-repo (which I would support) and actually doing the development in the kernel.org-repositories; the way it worked for years.

        I hope my points have become clear. If you want to hear my specific opinion or get some information regarding eudev, please just ask me
        The one problem I have with udev in kernel is the kernel's forced backwards compatibility until Linus is dead. I agree that there should be an acceptable level of backwards compatibility, but Linus' current attitude is "Youre gonna live with your mistakes until I'm dead and a new lead takes over." Which is in a way...stupid. What are the odds that the person is going to be running an ANCIENT version of udev..but on a modern kernel? That just doesnt make sense, even RHEL updates its pieces to where that doesn't happen.

        If you took out all of the code in kernel that is only there as wrapper functions for backwards compatibility, or other such BC-enablers, its probably a non-trivial amount of code. And I'd hate to see udev or anything else get stuck in this vicious circle of "Well we royally screwed up our design in hindsight...but we cant do a damn thing about it because of backwards compatibility." That just leads to ugly codebases.

        I know the udev guys got flamed by Linus a few months back because of a change they did that they knew would break existing systems. The problem was..the change was needed. It made sense to change it. But instead they got flamed by Linus basically going "Nope! Fuck you! BC4Evar!"

        Just to make this clear-- I'm a developer, but not for any of the projects being discussed. I've got no dog in any of the debates going on, and couldnt really care less whether I'm using udev or eudev, upstart or systemd. I use whatever has the most features / makes the most sense / works the best / seems to have the most "right" architecture. Whether its minimal or not. I tried stock alsa when Pulse was still being worked out (early ubuntu 9.10, and 9.04), I tried setting up OSSv4 on an Arch but it didnt work at all. I ran openrc on arch and gentoo, I ran upstart on fedora and ubuntu, and i've run systemd on arch, fedora and opensuse...so far, systemd has worked the best and most consistent with the most useful features.[/QUOTE]

        FWIW, Linus' approach is interesting. Most of his companions appear to be machines rather than real people, so I like to see the human-factor of Linus playing the biggest role in the development.
        The main premise of Kernel-development is not to break user-space, so it makes sense. This doesn't mean that the Kernel is being slowly developed or inefficient, because everyone is free to drop this support.

        In case of udev, backward compatibility is important because it is just such an essential software. My system runs without it, but I use it anyway to have my devices set up properly without required manual work or self-written node-scripts.

        Comment


        • #49
          Originally posted by GreatEmerald View Post
          Eh? systemd doesn't have shell scripts to begin with, and all the unit files are in either /usr/lib/systemd/system or in /etc/systemd/system, depending on whether they shipped with the software or manually defined by the user.
          And? I never stated to evaluate it; I pointed out configuration and code was separated.

          Comment


          • #50
            Originally posted by frign View Post
            ...covering up the real intention of this project: To be one suitable for general userspace, and not a sub-project of _one_ init-system.
            Who exactly gets to decide what are the "real" intentions of the project? Kay Sievers has been the maintainer and has done most of the udev developement since 2004. He's also the one who merged the project to systemd. Greg Kroah-Hartman who started the project in 2003 has also been supportive of the move. Those two developers have done something like 85 to 90% of udev developement in the past nine years; mostly Kay though. Also udev is still supported outside of systemd.

            Originally posted by frign View Post
            There is actually a heated debate to merge udev and eudev into a new Kernel-repo (which I would support) and actually doing the development in the kernel.org-repositories; the way it worked for years.
            Where?

            I fetched the 132k lines of code even excluding udev, because I look at it as a separate project. I included the optional dependencies, because you are using them as a basis for this discussion, forcing me to include them in my means of argumentation.
            Could you show the breakdown of that 132k lines of code? What optional dependecies did you include?

            Points you are missing is that power-consumption is already levelled sufficiently in the device-specific ALSA-drivers in-Kernel...
            No it isn't. Some of the key parts like mixing isn't done in kernel by Jack, ALSA (dmix) or PulseAudio. Here's a blog post about saving power by using PulseAudio.

            ...and that Jack is a Daemon not entirely situated in user-space, but also incorporated into the Kernel (which gives an insight into how the Linux-devs might look at PulseAudio).
            What exactly are you saying? Both Jack and PulseAudio use the ALSA userspace libaries to talk to the kernel ALSA drivers. I have no idea what you mean by how Linux-devs might be looking at PulseAudio.

            Concerning security, I would definitely choose an interface which is part of the Kernel and the highly-efficient bug-tracking system of it than some interface developed by a handful of individuals who strive for a certain appeal of reinventing the wheel.
            What I meant by security was this:

            If processes that have real-time scheduling privileges enter a
            busy loop they can freeze the entire the system. To make sure
            such run-away processes cannot do this RLIMIT_RTTIME has been
            introduced. Being a per-process limit it is however easily
            cirumvented by combining a fork bomb with a busy loop.

            RealtimeKit hands out RT scheduling to specific threads that
            ask for it -- but only to those and due to SCHED_RESET_ON_FORK
            it can be sure that this won't 'leak'.
            It's something that Jack to my understanding doesn't do.

            Comment


            • #51
              Originally posted by Ericg View Post
              Buffers, zero-copy architecture, efficient CPU usage. A few months back someone ran a few tests using Pulseaudio vs whatever Android's audio layer is (im blanking on the name.) Pulse had fewer wakeups during audio thanks to efficient buffer management and the fact it was more memory efficient, therefore more power efficient. Its not a matter of the drivers themselves and the HARDWARE power management, its the effect on the CPU and how often its causing wakeups and making the CPU kick up from idle. You can look up the full article on how the tests were run and what each test measured / showed on lennarts blog.
              Pulse Audio and efficient CPU usage don't belong in the same country. Let alone the same sentence.

              EDIT: I mean that must be a blatant flat out lie. There's just no way that you could -not- know how wrong that is.

              Comment


              • #52
                Originally posted by Teho View Post
                Same goes for socket based boot up as you can discover here. I would assume that same goes for cgroups too; or can you just set cgroup attributes on runtime by using something like this "systemctl set-cgroup-attr foobar.service cpu.shares 2000"? Not only that but systemd supports dependency based service startup and I'm not exactly sure what you mean by strict separation of configuration and shell and transparent networking and so on. I remain somewhat skeptical that those are things that you couldn't do with systemd.
                Systemd is like that. They don't have any dependency on a shell so the configuration has always been separated in Systemd. That line about separation in the configuration from the shell probably is tailored against the old shell based inits. It smell copy past from some sort of openrc propaganda material...

                Comment


                • #53
                  Originally posted by duby229 View Post
                  Pulse Audio and efficient CPU usage don't belong in the same country. Let alone the same sentence.

                  EDIT: I mean that must be a blatant flat out lie. There's just no way that you could -not- know how wrong that is.
                  I just pulled up htop and checked pulse's CPU usage while playing music-- sorted by CPU%, pulse was at the bottom of the list alongside packagekit (idle) and samba (no connections sending or receiving). If pulse is spiking your CPU or someone elses CPU its from buggy drivers or bad configurations (very possible. Check the arch wiki, pulse's defaults dont work on all cards. Sometimes they need adjusting)

                  Comment


                  • #54
                    Originally posted by Ericg View Post
                    A few months back someone ran a few tests using Pulseaudio vs whatever Android's audio layer is (im blanking on the name.)
                    Here's the blog post (PulseAudio vs. AudioFlinger: Fight!). It's already over year old though.

                    Originally posted by duby229
                    Pulse Audio and efficient CPU usage don't belong in the same country. Let alone the same sentence.
                    It's one of its key design goals. It's also why it could be used in Maemo/MeeGo/webOS... mobile platforms. Here's a blog post showing power savings over plain ALSA with PulseAudio.

                    Originally posted by frign
                    And? I never stated to evaluate it; I pointed out configuration and code was separated.
                    Well you can separate the ExecStart=, ExecStop=, WantedBy=... lines of other configuration lines by adding a ".../foobar.service.d/*.conf" file if you so desire.

                    Comment


                    • #55
                      clearing things up

                      Originally posted by Teho View Post
                      Who exactly gets to decide what are the "real" intentions of the project? Kay Sievers has been the maintainer and has done most of the udev developement since 2004. He's also the one who merged the project to systemd. Greg Kroah-Hartman who started the project in 2003 has also been supportive of the move. Those two developers have done something like 85 to 90% of udev developement in the past nine years; mostly Kay though. Also udev is still supported outside of systemd.

                      Where?

                      Could you show the breakdown of that 132k lines of code? What optional dependecies did you include?

                      No it isn't. Some of the key parts like mixing isn't done in kernel by Jack, ALSA (dmix) or PulseAudio. Here's a blog post about saving power by using PulseAudio.

                      What exactly are you saying? Both Jack and PulseAudio use the ALSA userspace libaries to talk to the kernel ALSA drivers. I have no idea what you mean by how Linux-devs might be looking at PulseAudio.

                      What I meant by security was this:



                      It's something that Jack to my understanding doesn't do.
                      Valid points, I agree.

                      Looking at security, Jack is actually dependent on HRT's, which means, that we also are bound to runaway-timers when we are talking about low-latency-daemons like Jack.
                      PulseAudio doesn't have such a low latency and thus doesn't have to entirely depend on those things. But this is a qualitative issue you have to live with when you aim at having a low-latency-system, I don't really see the issue here.

                      In regards to Kernel-development, I was speaking of the Jack-integration. Show me where PulseAudio is explicitly and not implicitly implemented into the Kernel and we can talk on in this regard.

                      Looking at power, the number of interrupts is highly dependent on how you configure your Kernel. My Kernel currently runs on 33 MHz (8 Cores) and has a _very_ low power-consumption when idling.
                      I can only guess in this regard, but PulseAudio performs better in this regard because most users have a low-latency Desktop with a high Timer-frequency and HRT's, ultimately rendering the ALSA-drivers dependent on these high interrupt-rates.

                      The number of lines of code were taken from the Wikipedia article after quick-lookup. These numbers may be inaccurate, granted, but it is out of question OpenRC is a way simpler approach than systemd, given the high number of "outsourced" functionality.

                      Comment


                      • #56
                        open questions

                        Originally posted by Teho View Post
                        Here's the blog post (PulseAudio vs. AudioFlinger: Fight!). It's already over year old though.

                        It's one of its key design goals. It's also why it could be used in Maemo/MeeGo/webOS... mobile platforms. Here's a blog post showing power savings over plain ALSA with PulseAudio.

                        Well you can separate the ExecStart=, ExecStop=, WantedBy=... lines of other configuration lines by adding a ".../foobar.service.d/*.conf" file if you so desire.
                        You really got to explain why this can even be possible. I am really wondering how a subset of PulseAudio can be less efficient than PulseAudio itself. Articles authored by Lennart Poettering himself are not that quite convincing.

                        Comment


                        • #57
                          Originally posted by frign View Post
                          You really got to explain why this can even be possible. I am really wondering how a subset of PulseAudio can be less efficient than PulseAudio itself. Articles authored by Lennart Poettering himself are not that quite convincing.
                          The Meego blog posts IIRC say why: Pulse configures the driver to have larger buffers than by default.

                          As a RT user you know what that does to latency, but it also saves power.

                          Comment


                          • #58
                            Originally posted by frign View Post
                            You really got to explain why this can even be possible. I am really wondering how a subset of PulseAudio can be less efficient than PulseAudio itself. Articles authored by Lennart Poettering himself are not that quite convincing.
                            Pulse is all about configuration frign. You can configure it to realtime like JACK and raise power usage, or you can configure it to be high-latency and lower power usage. Whats not to understand? (Serious question, I dont understand the part you arent understanding so if you could be more specific / point out specific parts of the articles, thatd be helpful)

                            Comment


                            • #59
                              About pulse being buggy or CPU hungry, or having hiccups:
                              My phone, 3 years ago, with 256MB of ram and 500GHz of cpu ran music and phone calls without any problem. With pulse. So you could route sound to speaker, headphones, or bluetooth any time, and keep different sound volumes for different output or different programs.

                              I haven't tried to do that with alsa, and neither did Nokia. Maybe it was possible, probably it wasn't (or they wouldn't be including it in their custom phone distro).
                              In any case, it ran fine and did not skip.

                              So if it hiccups on your desktop, well, either it's 15 years old hardware at least, or there is something wrong with your setup.

                              Comment


                              • #60
                                Originally posted by frign View Post
                                The number of lines of code were taken from the Wikipedia article after quick-lookup. These numbers may be inaccurate, granted, but it is out of question OpenRC is a way simpler approach than systemd, given the high number of "outsourced" functionality.
                                The OpenRC people seem to think that Wikipedia is their marketing platform. It doesn't have sources either and there's even a "This article's tone or style may not reflect the encyclopedic tone used on Wikipedia. See Wikipedia's guide to writing better articles for suggestions. (December 2012)" banner on top of the page. All in all that part of the article should probably be removed as off-topic, unreferenced and biased trash.

                                Originally posted by frign View Post
                                In regards to Kernel-development, I was speaking of the Jack-integration. Show me where PulseAudio is explicitly and not implicitly implemented into the Kernel and we can talk on in this regard.
                                Could you point me where the kernel part of Jack is? ...and how exactly does it make Jack better than PulseAudio.

                                Originally posted by frign View Post
                                Articles authored by Lennart Poettering himself are not that quite convincing.
                                Neither of the articles I linked were authored by Lennart.

                                Comment

                                Working...
                                X