SystemD, just like Pulsef*** and GRUB2, is a mess!

[Fitzcarraldo]

udev seems to be causing quite a bit of aggravation to some people at the moment, as a cursory look through the Gentoo Forums shows: the number of udev topics recently is a good indicator of the hassle it is causing . SL users are mostly oblivious because lxnay et al. know about most of the problems before using the Gentoo ebuilds to build packages for Entropy.

[nachoig]

PulseAudio is here because ALSA is not a sound server.

Actually PulseAudio is here to unify the Linux sound libraries and provide an unified API, this is why it has an extensible plugin architecture with numerous backends. Which doesn't make sense in the first place since it aims to unify audio libraries fragmentation by providing one more fragment.
Additionally, a sound server itself doesn't make much sense, as it only increases layers and sound latency and sound programming complexity, as you have to keep in mind anything you do is asynchronous, moreover any feature provided by the PulseAudio server could be achieved extending ALSA itself, or even OSS, and this is demonstrated by OSS4.

OSS is dead. Mixing in the kernel space is a bad idea, no power management, no Bluetooh, no USB audio and no modern application supporting it. OK, it has active development, but it was forgotten.

any feature provided by the PulseAudio server could be achieved extending ALSA itself,

In PulseAudio we have independent volume control per-application, switches on-the-fly between multiple outputs, better power consumption.

ALSA is onlye a sound architecture (Advanced Linux Sound Archtecture). Its function is working with the drivers and the kernel, but it's not intended for replacing a sound server or doing sound mixing. In the past, we had ESD and aRts because of this.

Latency: really, I didn't understand why. For general use, I don't see any problems with the latency. Low latency is only for the pros, and for this purpose, we have JACK.

Also, PulseAudio can be used by default by a lot of applications: KDE SC, GNOME, Skype, Steam, OpenAL...

it's capable to track all daemons, its unit files are much better than SysV's scripts, these unit files aren't distro-specific, it has excelent administrative tools.

Its features have been implemented on many other less known (and advertized) init systems, such as s6, runit, upstart. Among them s6 is very interesting, since it is completely SysV compatible. Whether or not shell scripts are better is not that easy to say, as shell scripts are much more flexible, you'll also notice that many systemd unit files resort to invoking shell scripts to start daemons, which kinda defeats the purpose of having them.

Look at a startup shell script and look at this:

Code: Select all

[Unit]
Description=CUPS Printing Service

[Service]
ExecStart=/usr/sbin/cupsd -f

[Install]
Alias=cupsd.service
Also=cups.socket cups.path
WantedBy=printer.target


Well, at this time, for example, Fedora and Arch don't invoke any shell scripts to start daemons. Other distros with systemd are doing the same (eg: Mageia 3)

In the startup, shell scripts are very fragile. A shell script for Gentoo won't work with Debian. In comparision, systemd units can be distributed by upstream mantainers.

No, I can't compare this with OpenRC. OpenRC is only an inprovemente running on top of SysVinit, but it falls in the limitations of SysV... Also, parallelisation in OpenRC doesn't work properly.

Parallelization in OpenRC does work, as cgroups support does, the fact that rc_parallel isn't recommended because synchronous boot is safer doesn't mean that it isn't working.

https://bugs.gentoo.org/show_bug.cgi?id=391945

X: X is bloated, and it has a lot of non-functional code and needs a lot of ugly workarounds.

The core X protocol hasn't been updated in 30 years with the excuse "We are not the X consortium", thus it has only been extended and worked around, I see little point in complaining about X when nobody done a single thing to improve it. I'd actually say it's a pretty good and solid standard if it has been able to survive and be extended all these years.
Regardless X, this doesn't explain why Mir has been announced despite Wayland doing exactly the same thing, little plausible explainations are available for this...

Because nobody needs a X12.

http://mirror.linux.org.au/linux.conf.a ... _and_X.ogv

[micia]

OSS is dead. Mixing in the kernel space is a bad idea, no power management, no Bluetooh, no USB audio and no modern application supporting it. OK, it has active development, but it was forgotten.

Why? This is your own opinion. Many developers actually think kernel mixing has less latency, leads to simpler implementation and allows smarter scheduling. Power management can still be implemented, OSS4 hasn't that feature in Linux, simply because they didn't think OSS would have been adopted there, and they were right. Also most of OSS deadness is related to its old Linux implementation, which was horrible and rightfully criticized and deprecated.
As explained here:
https://en.wikipedia.org/wiki/Open_Sound_System#OSS_in_relation_to_ALSA
http://manuals.opensound.com/developer/audio_myths.html (Doing "mixing" in kernel space (drivers) is evil)

In PulseAudio we have independent volume control per-application, switches on-the-fly between multiple outputs, better power consumption.

ALSA is onlye a sound architecture (Advanced Linux Sound Archtecture). Its function is working with the drivers and the kernel, but it's not intended for replacing a sound server or doing sound mixing. In the past, we had ESD and aRts because of this.

Latency: really, I didn't understand why. For general use, I don't see any problems with the latency. Low latency is only for the pros, and for this purpose, we have JACK.

Also, PulseAudio can be used by default by a lot of applications: KDE SC, GNOME, Skype, Steam, OpenAL...

I meant that the desktop oriented features, like per application volume and on the fly audio output switch, could be easily implemented with ALSA, or with external ALSA shared libraries, in a simpler fashion, having a single well focused project. Network audio streaming could be achieved much better with a dedicated multimedia oriented daemon, and there are lots of them. Such approach would lead to a more modular and more rational organization, that PulseAudio doesn't have in my opinion. PulseAudio actually does a lot of behind the scenes work to try to minimize its latency, in a way similar to Windows Vista, this makes it quite resource hungry with its memory, some applications (especially games and multimedia oriented applications) don't need that extra work and would be more efficient without it, since they already perform some kind of latency minimization (like game engines for example).

Look at a startup shell script and look at this:

Code: Select all

[Unit]
Description=CUPS Printing Service

[Service]
ExecStart=/usr/sbin/cupsd -f

[Install]
Alias=cupsd.service
Also=cups.socket cups.path
WantedBy=printer.target


Well, at this time, for example, Fedora and Arch don't invoke any shell scripts to start daemons. Other distros with systemd are doing the same (eg: Mageia 3)

In the startup, shell scripts are very fragile. A shell script for Gentoo won't work with Debian. In comparision, systemd units can be distributed by upstream mantainers.

Actually ArchLinux does exactly that, invoking shell script for many services, for example cpupower. Anyway I didn't say it's better, I said it is debatable, you might want that or you might trade off some simplicity over flexibility. I meant that implementing many of the systemd features is just a matter of implementing them, sysV style scripts aren't really a problem for that.
Actually there is even a standard for init scripts:
http://refspecs.linuxfoundation.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/tocsysinit.html

Agreeing to a standard for init scripts would make them portable, unfortunately, despite the existence of such standard, many sysV like init systems don't conform (I think even OpenRC dependencies aren't LSB standard).

https://bugs.gentoo.org/show_bug.cgi?id=391945

Well, it is a bug dated: 2011-11-26, I actually use rc_parallel on a daily basis, and I have /etc/init.d/modules active and working, also in that report you can read:

(In reply to comment #32)
> I think that the parallel feature is one of the indicator of healthy init
> layout implementation.
> A lot of effort was invested in making it happen.
> Giving it up is not the solution.

We're not going to give it up of course!

Because nobody needs a X12.

http://mirror.linux.org.au/linux.conf.a ... _and_X.ogv

Maybe you don't, this is your opinion, in that video he states exactly my point "We are not the X consortium" and that X wasn't updated, but just patched up, for centuries
Maybe if they refined and updated X11, instead of endlessly working around it, it could have been better, but they didn't, so Wayland is born, which isn't a bad thing, this still doesn't explain Mir.

[nachoig]

OSS is dead. Mixing in the kernel space is a bad idea, no power management, no Bluetooh, no USB audio and no modern application supporting it. OK, it has active development, but it was forgotten.

Why? This is your own opinion. Many developers actually think kernel mixing has less latency, leads to simpler implementation and allows smarter scheduling. Power management can still be implemented, OSS4 hasn't that feature in Linux, simply because they didn't think OSS would have been adopted there, and they were right. Also most of OSS deadness is related to its old Linux implementation, which was horrible and rightfully criticized and deprecated.
As explained here:
https://en.wikipedia.org/wiki/Open_Sound_System#OSS_in_relation_to_ALSA
http://manuals.opensound.com/developer/audio_myths.html (Doing "mixing" in kernel space (drivers) is evil)

Many application doesn't have any compatibility with OSS, simple.

Mixing in the kernel is not a good idea. Windows Vista, 7 and 8 don't do this. OS X doesn't do this. It's about security. The use of an exploit here can be used to gain the control over the kernel.

I meant that the desktop oriented features, like per application volume and on the fly audio output switch, could be easily implemented with ALSA, or with external ALSA shared libraries, in a simpler fashion, having a single well focused project. Network audio streaming could be achieved much better with a dedicated multimedia oriented daemon, and there are lots of them. Such approach would lead to a more modular and more rational organization, that PulseAudio doesn't have in my opinion. PulseAudio actually does a lot of behind the scenes work to try to minimize its latency, in a way similar to Windows Vista, this makes it quite resource hungry with its memory, some applications (especially games and multimedia oriented applications) don't need that extra work and would be more efficient without it, since they already perform some kind of latency minimization (like game engines for example).

I don't see a concrete problem here. Anyway, alsa-lib doesn't have anything about those.

Actually ArchLinux does exactly that, invoking shell script for many services, for example cpupower. Anyway I didn't say it's better, I said it is debatable, you might want that or you might trade off some simplicity over flexibility. I meant that implementing many of the systemd features is just a matter of implementing them, sysV style scripts aren't really a problem for that.

https://www.archlinux.org/news/final-sy ... n-warning/

Actually there is even a standard for init scripts:
http://refspecs.linuxfoundation.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/tocsysinit.html

Agreeing to a standard for init scripts would make them portable, unfortunately, despite the existence of such standard, many sysV like init systems don't conform (I think even OpenRC dependencies aren't LSB standard).

LSB was never a standard de facto, and this doesn't apply only with the init scripts.

Maybe you don't, this is your opinion, in that video he states exactly my point "We are not the X consortium" and that X wasn't updated, but just patched up, for centuries
Maybe if they refined and updated X11, instead of endlessly working around it, it could have been better, but they didn't, so Wayland is born, which isn't a bad thing, this still doesn't explain Mir.

The problem with X is not if they are or not the X consortium, that is not a relevant issue, the problem with X is about concept, it's about the archtecture behint that.

[micia]

So every kernel module is a security issue, because it could be exploited to gain priviledges over the machine, you should use Minix or any other microkernel if you want to avoid that.
Kernel mixing is not a security issue, it just performs mixing in kernel instead of userspace, and the mixing is performed by OSS itself, so it hardly is buggy or security error prone, it is simply a different approach with advantages and disadvantages.
OSS is supported very well, actually more than ALSA, since OSS is standard for any UNIX out there, while ALSA is standard only on Linux, can you name an application that offers ALSA support but not OSS? I can think of some that do the opposite, especially commercial ones. Also standards are there to be followed, it doesn't help if some standards are imposed because other standards aren't followed, such as PulseAudio or Systemd, they usually increase fragmentation instead of reducing it.
The fact that ArchLinux uses Systemd doesn't mean it doesn't call shell scripts from unit files instead of completely avoiding shell on boot, many of their unit files do that.
About X, my point is that you can't ask to a concept to be valid for 30 years without a single update, it's obvious that it can't work, we should actually be surprised that X worked that well. But this topic isn't about X being old, it's about Mir not having a reason to exist other than being a proprietary Canonical fork of Wayland.

Anyway it is getting a bit off topic, we have different opinions and that's all, as we all know, you can't change people opinion over the internet and flame wars are bad (luckily this isn't one, but better be safe than sorry)

[Ryuno-Ki]

About X, my point is that you can't ask to a concept to be valid for 30 years without a single update, it's obvious that it can't work, we should actually be surprised that X worked that well.

I am. There must be genious back then …

Anyway it is getting a bit off topic

Ehm … we're in the Off Topic shed here …

[nachoig]

So every kernel module is a security issue, because it could be exploited to gain priviledges over the machine, you should use Minix or any other microkernel if you want to avoid that.

Hey, we don't live in a perfect world!

Kernel mixing is not a security issue, it just performs mixing in kernel instead of userspace, and the mixing is performed by OSS itself, so it hardly is buggy or security error prone, it is simply a different approach with advantages and disadvantages.
OSS is supported very well, actually more than ALSA, since OSS is standard for any UNIX out there, while ALSA is standard only on Linux, can you name an application that offers ALSA support but not OSS? I can think of some that do the opposite, especially commercial ones. Also standards are there to be followed, it doesn't help if some standards are imposed because other standards aren't followed, such as PulseAudio or Systemd, they usually increase fragmentation instead of reducing it.

So, where is the real advantage to run it the kernel space? Is this travel really necessary? It's hard to care about a standard when this standard is a looser like OSS or pure ALSA. Let's compare with video rendering...

The fact that ArchLinux uses Systemd doesn't mean it doesn't call shell scripts from unit files instead of completely avoiding shell on boot, many of their unit files do that.

OK, I checked this folder in my Arch: /usr/lib/systemd/scripts/

Only 2 scripts.

About X, my point is that you can't ask to a concept to be valid for 30 years without a single update, it's obvious that it can't work, we should actually be surprised that X worked that well. But this topic isn't about X being old, it's about Mir not having a reason to exist other than being a proprietary Canonical fork of Wayland.

Mir is not a fork of Wayland.

X is working yet thanks to X.org developers. Also, many of Wayland developers are or was X.org developers. We are in good hands.

Anyway it is getting a bit off topic, we have different opinions and that's all, as we all know, you can't change people opinion over the internet and flame wars are bad (luckily this isn't one, but better be safe than sorry)

Off-topic. Where are we?
Board index ‹ Sabayon Linux ‹ Off Topic

[micia]

Kernel space mixing is not necessary, it's like saying why is mergesort necessary, we got quicksort, it has its advantages and disadvantages. It's just a different approach, you get synchronization for free, you save some sample copying all over the place, the kernel knows exactly when and who is mixing audio, thus it might apply some heuristics for scheduling. It might be better under some circumstances. With userspace mixing you don't have such advantages, but you get others, less code in kernel and maybe a better use of the CPU features. Linux Kernel Mode Setting adds more kernel space code, but it is not that bad.

About Mir I meant that it does basically the same as Wayland (so I abused the fork word), the differences they are aiming for (if any) do not justify the extra fragmentation you get in the Linux scene. Sometimes developers need standards, you can't create decent applications without a clear way to code graphics, right now you won't get far in Linux without using some utility library like SDL providing a consistent interface to the Linux, and Unix in general, fragmentation.
It would be nice to avoid that at least for simple tasks.

I am sure that Wayland is a good project, I like its concept, I am definitely not against it, but I am not convinced that X is that bad.
I am against unnecessary fragmentation, I'd love to see just one standard after this big change, be it X or Wayland.

I thought we were deviating from the original topic which was not about ALSA vs OSS or about X being flawed, but about PulseAudio and Systemd (and incidentally about Mir), hence my off topic into the off topic warning. I merely brought OSS4 as a "better approach" to audio, since, in my opinion, it brings the desktop oriented features of PulseAudio without the extra complexity, I didn't mean to focus on kernel space mixing.

[nachoig]

Kernel space mixing is not necessary, it's like saying why is mergesort necessary, we got quicksort, it has its advantages and disadvantages. It's just a different approach, you get synchronization for free, you save some sample copying all over the place, the kernel knows exactly when and who is mixing audio, thus it might apply some heuristics for scheduling. It might be better under some circumstances. With userspace mixing you don't have such advantages, but you get others, less code in kernel and maybe a better use of the CPU features. Linux Kernel Mode Setting adds more kernel space code, but it is not that bad.

If your kernel or the video drivers are in trouble, you will see a message with kernel mode setiing. With userspace mode setting, this is not possible. And modestting in the kernel is just about setting display resolution, not rendering video. Plus, with mode setting in the kernel, you can gain a better boot splash.

But in my opinion, mixing sound in the kernel space is like rendering video in the kernel space. It's very strange, isn't it? In the kernel space, we should run only the essential or critical. And sound mixing is not a critical or essential thing.

[sabayonino]

https://www.sabayon.org/article/what%E2 ... %80%99-bbq

lxnay wrote :

leh systemd

I spent a week working on a Sabayon systemd system to see how it works and performs compared to openrc. Long story short, I am about to arrange some ideas on making the systemd migration come true at some point in the (near) future. Joost and I are experimenting with a private Entropy repository (thus chroot) that’s been migrated to systemd, from openrc. While I don’t want to start yet another flamewar about openrc vs systemd, I do believe in science, facts and benchmarks. Even though I don’t really like the horizontal architecture of systemd, I am starting to appreciate its features and most importantly, its performance. The first thing I would like to sort out is to be able to switch between systemd and openrc at runtime, this may involve the creation of an eselect module (trivial) and patching some ebuilds. I think that’s the best thing to do, if we really want to design and deploy a migration path for current openrc users (I would like to remind people that Gentoo is about choice, after all). If you’re a Gentoo developer that hasn’t been bugged by me yet, feel free to drop a line to lxnay@g.o (expand the domain, duh!) if you’re interested.