Announcement

Collapse
No announcement yet.

Systemd 199 Has Its Own D-Bus Client Library

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

  • #31
    Originally posted by bkor View Post
    Alsa does not provide the same as PulseAudio, nor does Jack. None of what you listed is a replacement for systemd.

    I've attended the FOSDEM eudev talk and it was one of the worst presentations I've ever attended. No answers to questions, just things like "eat a chocolate". Some vague statements, no technical answers.

    Seems the trend continues!
    The only thing that PA does that is kinda nice is its per application volume control. Thats it. But its soooo huge that it simply isnt worth it to get that slight advantage. It's performance is so bad that even the slightest cpu load makes it skip and crackle. Simply put, it's some of the worst software ever written for little to no gain with lots and lots to lose.

    Alsa running by itself on the other hand will easily fit the needs of almost everyone.

    Comment


    • #32
      Originally posted by bkor View Post
      Alsa does not provide the same as PulseAudio, nor does Jack. None of what you listed is a replacement for systemd.

      I've attended the FOSDEM eudev talk and it was one of the worst presentations I've ever attended. No answers to questions, just things like "eat a chocolate". Some vague statements, no technical answers.

      Seems the trend continues!
      PulseAudio provides, in my view, unneeded abstraction as a solution for problems I don't see or am unable to perceive (maybe apart from per-application volume control).
      Please tell me when PulseAudio comes in handy, because I don't see the benefit.
      If you need normal playback, Alsa is the way to go.
      If you need low-latency for professional music-production, Jack is the way to go.

      I don't want to appear arrogant in this context and am very open to your words on this topic, because I may have not spent enough time in this area to really see the benefit of the PulseAudio-Layer. Feel free to state your points more clearly.

      I agree on the eudev-talk, but as I am involved in this project, I have to say that they know what they are doing and I am glad to work with them on this essential project, considering the fact that udev is about to merged into systemd in the next versions.

      In regards to systemd, I forgot about the most important module: OpenRC.
      Please tell me where OpenRC (and now DBUS) lack in comparison to Systemd.
      Last edited by frign; 27 March 2013, 03:39 PM.

      Comment


      • #33
        Originally posted by frign View Post
        Please tell me when PulseAudio comes in handy, because I don't see the benefit.
        If you need multiple simultaneous audio outputs or inputs or need to switch outputs on the fly. For example I have three audio outputs: HDMI, Bluetooth and headphone jack; with PulseAudio I can change the output by simply dragging the audio source (application) to the output and it changes instantly. I can also play movie audio from the HDMI connected TV while I listen to music from different application on my headphones while someone is talking on Skype with a bluetooth headset. It can also combine soundcards and play same audio from multiple outputs. It can apply filters like equalizers and various effects to individual audio sources or globally. It provides zero configuration support for bluetooth. It can be set to use less power than ALSA/dmix... and so on and so forth.

        Originally posted by frign View Post
        In regards to systemd, I forgot about the most important module: OpenRC.
        Please tell me where OpenRC (and now DBUS) lack in comparison to Systemd.
        Does it have user session support? Does it run on initrd? Does it have equilevant of "systemd status" command? Can it start applications on file changes, based on timers or states of other services? Can it automaticly start services when they crash? Does it provide socket based startup? Can it start services when certain devices are attached? Does it provide trivial to write service files like systemd unit files? Does it provide good integratio with various security features like SELinux or seccomp?...


        Originally posted by frign View Post
        systemd, pulseaudio, ...
        Yes those are projects... but what is his agenda that is disputable and makes you not want to work with him?

        Comment


        • #34
          Originally posted by frign View Post
          PulseAudio provides, in my view, unneeded abstraction as a solution for problems I don't see or am unable to perceive (maybe apart from per-application volume control).
          Please tell me when PulseAudio comes in handy, because I don't see the benefit.
          If you need normal playback, Alsa is the way to go.
          If you need low-latency for professional music-production, Jack is the way to go.

          I don't want to appear arrogant in this context and am very open to your words on this topic, because I may have not spent enough time in this area to really see the benefit of the PulseAudio-Layer. Feel free to state your points more clearly.

          I agree on the eudev-talk, but as I am involved in this project, I have to say that they know what they are doing and I am glad to work with them on this essential project, considering the fact that udev is about to merged into systemd in the next versions.

          In regards to systemd, I forgot about the most important module: OpenRC.
          Please tell me where OpenRC (and now DBUS) lack in comparison to Systemd.
          I ask you a question and you turn it around and say that I should provide the answer. What an interesting way to answer a question.

          In any case: udev has been merged into systemd for a pretty long time (in Internet time:P). If you say you're involved with eudev, how could you miss this? Really, wtf.

          Per your argumentation: If you do not see the benefit of something, this means it provides no benefit. Various other people do see the benefit of them though. Maybe you want to not only look at your own needs, but also look what others find useful.

          Regarding my earlier answer that eudev people seem to lack any technical answer: Show me why OpenRC is so much better. You brought this up as argumentation, burden is on you.

          You said everything Lennart is doing is not needed or something. Explain already.

          Comment


          • #35
            Originally posted by duby229 View Post
            The only thing that PA does that is kinda nice is its per application volume control. Thats it. But its soooo huge that it simply isnt worth it to get that slight advantage. It's performance is so bad that even the slightest cpu load makes it skip and crackle. Simply put, it's some of the worst software ever written for little to no gain with lots and lots to lose.

            Alsa running by itself on the other hand will easily fit the needs of almost everyone.
            PulseAudio performance is perfectly acceptable. The things you say (skip and crackle) I've not experienced, nor heared anyone complain about it. Maybe with your specific driver there is an issue which causes problems in PulseAudio. But PulseAudio is used by default on loads of distributions. Compared to the usage, the number of complaints is really really low.

            Further, PulseAudio does way more than application volume control. Think of the headset stuff, automatically being able to do echo cancellation, plugins, easy monitoring (recording), etc.

            Comment


            • #36
              Originally posted by Teho View Post
              If you need multiple simultaneous audio outputs or inputs or need to switch outputs on the fly. For example I have three audio outputs: HDMI, Bluetooth and headphone jack; with PulseAudio I can change the output by simply dragging the audio source (application) to the output and it changes instantly. I can also play movie audio from the HDMI connected TV while I listen to music from different application on my headphones while someone is talking on Skype with a bluetooth headset. It can also combine soundcards and play same audio from multiple outputs. It can apply filters like equalizers and various effects to individual audio sources or globally. It provides zero configuration support for bluetooth. It can be set to use less power than ALSA/dmix... and so on and so forth.


              Does it have user session support? Does it run on initrd? Does it have equilevant of "systemd status" command? Can it start applications on file changes, based on timers or states of other services? Can it automaticly start services when they crash? Does it provide socket based startup? Can it start services when certain devices are attached? Does it provide trivial to write service files like systemd unit files? Does it provide good integratio with various security features like SELinux or seccomp?...


              Yes those are projects... but what is his agenda that is disputable and makes you not want to work with him?
              @PulseAudio
              The dynamic input/output switching is available in Jack; take a look at QJackCtl and tell me where this tool lacks those capabilities. Applying filters is done through software-ports and very easy and convenient.
              Added to this, Jack is implemented in the Kernel and is not a big bull running in user-space trying to, again, reinvent the wheel (again, apart from per-application volume control).

              @SystemD/OpenRC
              user session support --> process segragation with cgroups √
              runs on initrd √
              systemd status --> rc-status, through Kernel (but admittedly, probably not as advanced) √
              service handlers --> handled through cron-jobs (external), crashed services can be automatically restarted √
              socket based startup --> handled by xinetd √
              SELinux √

              Added to that, the main advantage of OpenRC is definitely the low complexity and high flexibility. Whereas Systemd pulls in D-Bus as a mandatory dependency, it also consists of 132k lines of code in contrast to OpenRC which consists of only 32k lines of code and focuses on utilizing already available functions without trying to reinvent the wheel in many regards.
              I don't want to say that SystemD is generally bloated, but it does the job for me, doesn't seem to lack the features you were talking about and rather has many practical advantages over SystemD too complex to talk about here (I pinpoint ulimits, dep-based bootup, strict separation of configuration and shell, transparent networking and so on).

              Comment


              • #37
                Originally posted by frign View Post
                PulseAudio provides, in my view, unneeded abstraction as a solution for problems I don't see or am unable to perceive (maybe apart from per-application volume control).
                Please tell me when PulseAudio comes in handy, because I don't see the benefit.
                If you need normal playback, Alsa is the way to go.
                If you need low-latency for professional music-production, Jack is the way to go.

                I don't want to appear arrogant in this context and am very open to your words on this topic, because I may have not spent enough time in this area to really see the benefit of the PulseAudio-Layer. Feel free to state your points more clearly.
                Pulse got started because at the time, the Alsa devs were...for lack of a better word, being jackasses. Dmix was a complete mess, it could barely keep software mixing right. It had no plug-in support-- if you plugged in anything that also accepted sound output, it wouldnt shut off your speakers and send it out the new output (such as HDMI or headphones) it would just blast all sound out all outputs with zero coherency.*

                Another thing that they wanted to work on was the idea of network-transparent audio. Pulse has the ability to send sound from 1 computer to another (such as a laptop sending its audio over speakers in your media center for a party or something similar).*

                Alsa and OSS tend to not play...quite right together (It was very hit and miss). Pulse fixed this by creating a fake device node at /dev/dsp which let OSS applications THINK they had exclusive access and therefore work properly, despite the fact they did. It also provided the interfaces necessary to be a drop-in replacement for ESD. Alsa likes applications to use THEIR interface, Pulse just provides extra interfaces *so that applications dont have to actually be changed in any way, its future-proofing for the applications essentially.

                Also Pulse can do per-stream-volume-management. If you're on Skype with someone but want your music playing too, you want Skype at 90% volume, but music to be at like 20% so that the music isnt drowning out the person... Alsa cant do that.

                Also last I checked (they may have added this by now) Alsa didnt support Bluetooth...like at all. It didnt understand the concept of a sound output that wasnt directly connected to the laptop.*

                Pulse is also working on a system-wide equalizer, the application is in the current tree but they dont have any presets yet.

                Pulse is better at power consumption than stock alsa, since the entire architecture is zero-copy.

                Pulse can dynamically move sound from 1 device to the other, on the fly, with zero stuttering or lag. If I start a movie on my laptop at my desk, a friend comes over or I just decide to do something else. I plug in the HDMI cable, pull up veromix and move the window from the laptop screen to the TV screen, and then drag the entry for the movie player (no matter what it is--applications are blind to what output they are on, all they know is they are connected to Pulse) from the speakers to the HDMI output.

                A lot of people say that pulse is laggy or stutters..I literally have no idea what they are talking about. Since Ubuntu 9.10 hit I've used it on EVERY distro I run-- openSUSE, Arch, Gentoo, Ubuntu, Fedora and Debian testing, across a lot of different hardware and have never ONCE had problems with stuttering or lag. Even under high CPU load, so the only thing I can think of is bad configurations on those users part, or maybe their sound drivers (managed by the ALSA project) are buggy


                I agree on the eudev-talk, but as I am involved in this project, I have to say that they know what they are doing and I am glad to work with them on this essential project, considering the fact that udev is about to merged into systemd in the next versions.
                udev was not merged INTO systemd. it was merged into the systemd repo. But its still in its own folder and can be loaded without systemd existing.

                In regards to systemd, I forgot about the most important module: OpenRC.
                Please tell me where OpenRC (and now DBUS) lack in comparison to Systemd.
                This one is going to be more of a discussion, because I am not familiar with OpenRC. I know Upstart but its been a while since I ran Gentoo haha.

                How does OpenRC handle parallelization? Back when I used it it was very hit or miss, sometimes even breaking the boot process because things got ran in the wrong order and there were no safeguards.

                Does OpenRC have socket activation of services so that they arent loaded before they are needed?

                If an app crashes can OpenRC automatically restart it?

                Does OpenRC use cgroups to track applications? Under init and upstart if an application double-forks itself, it can get away from its parent and basically be an orphan process. Systemd prevents this by using cgroups to carefully keep track of processes and it guarantees that no matter how many times a process forks it can never be orphaned. Does openrc have something similar?

                Systemd also uses cgroups now to handle resource management and resource restriction. The usual "unix" way of that was setting a NICE level for the process. The problem that arouse though was Apache isnt 1 process..its anywhere from 10 to infinite depending on the configuration and load on the server. You cant set NICE levels for an infinite number of processes. Systemd just sets 1 global level for the entire apache cgroup and apache is forced to respect that (by the kernel) whether it wants to not. <--- Administrator controls the resource restriction systemd sets.

                The problem with comparing systemd to openrc or init or sh or any other "minimal" init system is that systemd isn't just service management. Its not even all named systemd. Systemd is the umbrella name for a suite of tools (systemd & systemctl, journald & journalctl, logind, hostnamectl, and many other) all developed in the same git repository. But they arent the same process (as some have said), they arent mandatory to all have running at the same time (as some have claimed), they arent even all mandatory to be COMPILED. A stock barebones systemd installation is:

                1) systemd and systemctl (the daemon, and the control interface)
                2) udev (systemd depends on udev, udev does NOT however depend on system. Thats pure FUD)
                3) journald and journalctl (the daemon and the control interface. This does NOT stop you from using syslog or rsyslog or whatever else)

                And thats it. If you dont want something you either 1) dont compile it, or 2) just dont use it. Turn it off / ignore it lol.
                All opinions are my own not those of my employer if you know who they are.

                Comment


                • #38
                  Originally posted by frign View Post
                  @PulseAudio
                  The dynamic input/output switching is available in Jack; take a look at QJackCtl and tell me where this tool lacks those capabilities. Applying filters is done through software-ports and very easy and convenient.
                  Added to this, Jack is implemented in the Kernel and is not a big bull running in user-space trying to, again, reinvent the wheel (again, apart from per-application volume control).
                  Pulse avoided being in-kernel because of the fear of crashing the whole kernel. If you absolutely have to have zero lag / latency then you just load the realtime pulseaudio kernel module on a realtime kernel. You'll get under .2ms latency assuming the rest of your system isnt a bottleneck once you get it configured and setup.

                  As far as JACK is concerned, maybe its changed since I ran it, but it was a massive pain to get setup and configured last time I tried to use it on Arch. With pulse I just install pulseaudio, pulseaudio-alsa and thats it. pulseaudio-alsa automatically changes the alsa config file to default to the pulse server and I dont have to touch a single config file. Sound JUST works.
                  All opinions are my own not those of my employer if you know who they are.

                  Comment


                  • #39
                    Originally posted by frign View Post
                    Whereas Systemd pulls in D-Bus as a mandatory dependency, it also consists of 132k lines of code in contrast to OpenRC which consists of only 32k lines of code and focuses on utilizing already available functions without trying to reinvent the wheel in many regards.
                    I don't want to say that SystemD is generally bloated, but it does the job for me, doesn't seem to lack the features you were talking about and rather has many practical advantages over SystemD too complex to talk about here (I pinpoint ulimits, dep-based bootup, strict separation of configuration and shell, transparent networking and so on).
                    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 cron and xinetd among other things. Also you can't just say that because you can run xinetd or cron on top of OpenRC that it would support the same functionality as systemd. Here's a quote explaining what you could do with systemd timers for example:

                    So, here's why you want systemd time events:
                    systemd timer events allow you to make use of the same execution parameters of any other systemd service, which means you can limit resources, change users/group ids, set nice values, oom score, IO scheduling class, IO scheduling priority, CPU scheduling policy, CPU scheduling priority, CPU affinity, umask, timer slack, capabilities, secure bits, control group memberships, control group attributes, network access, private /tmp, namespaces, system call filters, ... individually for each job.
                    As the services started by a timer unit is a normal service it can pull in arbitrary dependencies on activation. That means you can actually sanely write cron jobs that depend on what they need.
                    As timer events are just one way to activate a unit you can actually combine that, so that you can spawn a service triggered by different events. Think: there's now a sane way to invoke something on the command line + at boot + if hw is plugged in + on a time event or if the user starts it explicitly, and the service will be executed in the exact same environment.
                    As timer events are just like any other units you now have a sane way to enable and disable them: "systemctl enable" and "systemctl disable".
                    All output of systemd timer events ends up in the logs, and is indexed by the event.
                    systemd can schedule time events both on monotonic times (think: run something every so and so often regardless of timzones, DST, the user mucking with the clock, broken clock, clock battery gone...) and on calendar times.
                    systemd calendar time events are more fine grained than cron (1s precision)
                    systemd calendar time events are more expressive (you can have repetitive and non-repetitive events, you can match on years, and you can actually match a week day at the same time as a day of month). And also I'd claim they are easier to write and especially read than cron time events. (See the lower part of http://www.freedesktop.org/software/...temd.time.html[1] for details)
                    the systemd timer scheduling is a bit more energy efficient as systemd wakes up the CPU only when the timer elapsed, and not repeatedly as cron does
                    In cron if you wanted to avoid that slow running services are spawned multiple times you had to invent your own locking in the job. In systemd that's implicit, as the trigger is just a trigger, and the service will never be started at once.
                    You can even express timer events that are scheduled based on the finish time of the previous execution, i.e. for example to say that there should always be 1h between executions, even if each of them takes 2h.
                    You can combine timer events easily. e.g. "5 min after bootup + every day at 6am".
                    You now have a nice way to stop/kill a cronjob (and all its children), and only that one cron job, with "systemctl stop" and "systemctl start"
                    You now have a nice way how you can figure out to which cronjob a process belongs to, "ps xawf -eo pid,user,cgroup,args".
                    External programs can query all details about timers and the jobs. Execution status, when they ran the last time, and so on. There's a pretty complete, documented API for that exposed on the bus.
                    We now track failed cron jobs nicely, and just typing "systemctl show" will show them to you.
                    You now can establish cronjobs only in certain system states. For example, you can queue a cronjob only if the network is up, or suchlike. Think of cronjobs that are pulled in by the equivalent of classic sysv runlevels, only.
                    And yeah, the scheme makes timer events uniform with other triggers, so it's simpler to understand for newcomers...
                    ...
                    The interesting bit about all of this is that the code necessary for implementing all of this is pretty short, since all the complex bits (spawning/supervising a process in a precisely defined execution environment, pulling in deps...) is just the stuff we do anyway for normal services. The only additions for supporting timer events, was basically a parser for the timer expression language and a bit of code to tell the kernel to actually wake up systemd when the timer triggers.
                    So, yeah, the code we had to write was small, the benefits gained throught it are substantial, so we did it.
                    I figure embedded people will start making use of all of this first.
                    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 status --> rc-status, through Kernel (but admittedly, probably not as advanced) √
                    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?

                    Added to this, Jack is implemented in the Kernel and is not a big bull running in user-space trying to, again, reinvent the wheel (again, apart from per-application volume control).
                    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.
                    Last edited by Teho; 27 March 2013, 05:16 PM.

                    Comment


                    • #40
                      Some more points

                      Originally posted by Ericg View Post
                      Pulse got started because at the time, the Alsa devs were...for lack of a better word, being jackasses. Dmix was a complete mess, it could barely keep software mixing right. It had no plug-in support-- if you plugged in anything that also accepted sound output, it wouldnt shut off your speakers and send it out the new output (such as HDMI or headphones) it would just blast all sound out all outputs with zero coherency.*

                      Another thing that they wanted to work on was the idea of network-transparent audio. Pulse has the ability to send sound from 1 computer to another (such as a laptop sending its audio over speakers in your media center for a party or something similar).*

                      Alsa and OSS tend to not play...quite right together (It was very hit and miss). Pulse fixed this by creating a fake device node at /dev/dsp which let OSS applications THINK they had exclusive access and therefore work properly, despite the fact they did. It also provided the interfaces necessary to be a drop-in replacement for ESD. Alsa likes applications to use THEIR interface, Pulse just provides extra interfaces *so that applications dont have to actually be changed in any way, its future-proofing for the applications essentially.

                      Also Pulse can do per-stream-volume-management. If you're on Skype with someone but want your music playing too, you want Skype at 90% volume, but music to be at like 20% so that the music isnt drowning out the person... Alsa cant do that.

                      Also last I checked (they may have added this by now) Alsa didnt support Bluetooth...like at all. It didnt understand the concept of a sound output that wasnt directly connected to the laptop.*

                      Pulse is also working on a system-wide equalizer, the application is in the current tree but they dont have any presets yet.

                      Pulse is better at power consumption than stock alsa, since the entire architecture is zero-copy.

                      Pulse can dynamically move sound from 1 device to the other, on the fly, with zero stuttering or lag. If I start a movie on my laptop at my desk, a friend comes over or I just decide to do something else. I plug in the HDMI cable, pull up veromix and move the window from the laptop screen to the TV screen, and then drag the entry for the movie player (no matter what it is--applications are blind to what output they are on, all they know is they are connected to Pulse) from the speakers to the HDMI output.

                      A lot of people say that pulse is laggy or stutters..I literally have no idea what they are talking about. Since Ubuntu 9.10 hit I've used it on EVERY distro I run-- openSUSE, Arch, Gentoo, Ubuntu, Fedora and Debian testing, across a lot of different hardware and have never ONCE had problems with stuttering or lag. Even under high CPU load, so the only thing I can think of is bad configurations on those users part, or maybe their sound drivers (managed by the ALSA project) are buggy




                      udev was not merged INTO systemd. it was merged into the systemd repo. But its still in its own folder and can be loaded without systemd existing.



                      This one is going to be more of a discussion, because I am not familiar with OpenRC. I know Upstart but its been a while since I ran Gentoo haha.

                      How does OpenRC handle parallelization? Back when I used it it was very hit or miss, sometimes even breaking the boot process because things got ran in the wrong order and there were no safeguards.

                      Does OpenRC have socket activation of services so that they arent loaded before they are needed?

                      If an app crashes can OpenRC automatically restart it?

                      Does OpenRC use cgroups to track applications? Under init and upstart if an application double-forks itself, it can get away from its parent and basically be an orphan process. Systemd prevents this by using cgroups to carefully keep track of processes and it guarantees that no matter how many times a process forks it can never be orphaned. Does openrc have something similar?

                      Systemd also uses cgroups now to handle resource management and resource restriction. The usual "unix" way of that was setting a NICE level for the process. The problem that arouse though was Apache isnt 1 process..its anywhere from 10 to infinite depending on the configuration and load on the server. You cant set NICE levels for an infinite number of processes. Systemd just sets 1 global level for the entire apache cgroup and apache is forced to respect that (by the kernel) whether it wants to not. <--- Administrator controls the resource restriction systemd sets.

                      The problem with comparing systemd to openrc or init or sh or any other "minimal" init system is that systemd isn't just service management. Its not even all named systemd. Systemd is the umbrella name for a suite of tools (systemd & systemctl, journald & journalctl, logind, hostnamectl, and many other) all developed in the same git repository. But they arent the same process (as some have said), they arent mandatory to all have running at the same time (as some have claimed), they arent even all mandatory to be COMPILED. A stock barebones systemd installation is:

                      1) systemd and systemctl (the daemon, and the control interface)
                      2) udev (systemd depends on udev, udev does NOT however depend on system. Thats pure FUD)
                      3) journald and journalctl (the daemon and the control interface. This does NOT stop you from using syslog or rsyslog or whatever else)

                      And thats it. If you dont want something you either 1) dont compile it, or 2) just dont use it. Turn it off / ignore it lol.
                      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

                      Comment

                      Working...
                      X