micia wrote:nachoig wrote: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.
micia wrote:any feature provided by the PulseAudio server could be achieved extending ALSA itself,
micia wrote: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.
Description=CUPS Printing Service
micia wrote: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.
micia wrote: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...
nachoig wrote: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.
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...
Look at a startup shell script and look at this:
- Code: Select all
Description=CUPS Printing Service
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.
Christian Ruppert wrote:(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
micia wrote:nachoig wrote: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:
http://manuals.opensound.com/developer/audio_myths.html (Doing "mixing" in kernel space (drivers) is evil)
micia wrote: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).
micia wrote: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.
micia wrote:Actually there is even a standard for init scripts:
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).
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.
micia wrote: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.
micia wrote:Anyway it is getting a bit off topic
micia wrote: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.
micia wrote: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.
micia wrote: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.
micia wrote: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.
micia wrote: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)
micia wrote: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.
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 [email protected] (expand the domain, duh!) if you’re interested.
Users browsing this forum: No registered users and 2 guests