Phoronix News Bot
Fedora 18 Approves Controversial Feature
Phoronix: Fedora 18 Approves Controversial Feature
At the FESCo meeting on Monday, aside from Fedora reaffirmining their commitment towards the GCC compiler, the FESCo members also approved some new features for Fedora 18. One of the approved features has already sparked the grievance of Lennart Poettering...
http://www.phoronix.com/vr.php?view=MTEwMzQ
Senior Member
Big LOL
[A bit of irony] Oh my, now the guy that created init-ng (systemd) and alsa-ng (Pulseaudio) is criticizing the addition of procps-ng on its distro...That's the progress Lennart! [/end of irony]
Btw, Arch is already using props-ng. I didn't have any problems when I did the upgrade, so I don't see what's the big deal of using procps-ng vs procps...
Cheers
p.s.: Btw, "init-ng" works pretty well, but the same can't be said about "alsa-ng"...
Phoronix Member
I suspect Lennart wanted to do it with another module added to systemd.
I like the core idea of systemd, I think I like the idea of pulseaudio. What I don't like is turning LInux into something inscrutable.
Windows "just works" 95% of the time, but when it doesn't work, it's inscrutable. Linux "just works" less often, but because you can scrute it, you can fix it. There must be a third way, to get that "just works" number up there without sacrificing hackability.
Red Hat
You could try reading the thread, instead of guessing. Lennart thinks the functionality should be in in util-linux, not systemd.
PulseAudio is not alsa-ng and systemd is not init-ng. Neither PA nor systemd are a fork of existing code claiming to be the 'true successor'. PA is not in any sense an ALSA replacement; it sits higher up the stack than ALSA and works with it. PA would be useless without ALSA, indeed. systemd is not a drop-in replacement for any existing init system exactly but an alternative approach to init. It doesn't claim to be the 'true successor' of sysv or upstart or anything else. So neither is a -ng project in the sense Lennart indicts.
Phoronix Member
yes, please people stop compairing alsa to pulseaudio, its different levels. you can compair alsa's dmix vs pulse, but dmix is really a hack to try and solve the issue of a need for multiple sound sources when you dont have hardware mixing (or even if you do, hardware mixing is not the birthday cake it was made out to be, usualy it was just a carrot cake, yuck).
as for procps-ng, this seems to jut be a bunch of end user programs to report ifromation or send commands to the kernel. this shouldnt be a big issue is fedora picked out the wrong package solution. it would be just as easy to swithc to a different one later. its not like picking systemd or pulseaudio pr dbus where now it affects how you make other programs communicate with the system.
Senior Member
Well, I aknowledge that PA and systemd aren't forks from ALSA and init, respectively... And that PA is a layer that works over ALSA...Originally Posted by AdamW
Btw, I've been using systemd for over a year on Arch and so far, I already got (completely) rid of sysvinit... So, personally, It's (for me) a replacement of sysvinit...
If Lennart stated that procps-ng should be merged with util-linux, it wouldn't be a bad idea... ATM, I think there's a big dependency hell problem that some distros suffer, and some "core" apps should be merged with other ones...
Cheers
@benjamin545: I don't want to argue here which is the best audio application/layer for linux. For me, dmix works pretty well for my 5.1 sound system / laptop and allows me to play multiple audio streams simultaneously without problems... What I'd like to see a day is PA using the ALSA kernel modules directly...
Phoronix Member
pa using the kernel modules directly? like a microkernel? thats how X11 USE to work, where the x server actualy ran the code that drove the graphics hardware. it was horribad, X had to run as root so it coulde have direct access to the hardware and therefore was a huge security hole and performed worse than if the kernel directly handeled the hardware.
pulseaudio talks directly to the kernel via the alsa api, it uses the alsa library in its alsa audio sink module. its just like how a xorg ddx driver uses libdrm to talk to the drm part of the kernel who directly operates the hardware nowadays.
the alsa dmix way wasnt really any different. im pretty shure dmix was just a procces that ran and alsa had a dumby sound card that would send audio streams out to dmix, and then dmix would mix the sounds in software, and then send them out to the real alsa audio card. a lot of disros set it up for you, but i actauly had to try to set it al up myself before in gentoo. you basicaly created a .asound orwhatever the alsa configure file is and pipe it all around so it will work.
all pulseaudio is doing is doing the same thing with a much broader scope of advertised capabilities (sometimes those capabilities can be a little buggy, like all new stuff) while not really lying to you about what its doing like alsa kinda was.(maybe not lie, but people dont really seem to understand HOW alsa was mixing sound because people dont reallize alsa has become the name of a large project that goes beyond te initial scope of making audio drivers for linux)
alsa dmix is not the same as alsa drivers or alsa mixer(the ncurses based gui for configure audio cards) its like mesa if the name of the opengl like graphics api and implementation. but mesa is a lot more than that, CLover is in the mesa source tree but its a very seperate part. mesa is now the project that operates and develops the gallium3d stack, opengl(both state tracker and stand alone) implementation, clover state tracker, the vaapi state tracker, opengl es state tracker, openvg state tracker, and the various hardware backends that talk to the kernels drm interface for each specific gpu architecture they are designed to do. all of that is "mesa" yet most people think of it all as one big program. but if say we went out and made the super duper opengl implementation and gave it a gallium3d backend, we would have done nothing dfferent than what pulseaudio did. we just replaced dmix with a new componant. we did this because dmix was not developed as a full sound dameon like it was being used as. dmix was hampered by the fact that it was trying to make the alsa api act as if it was a sound api which it IS NOT. alsa is at the same level as drm, it is an api for a sound manager to direct sound to the kernel. it was wrong for people to make programs talk directly to alsa like that, it would be like writing a 3d game using drm. techincaly it could be done but its a horrible idea. alsa api is ment to transport the audio streams directly from the source to the hardware without any stage proccessing on it. thats perfect if you are a sound deameon and hae already proccessed it, but if you are a end user program, you want t be compleatly abstracted from the hardware as possible. alsa didnt reallly do that, it tried to make the defaults as generic as possible, but that didnt really solve al the problems, it just make simple sound setups work ok. pulse allows you to keep theend peogram from having to know much at all about what the hardware is capable of, only what pulseaudio is currently configured as, with being able to change on the fly.
Senior Member
Merging the contents of procps into util-linux *would* make some sense - the latter is already a repository for miscellaneous Linux-specific utilities, and the former certainly meets that definition.
But I don't think this is the occasion for Lennart to make a fuss about the idea - all that's happened is that Fedora has agreed to move from the dead procps project to the actively maintained procps-ng fork. If that project should be merged into another, that's something to discuss with the relevant projects - not the subject of a rant on a distro's mailing list.
Posting Permissions
Reply With Quote