Announcement

Collapse
No announcement yet.

Systemd 199 Has Its Own D-Bus Client Library

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

  • #41
    Originally posted by Teho View Post
    Seriously what are you talking about? Both Jack and PulseAudio run on top of the ALSA userspace that talks to the kernel ALSA drivers. Jack is a daemon just like PulseAudio. It's also meant for professional audio, it doesn't take in account the power consumption or security (relating to the scheduling or something) like PulseAudio.
    Good point Teho. Alsa is the drivers for your soundcard, and a minimal setup for someone who basically has a desktop computer and monitor speakers and thats it. No media center, no extra monitors, no cables, just needs A to B and thats it.

    JACK is for the pros, typically also desktop users. They need super fine-grained control over audio, they need it to be in realtime by default and always, the system is probably locked down so security isnt an issue, and also Audio is the most important process other than the kernel itself.

    Pulse is the middle ground. Pulse is for the everyday user, especially laptops (headphones and power consumption). If there's a few milliseconds of lag, thats fine, but realtime is available if needed. They're gonna be plugging in HDMI cables, or speakers, or running skype and music, or headphones. Basically if you need anything OTHER than "This is my desktop, these are my speakers and I do 1 thing at 1 time" (that would be alsa), you could probably benefit from running Pulse. Maybe not benefit enough for YOU to bother setting it up, but there would be SOME benefit from Pulse.
    All opinions are my own not those of my employer if you know who they are.

    Comment


    • #42
      Logical problems

      Originally posted by Teho View Post
      Where do you get the 132k lines of code? I mean only fraction of the project makes up the init system. On top of that it has udev, journald, readahead implementation, hostnamed, logind, timedated, bootchart implementation... and various other tools; almost all of these are obviously optional. It also replaces stuff like xinted, cron and xinetd among other things. Also you can't just say that because you can run xinetd or cron on top of systemd that it would support that it would support the same functionality. Here's a quote explaining what you could do with systemd timers for example:



      Same goes for socket based boot up as you can discover here; you can't do that with xinetd. 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.



      Well the point is that it's advanced. This is awesome. It for example shows the last ten log messages for the daemon.

      Also could you point me to some examples of using OpenRC on initrd and starting user sessions?

      Seriously what are you talking about? Both Jack and PulseAudio run on top of the ALSA userspace that talks to the kernel ALSA drivers. Jack is a daemon just like PulseAudio. It's also meant for professional audio, it doesn't take in account the power consumption or security (relating to the scheduling or something) like PulseAudio.
      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.

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


      @Jack
      Points you are missing is that power-consumption is already levelled sufficiently in the device-specific ALSA-drivers in-Kernel 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).
      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.

      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.

      Comment


      • #43
        Originally posted by frign View Post
        Thanks for your extensive reply (I really appreciate it).

        Your points on PulseAudio are valid. The functions seem practical and are in some ways advantages over ALSA.
        However, most problems you addressed with ALSA have been in regards to those during the transition-phase from OSS to ALSA, when ALSA was still buggy and lagging features. It now _does_ support bluetooth through "bluez", it definitely has been fixed in regards to io-routing and it is not a big bloated hog clobbering the user-space, being well-integrated into the Kernel.
        I personally am very liberal about PulseAudio, but I am not happy to hear of FUD spread about ALSA when the problems talked about have mostly been fixed years ago and when ALSA is actually a sufficient option for most users.

        Concerning OpenRC, I already put the questioned points together and won't address them again, because I lack the patience.

        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
        Regarding your comments about udev. I know that you have some involvement with it so its good to hear your opinions on the matter. And Yes thats a freakin awesome idea. It is after all the kernels responsibility to manage hardware.

        Comment


        • #44
          Originally posted by duby229 View Post
          Regarding your comments about udev. I know that you have some involvement with it so its good to hear your opinions on the matter. And Yes thats a freakin awesome idea. It is after all the kernels responsibility to manage hardware.
          Yes, well put! I am really excited to see the direction we are heading to in the future

          Comment


          • #45
            Originally posted by frign View Post
            Concerning OpenRC, I already put the questioned points together and won't address them again, because I lack the patience.
            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 [/QUOTE]

            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.
            All opinions are my own not those of my employer if you know who they are.

            Comment


            • #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.
                All opinions are my own not those of my employer if you know who they are.

                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

                      Working...
                      X