[arch-general] change in mount behaviour?
Hi all, i used to keep a folder in /media to serve as mountpoint if some manual mountis was needed. since some days, this folder disappeared, even if created again. is there any change in filesystems, kernel or whatsoever changing behavior there, is it intended (if so, why?) or a bug? every hint appreciated. georg
Am 28.01.2012 00:26, schrieb G. Schlisio:
Hi all, i used to keep a folder in /media to serve as mountpoint if some manual mountis was needed. since some days, this folder disappeared, even if created again. is there any change in filesystems, kernel or whatsoever changing behavior there, is it intended (if so, why?) or a bug? every hint appreciated. georg
# mount tmpfs on /media type tmpfs (rw,nosuid,nodev,noexec,relatime,mode=755) ok, but thats one half only…
On Sat, Jan 28, 2012 at 12:35 AM, G. Schlisio <g.schlisio@gmx.de> wrote:
Am 28.01.2012 00:26, schrieb G. Schlisio:
Hi all, i used to keep a folder in /media to serve as mountpoint if some manual mountis was needed. since some days, this folder disappeared, even if created again. is there any change in filesystems, kernel or whatsoever changing behavior there, is it intended (if so, why?) or a bug? every hint appreciated.
If you are using initscripts this should not happen. If you are using systemd it should. The justification being that /media is meant for ephemeral mount points (i.e. stuff created by udisks et al.). -t
On Sat, Jan 28, 2012 at 12:50:09AM +0100, Tom Gundersen wrote:
On Sat, Jan 28, 2012 at 12:35 AM, G. Schlisio <g.schlisio@gmx.de> wrote:
Am 28.01.2012 00:26, schrieb G. Schlisio:
Hi all, i used to keep a folder in /media to serve as mountpoint if some manual mountis was needed. since some days, this folder disappeared, even if created again. is there any change in filesystems, kernel or whatsoever changing behavior there, is it intended (if so, why?) or a bug? every hint appreciated.
If you are using initscripts this should not happen.
If you are using systemd it should. The justification being that /media is meant for ephemeral mount points (i.e. stuff created by udisks et al.).
Wouldn't most users associate /media with cd, dvd etc. ? Seems like on odd name for what systemd uses it for. Ciao, -- FA Vor uns liegt ein weites Tal, die Sonne scheint - ein Glitzerstrahl.
On Fri, Jan 27, 2012 at 5:56 PM, Fons Adriaensen <fons@linuxaudio.org> wrote:
Wouldn't most users associate /media with cd, dvd etc. ? Seems like on odd name for what systemd uses it for.
for as long as i remember anyway, the DE will often mount stuff there automatically, ergo it's not safe to put manual mount points there. /mnt is specifically reserved for admin, so /mnt/media is safe. under systemd, /media is a tmpfs. -- C Anthony
Am Fri, 27 Jan 2012 19:41:54 -0600 schrieb C Anthony Risinger <anthony@xtfx.me>:
On Fri, Jan 27, 2012 at 5:56 PM, Fons Adriaensen <fons@linuxaudio.org> wrote:
Wouldn't most users associate /media with cd, dvd etc. ? Seems like on odd name for what systemd uses it for.
for as long as i remember anyway, the DE will often mount stuff there automatically, ergo it's not safe to put manual mount points there. /mnt is specifically reserved for admin, so /mnt/media is safe.
This is not true. If this is what some DEs are doing, than you should file a bug report to the DE's upstream.
under systemd, /media is a tmpfs.
The same for systemd. There's a Linux Filesystem Hierarchy Standard which says that /media is meant for removable media and /mnt is for temporarily mounted filesystems. Whatever the difference between an optical media and a temporary filesystem may be. http://www.pathname.com/fhs/pub/fhs-2.3.html#MEDIAMOUNTPOINT I know that Lennart Poettering doesn't care much about Linux standards and likes to declare his non working crap as standard. But fortunately he is not a standardization authority. So if a software doesn't follow those FHS you should file a bug report to upstream. And yes, /media is supposed to contain subdirectories for cd, dvd, etc. Nevertheless /media was also invented by SUSE in the past, because originally those optical media was also meant to be mounted to subdirectories of /mnt. Nevertheless meanwhile FHS was changed to include /mnt as well as /media for whatever reasons. Heiko
On Fri, Jan 27, 2012 at 8:39 PM, Heiko Baums <lists@baums-on-web.de> wrote:
Am Fri, 27 Jan 2012 19:41:54 -0600 schrieb C Anthony Risinger <anthony@xtfx.me>:
On Fri, Jan 27, 2012 at 5:56 PM, Fons Adriaensen <fons@linuxaudio.org> wrote:
Wouldn't most users associate /media with cd, dvd etc. ? Seems like on odd name for what systemd uses it for.
for as long as i remember anyway, the DE will often mount stuff there automatically, ergo it's not safe to put manual mount points there. /mnt is specifically reserved for admin, so /mnt/media is safe.
This is not true. If this is what some DEs are doing, than you should file a bug report to the DE's upstream.
well ... gnome3 is doing it right now, and IIRC kde4 did as well, been quite awhile since i used that though. i want to say xfce did it too ... but it's been even longer since i used that. this functionality is provided thru udisks/dbus, and it seems perfectly reasonable to me.
under systemd, /media is a tmpfs.
The same for systemd.
the same what? file a bug? systemd does this because the mounts/directory structure are ephermal. there may be other reasons i'm unaware of, but i don't see a problem.
There's a Linux Filesystem Hierarchy Standard which says that /media is meant for removable media and /mnt is for temporarily mounted filesystems. Whatever the difference between an optical media and a temporary filesystem may be.
http://www.pathname.com/fhs/pub/fhs-2.3.html#MEDIAMOUNTPOINT
yes i'm quite familiar with the FHS, and have read the spec in depth, as packaging/deployment is of great interest to me. while my own designs take the FHS into consideration, there is no reason to believe their are not better schemes, esp. consideration the current age of virtualization and usage patterns. IMO at least, the document is clearly outdated, and i've read more than once that the maintainers are non-responsive to requests for amendment/alteration.
I know that Lennart Poettering doesn't care much about Linux standards and likes to declare his non working crap as standard. But fortunately he is not a standardization authority.
So if a software doesn't follow those FHS you should file a bug report to upstream.
well, i can't say i care much about the FHS either. IMO, systemd/pulseaudio work fantastic, and are orders of magnitude better than their predecessors, and only move the ecosystem forward. i also make extensive use of avahi/libnss-mdns/libnss-myhost ... soooo, they seem to work OK ;-) there are many contributors to these projects ... he's not a one-man band.
And yes, /media is supposed to contain subdirectories for cd, dvd, etc. Nevertheless /media was also invented by SUSE in the past, because originally those optical media was also meant to be mounted to subdirectories of /mnt. Nevertheless meanwhile FHS was changed to include /mnt as well as /media for whatever reasons.
i see no reason to include those directories unconditionally, nor any reason to avoid alternatives. -- C Anthony
Am Fri, 27 Jan 2012 21:21:01 -0600 schrieb C Anthony Risinger <anthony@xtfx.me>:
well, i can't say i care much about the FHS either. IMO, systemd/pulseaudio work fantastic, and are orders of magnitude better than their predecessors, and only move the ecosystem forward. i also make extensive use of avahi/libnss-mdns/libnss-myhost ... soooo, they seem to work OK ;-)
Do I really need to repeat it? PulseAudio and ice1712? No, PulseAudio doesn't work fantastic, it's pure crap as long as it can't handle every sound and audio card, which ALSA, btw., does perfectly out-of-the-box. And, no, artificially crippling a (semi-)professional audio card down to stereo with a strange ALSA configuration is not a solution for this. And, no, it's not ALSA's fault like Lennart Poettering says, it's PulseAudios fault. And why should I trust other software by Lennart Poettering if he isn't able to get this one software working perfectly. And, yes, he tried to declare this PulseAudio crap as a standard. Heiko
OT: PulseAudio On Sat, 2012-01-28 at 14:02 +0100, Heiko Baums wrote:
IMO, systemd/pulseaudio work fantastic, and are orders of magnitude better than their predecessors, and only move the ecosystem forward. No, PulseAudio doesn't work fantastic, it's pure crap as long as it can't handle every sound and audio card, which ALSA, btw., does
Am Fri, 27 Jan 2012 21:21:01 -0600 schrieb C Anthony Risinger <anthony@xtfx.me>: perfectly out-of-the-box.
And, no, artificially crippling a (semi-)professional audio card down to stereo with a strange ALSA configuration is not a solution for this.
The majority of Linux users on non-audio Linux mailing lists praise PA, OTOH as soon as they run into trouble regarding to PA, the Linux "pro-"audio users will help them to fix it, usually it's not that majority of users who praise PA, giving the needed hints. I always had issues with PA and I never had an issue when I replaced PA by dummy packages, but seemingly there's a work flow by a majority of Linux users, where having PA installed is an advantage. You might take a look at Debian users mailing list. On KDE4 PA is using 2% CPU already when doing nothing. For some people using 2% for nothing isn't a bug, it's ok for them.
And why should I trust other software by [someone] if he isn't able to get this one software working perfectly.
Why should I trust that a musician is a good drummer, when she's a bad guitarist? Perhaps because she's a drummer ;). - Ralf
Am Sat, 28 Jan 2012 15:29:33 +0100 schrieb Ralf Mardorf <ralf.mardorf@alice-dsl.net>:
The majority of Linux users on non-audio Linux mailing lists praise PA, ...
And the most computer users use Windows. So what's the point? That doesn't mean that Windows is better than Linux or that Windows works perfectly. I'm sure that most Linux users just use their stereo or maybe surround SoundBlaster like or onboard AC'97 sound card and not a (semi-)professional audio card. For those people PulseAudio may work, but that doesn't mean that it really works, because they just don't see all the flaws. And it definitely doesn't work with those ice1712 cards. And I've seen a lot of discussions in Linux and IT forums where PulseAudio absolutely wasn't praised, where most users said that it is crap or at least unnecessary, because of the missing hardware support, and because most of the features are already done by ALSA itself out-of-the-box.
I always had issues with PA and I never had an issue when I replaced PA by dummy packages, but seemingly there's a work flow by a majority of Linux users, where having PA installed is an advantage.
You might take a look at Debian users mailing list. On KDE4 PA is using 2% CPU already when doing nothing. For some people using 2% for nothing isn't a bug, it's ok for them.
So you see, that some people just don't care, maybe because they don't know better. I would call those 2% buggy and a waste of resources. Another reason not to using PulseAudio.
Why should I trust that a musician is a good drummer, when she's a bad guitarist? Perhaps because she's a drummer ;).
This comparison is flawed. A guitarist wouldn't go on stage and drum, if he can't drum, and vice versa. But Lennart writes a software for something he at least doesn't know enough about (PulseAudio) and tries to have this declared as standard, and at the same time writes another software (systemd), which also has several issues or is at least not really compatible with existing systems or script as far as I know, instead of first fixing the first one, so that it really works. And then he thinks he has to get involved in other things at the same time. This is something completely different, and this is what I'm worried about. If he would do one thing and would really try to fix its issues and he would really try to learn how to fix them, I wouldn't say much. But I don't see this. So how should I trust him and his software if he gets himself involved in several different things if he's not able to do the one and even the other thing correctly? Heiko
2012/1/28 Heiko Baums <lists@baums-on-web.de>:
Am Sat, 28 Jan 2012 15:29:33 +0100 schrieb Ralf Mardorf <ralf.mardorf@alice-dsl.net>:
The majority of Linux users on non-audio Linux mailing lists praise PA, ...
And the most computer users use Windows. So what's the point? That doesn't mean that Windows is better than Linux or that Windows works perfectly.
I'm sure that most Linux users just use their stereo or maybe surround SoundBlaster like or onboard AC'97 sound card and not a (semi-)professional audio card.
For those people PulseAudio may work, but that doesn't mean that it really works, because they just don't see all the flaws. And it definitely doesn't work with those ice1712 cards. And I've seen a lot of discussions in Linux and IT forums where PulseAudio absolutely wasn't praised, where most users said that it is crap or at least unnecessary, because of the missing hardware support, and because most of the features are already done by ALSA itself out-of-the-box.
I always had issues with PA and I never had an issue when I replaced PA by dummy packages, but seemingly there's a work flow by a majority of Linux users, where having PA installed is an advantage.
You might take a look at Debian users mailing list. On KDE4 PA is using 2% CPU already when doing nothing. For some people using 2% for nothing isn't a bug, it's ok for them.
So you see, that some people just don't care, maybe because they don't know better. I would call those 2% buggy and a waste of resources. Another reason not to using PulseAudio.
Why should I trust that a musician is a good drummer, when she's a bad guitarist? Perhaps because she's a drummer ;).
This comparison is flawed. A guitarist wouldn't go on stage and drum, if he can't drum, and vice versa. But Lennart writes a software for something he at least doesn't know enough about (PulseAudio) and tries to have this declared as standard, and at the same time writes another software (systemd), which also has several issues or is at least not really compatible with existing systems or script as far as I know, instead of first fixing the first one, so that it really works. And then he thinks he has to get involved in other things at the same time. This is something completely different, and this is what I'm worried about.
If he would do one thing and would really try to fix its issues and he would really try to learn how to fix them, I wouldn't say much. But I don't see this. So how should I trust him and his software if he gets himself involved in several different things if he's not able to do the one and even the other thing correctly?
Heiko
Does this really need to be rehashed yet again? This isn't arch related yet these PA back and forths keeps popping up in the mailboxes of all the registered people looking for arch-related content. I didn't follow the original discussion so I cant argument on that extent, but the last thing we need on this list is more noise.
Am Sat, 28 Jan 2012 18:22:05 +0100 schrieb Stefan Wilkens <stefanwilkens@gmail.com>:
Does this really need to be rehashed yet again? This isn't arch related yet these PA back and forths keeps popping up in the mailboxes of all the registered people looking for arch-related content.
I didn't follow the original discussion so I cant argument on that extent, but the last thing we need on this list is more noise.
I guess there's a reason why this always pops up on several mailing lists. I would say it's just related to Lennart Poettering who has also developed systemd which was originally mentioned regarding the mount behaviour, and who thinks he needs to take part on the discussion about the FHS and thinks he needs to change every standard. And both tools shall be declared as a new Linux standard (that's at least my impression) even if both don't work very well, don't support every hardware or are just unnecessary (PulseAudio) or have issues regarding incompatibilities (systemd). That's the point and that's why you always will read PulseAudio in threads which are at least partly related to Lennart Poettering or his software. If Lennart would either fix all those issues in PulseAudio and systemd, so that they would really work for everybody and would really bring advantages for everybody or at least no disadvantages, or if his software would just be optional and not needed as a dependency by some distros or DEs, I'm pretty sure this discussion wouldn't always pop up again. Heiko
On Sat, Jan 28, 2012 at 11:34 AM, Heiko Baums <lists@baums-on-web.de> wrote:
If Lennart would either fix all those issues in PulseAudio and systemd, so that they would really work for everybody and would really bring advantages for everybody or at least no disadvantages, or if his software would just be optional and not needed as a dependency by some distros or DEs, I'm pretty sure this discussion wouldn't always pop up again.
dear Lennart and co., the community would appreciate software that is 100% free of all bugs, now and forever. we expect these things to work with every card ever manufactured, even stuff 10yrs obsolete or in the 1% of use cases. and no, before you ask, just working is not good enough, please be sure that all possible features are exposed. also, ensure your software integrates perfectly with legacy systems and perfectly with future systems that haven't been thought of. lastly, after achieving completely awesome and 150% interoperability (must include future), make sure that your software is 100% optional and free of dependencies in either direction. seriously, if you can't hit this entry-level 3rd grade target, there is no hope of becoming a l33t linnicks developer, and you should right fuxxor off, guy. signed, Your Friends in the Community ...... haha, i make myself laugh, that's all that really matters. is this roughly message you want to send? both PA and systemd already do a pretty good job coping with legacy stuff, in two areas that are *notorious* for their excessive proliferation ... you seem to have some basic misunderstandings of ALSA/alsa-lib/init ... you do know that init doesn't actually do *anything*, right? i reimplemented init in ~40 lines of bash years ago for LXC containers ... and it was full-featured, supporting all signals, and even inittab. that shiz was unfixable garbage imo. i think if you read a bit more ... eg. man pages, documentation, introductory blogs/etc, and not rants by random-equally-infuriated users ... you may find some reason, and *maybe* even some use. ftw, PA idles at 0% CPU for me, and when streaming over the network to an XBMC sound system, it uses a steady average 1-2% (actually brief intermittent bursts at 10% or so) ... nothing outrageous ...meanwhile, FF consumes 3-5% to run flash, and flash consumes 8-10% to run Pandora ... PA is the lightest link in the chain. ... and that's a wrap on this topic, for me that is. -- C Anthony
On Sat, 2012-01-28 at 12:37 -0600, C Anthony Risinger wrote:
dear Lennart and co.,
make sure that your software is 100% optional and free of dependencies in either direction.
signed,
Your Friends in the Community
Dear my Friends in the Community, PA already is optional. Please test what happens, if you replace it with a dummy package. $ cat PKGBUILD pkgname=pulseaudio-dummy pkgver=1.0 pkgrel=1 pkgdesc="A dummy package that pretends to provide pulseaudio." arch=('any') url="" license=('BSD') provides=('pulseaudio') conflicts=('pulseaudio') source=() Is anything broken for you, if you replace it by this package? signed, Oc Dna Trannel
Am Sat, 28 Jan 2012 12:37:14 -0600 schrieb C Anthony Risinger <anthony@xtfx.me>:
is this roughly message you want to send?
No, this is not the message, and I guess you totally misunderstood me. The problem is that PulseAudio is not working with every sound and audio card, but users are forced to install it as a dependency by some distros and/or DEs, even if it doesn't support several audio cards. And the problem is that this leads to being called PulseAudio as a standard even if it doesn't support a lot of sound and audio cards, so that sound probably wouldn't work with those cards some day. And the problem is upstream's reaction on bug reports about this, that they say something like "it's ALSA's fault that our software doesn't work with your audio card" even if ALSA supports these card perfectly out-of-the-box, etc. So to me it just sounds like "We want our software to be a standard but we just don't care about hardware we don't understand, and we just ignore it." That are the problems. Like I said before, if PulseAudio was just another piece of software which I can install or not, I totally wouldn't care about it. But as soon as someone forces me to installing this, I do care. Well, I'm currently using Arch Linux and Xfce. So I'm not, yet, forced to install it. But I'd like to keep it this way.
i think if you read a bit more ... eg. man pages, documentation, introductory blogs/etc, and not rants by random-equally-infuriated users ... you may find some reason, and *maybe* even some use. ftw, PA idles at 0% CPU for me, and when streaming over the network to an XBMC sound system, it uses a steady average 1-2% (actually brief intermittent bursts at 10% or so) ... nothing outrageous ...meanwhile, FF consumes 3-5% to run flash, and flash consumes 8-10% to run Pandora ... PA is the lightest link in the chain.
I didn't say anything about PulseAudio's CPU usage. That was someone else. I just answered that 2% CPU usage at idle time would be too much. Actually I don't know how many resources it needs. Heiko
Heiko, Maybe I (or others) were unclear in our explanations, but at least you should have had a look at the software you are claiming to be buggy (you would quickly see that there is no problem). On Sat, Jan 28, 2012 at 3:39 AM, Heiko Baums <lists@baums-on-web.de> wrote:
for as long as i remember anyway, the DE will often mount stuff there automatically, ergo it's not safe to put manual mount points there. /mnt is specifically reserved for admin, so /mnt/media is safe.
This is not true. If this is what some DEs are doing, than you should file a bug report to the DE's upstream.
This is what all DEs I'm aware of have been doing for a long time. They create mountpoints and mount removable media under /media, which is perfectly in line with the FHS.
There's a Linux Filesystem Hierarchy Standard which says that /media is meant for removable media and /mnt is for temporarily mounted filesystems. Whatever the difference between an optical media and a temporary filesystem may be.
"Whatever the difference [...] may be", this should give you a hint that there is something you are missing...
http://www.pathname.com/fhs/pub/fhs-2.3.html#MEDIAMOUNTPOINT
I know that Lennart Poettering doesn't care much about Linux standards and likes to declare his non working crap as standard. But fortunately he is not a standardization authority.
Please stop this nonsense. First of all, the way in which /media is (and has been) used has nothing to do with Lennart. Secondly, the FHS has not been breached in this instance. Thirdly, anyone who knows anything about these matters agree that the FHS is outdated and needs to be rewritten (and that until it is, we should not care too much about it).
So if a software doesn't follow those FHS you should file a bug report to upstream.
This is a waste of time. The upstream developers are well aware of the FHS. If their apps violate it, it is intentional. -t
Am Sat, 28 Jan 2012 11:24:47 +0100 schrieb Tom Gundersen <teg@jklm.no>:
Maybe I (or others) were unclear in our explanations, but at least you should have had a look at the software you are claiming to be buggy (you would quickly see that there is no problem).
Again, PulseAudio which Lennart Poettering likes to have as a standard completely doesn't work with (semi-)professional audio cards with an ice1712 chip. Yes, I had a look at PulseAudio. And as I already asked previously, why should I believe that his other software really works if he's not able to get that one software working. And, yes, there are incompatibilities in systemd. As far as I read there are a lot of initscripts which don't work with systemd and therefore have/had to be rewritten to get them working with systemd. Where's the bug? In the scripts or in systemd?
This is what all DEs I'm aware of have been doing for a long time. They create mountpoints and mount removable media under /media, which is perfectly in line with the FHS.
If they create a subdirectory under /media it's indeed corresponding to the FHS.
"Whatever the difference [...] may be", this should give you a hint that there is something you are missing...
Then explain it to me. An optical drive is also only mounted temporarily. I don't see a difference between mounting a harddisk temporarily or mounting a dvd temporarily. Maybe you can explain the difference.
Please stop this nonsense. First of all, the way in which /media is (and has been) used has nothing to do with Lennart. Secondly, the FHS has not been breached in this instance. Thirdly, anyone who knows anything about these matters agree that the FHS is outdated and needs to be rewritten (and that until it is, we should not care too much about it).
So let everybody invent their own directory scheme, because FHS is so called outdated so that every Linux distribution and every Unix derivate is totally incompatible with each other? Right, great idea! What about first rewriting the FHS first to make it up-to-date again and only then using this new FHS? Until then the FHS should be fully respected. And why doesn't have "anyone who knows anything about these matters" updated this FHS, yet? Because "anyone who knows anything about these matters agrees that the FHS is outdated and needs to be rewritten"? Come on, if this was really true then the FHS would have already been rewritten by those guys. So this is nonesense. And, btw., I don't see any point in which the FHS doesn't work anymore. But maybe you can explain this, too.
This is a waste of time. The upstream developers are well aware of the FHS. If their apps violate it, it is intentional.
Wrong again, it's not intentional, it's buggy. It was intentional if the FHS would first be rewritten and the upstream developers would then follow the new FHS. Heiko
On Sat, Jan 28, 2012 at 2:14 PM, Heiko Baums <lists@baums-on-web.de> wrote:
Again, PulseAudio which Lennart Poettering likes to have as a standard completely doesn't work with (semi-)professional audio cards with an ice1712 chip. Yes, I had a look at PulseAudio.
Have you tried after this fix was released: <http://git.alsa-project.org/?p=alsa-lib.git;a=commitdiff;h=d3906a93072171e5b5f4000d4a228af4eb8fa253>?
And, yes, there are incompatibilities in systemd. As far as I read there are a lot of initscripts which don't work with systemd and therefore have/had to be rewritten to get them working with systemd.
Where's the bug? In the scripts or in systemd?
Dunno. Depends on the bug. Point me at it and I'll fix it wherever it is.
Then explain it to me. An optical drive is also only mounted temporarily. I don't see a difference between mounting a harddisk temporarily or mounting a dvd temporarily.
The different usecases of /media and /mnt are explained in the FHS link you provided.
So let everybody invent their own directory scheme, because FHS is so called outdated so that every Linux distribution and every Unix derivate is totally incompatible with each other? Right, great idea!
Nope. We are working with the other distros to make things more uniform, not less. In my humble opinion doing this work within the framework of the FHS is not very effective. Coding by committee seldom works.
What about first rewriting the FHS first to make it up-to-date again and only then using this new FHS?
The things that are agreed upon are being added to the next version of FHS, but I guess things are not done in the order you would prefer.
Until then the FHS should be fully respected.
If you say so...
Come on, if this was really true then the FHS would have already been rewritten by those guys. So this is nonesense.
It is: <http://lists.linuxfoundation.org/pipermail/fhs-discuss/2011-May/000001.html>. Note how they hope to be finished by July 1, but conveniently forget to mention what year ;-) But fear not, they have almost agreed on the color of the bikeshed, the rest is expected to follow shortly.
And, btw., I don't see any point in which the FHS doesn't work anymore.
But maybe you can explain this, too.
I'm sure Google will point you at plenty of discussions on this subject.
This is a waste of time. The upstream developers are well aware of the FHS. If their apps violate it, it is intentional.
Wrong again, it's not intentional, it's buggy.
I meant that it is intentional by the software developers, not by the FHS committee. But don't take my word for it, try to file your bugs upstream and see what happens. -t
Am Sat, 28 Jan 2012 15:09:30 +0100 schrieb Tom Gundersen <teg@jklm.no>:
Have you tried after this fix was released: <http://git.alsa-project.org/?p=alsa-lib.git;a=commitdiff;h=d3906a93072171e5b5f4000d4a228af4eb8fa253>?
Like I've written in another e-mail in this thread: And, no, artificially crippling a (semi-)professional audio card down to stereo with a strange ALSA configuration is not a solution for this. And, no, it's not ALSA's fault like Lennart Poettering says, it's PulseAudio's fault. This is what is done by this fix. But those (semi-)professional audio cards with an ice1712 chip aren't SoundBlaster like stereo sound cards for playing some games. They work completely different, because they have several separate channels which can be mixed however you want (of course to normal stereo, too, but not only). Look at the only working mixer for this card, envy24control in alsa-tools (or alsa-tools-ice1712 from AUR), to get a clue. It's sort of a clone of the original mixer and patchbay of the Windows driver for these cards. Or search for documentation of these cards. The problem is, that Lennart Poettering and the other PulseAudio guys don't know anything about these cards. There's also an upstream bug (I don't have the URL to hand), which was indeed closed as fixed with a reference to this commit. Since this is not a fix and not even a workaround I reopened the bug report and never got an update of this bug, yet. So, no, as long as the PulseAudio developers don't know enough about sound and audio and as long as they don't support every sound and audio card in the way those cards are supposed to by the hardware developers and the users, it's just crap, and definitely not a candidate for being a standard. ALSA can handle every sound and audio card including the ice1712 cards perfectly out-of-the-box without such a strange configuration.
Dunno. Depends on the bug. Point me at it and I'll fix it wherever it is.
I'm not using systemd and never will until Arch Linux switches officially to it. But it was already announced that this will most likely not happen. I guess there are good reasons for this decision.
The different usecases of /media and /mnt are explained in the FHS link you provided.
I don't see any difference there. Optical media contain a filesystem and harddisks contain filesystems. Both are usually mounted temporarily. So what's the difference?
Nope. We are working with the other distros to make things more uniform, not less. In my humble opinion doing this work within the framework of the FHS is not very effective. Coding by committee seldom works.
If this is really done this way it's OK. But somehow I still have my doubts. But I'm open to conviction. My impression recently was that there are a lot of people doing and inventing a lot of things on their own which has almost nothing to do with any Linux standards, particularly again Lennart Poettering, and that some other distros just take Lennart's ideas without thinking about it, while other distros don't do this, etc. And you know what I still think of Lennart.
The things that are agreed upon are being added to the next version of FHS, but I guess things are not done in the order you would prefer.
If this will indeed happen, then it's OK for me. Still I have some doubts. Heiko
On Sat, Jan 28, 2012 at 05:29:51PM +0100, Heiko Baums wrote:
And, no, artificially crippling a (semi-)professional audio card down to stereo with a strange ALSA configuration is not a solution for this. And, no, it's not ALSA's fault like Lennart Poettering says, it's PulseAudio's fault.
If you would call it the designer of an average car's fault that you can't transport a grand piano in it. PA is for 'consumer' use, its scope ends at ITU 5.1 or so. It doesn't support any serious multichannel card (like the the comlete RME series, up to 64+64 channels). Users of such cards don't need or want PA, so it's really not a problem at all. If you use such cards you probably have Jack running, and if you really want PA you can configure it as a Jack client. Ciao, -- FA Vor uns liegt ein weites Tal, die Sonne scheint - ein Glitzerstrahl.
Am Sat, 28 Jan 2012 17:05:25 +0000 schrieb Fons Adriaensen <fons@linuxaudio.org>:
PA is for 'consumer' use, its scope ends at ITU 5.1 or so. It doesn't support any serious multichannel card (like the the comlete RME series, up to 64+64 channels). Users of such cards don't need or want PA, so it's really not a problem at all.
That's principally what I said. The problem is that several distros and DEs like Gnome depend on PulseAudio as far as I know. This is what I'm concerned about. Arch Linux and Xfce, what I'm using, fortunately don't depend on it. If PulseAudio was generally only optional and if its developers wouldn't try to declare it as a standard, I just wouldn't care.
If you use such cards you probably have Jack running, and if you really want PA you can configure it as a Jack client.
I'm using an M-Audio Audiophile 24/96, so one of the cheapest semi-professional audio cards of this kind. And I admit I primarily use it for listening to music, watching videos etc. because of its sound quality. But you're right I don't want and need PulseAudio. Heiko
On Sat, Jan 28, 2012 at 06:24:07PM +0100, Heiko Baums wrote:
If PulseAudio was generally only optional and if its developers wouldn't try to declare it as a standard, I just wouldn't care.
It's part of a more general trend, that of dependencies on specific desktop junk trickling down into even basic system components and plain apps. And it's staring to affect Arch as well, be it much less than some others. Ciao, -- FA Vor uns liegt ein weites Tal, die Sonne scheint - ein Glitzerstrahl.
Am Sat, 28 Jan 2012 17:34:32 +0000 schrieb Fons Adriaensen <fons@linuxaudio.org>:
It's part of a more general trend, that of dependencies on specific desktop junk trickling down into even basic system components and plain apps.
And that's a problem. This should be changed again.
And it's staring to affect Arch as well, be it much less than some others.
The Arch devs fortunately try to avoid this trend as good as possible. I hope they can keep it up. And I hope that other distros and upstream developers will rethink soon. Heiko
On Sat, 28 Jan 2012 18:24:07 +0100 Heiko Baums <lists@baums-on-web.de> wrote:
Am Sat, 28 Jan 2012 17:05:25 +0000 schrieb Fons Adriaensen <fons@linuxaudio.org>:
PA is for 'consumer' use, its scope ends at ITU 5.1 or so. It doesn't support any serious multichannel card (like the the comlete RME series, up to 64+64 channels). Users of such cards don't need or want PA, so it's really not a problem at all.
That's principally what I said. The problem is that several distros and DEs like Gnome depend on PulseAudio as far as I know. This is what I'm concerned about. Arch Linux and Xfce, what I'm using, fortunately don't depend on it.
If PulseAudio was generally only optional and if its developers wouldn't try to declare it as a standard, I just wouldn't care.
If you use such cards you probably have Jack running, and if you really want PA you can configure it as a Jack client.
I'm using an M-Audio Audiophile 24/96, so one of the cheapest semi-professional audio cards of this kind. And I admit I primarily use it for listening to music, watching videos etc. because of its sound quality.
But you're right I don't want and need PulseAudio.
Heiko
Please please please not again!!! PA is a great consumer thing, and that's exactly what we need. Because noone cares about "pro" audio solutions which are a nightmare to configure. PA goes far beyond you KDE/gnome to embedded systems with android and webos. Having different volume controls for different ergimes is very handy there. -- Leonid Isaev GnuPG key ID: 164B5A6D Key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
On Sat, 2012-01-28 at 13:14 -0600, Leonid Isaev wrote:
Please please please not again!!!
PA is a great consumer thing, and that's exactly what we need. Because noone cares about "pro" audio solutions which are a nightmare to configure.
PA goes far beyond you KDE/gnome to embedded systems with android and webos. Having different volume controls for different ergimes is very handy there.
The discussion would stop once and for all, if there would simply be a dummy package available by the repositories of all the distros who make PA a dependency. Neither the OP nor I have started this discussion on several other lists, where it was a thread some days ago. All the time there are averaged non-pro-audio users having trouble with PA. And now I shut up, Ralf
On Sat, Jan 28, 2012 at 8:29 PM, Ralf Mardorf <ralf.mardorf@alice-dsl.net>wrote:
Please please please not again!!!
PA is a great consumer thing, and that's exactly what we need. Because noone cares about "pro" audio solutions which are a nightmare to configure.
PA goes far beyond you KDE/gnome to embedded systems with android and webos. Having different volume controls for different ergimes is very handy
On Sat, 2012-01-28 at 13:14 -0600, Leonid Isaev wrote: there.
The discussion would stop once and for all, if there would simply be a dummy package available by the repositories of all the distros who make PA a dependency.
If it's an upstream dependency , then a package depends on it. If you don't like PA. Then either stop using it or improve it, just don't spread this silly FUD and complains. Man up and take it to upstream.
Neither the OP nor I have started this discussion on several other lists, where it was a thread some days ago. All the time there are averaged non-pro-audio users having trouble with PA.
As always "Patches welcome!"
And now I shut up, Ralf
-- Jelle van der Waa
Thanks. On Sat, Jan 28, 2012 at 11:29 AM, Ralf Mardorf <ralf.mardorf@alice-dsl.net>wrote:
Please please please not again!!!
PA is a great consumer thing, and that's exactly what we need. Because noone cares about "pro" audio solutions which are a nightmare to configure.
PA goes far beyond you KDE/gnome to embedded systems with android and webos. Having different volume controls for different ergimes is very handy
On Sat, 2012-01-28 at 13:14 -0600, Leonid Isaev wrote: there.
The discussion would stop once and for all, if there would simply be a dummy package available by the repositories of all the distros who make PA a dependency.
Neither the OP nor I have started this discussion on several other lists, where it was a thread some days ago. All the time there are averaged non-pro-audio users having trouble with PA.
And now I shut up, Ralf
On Sat, 28 Jan 2012 20:29:28 +0100 Ralf Mardorf <ralf.mardorf@alice-dsl.net> wrote:
On Sat, 2012-01-28 at 13:14 -0600, Leonid Isaev wrote:
Please please please not again!!!
PA is a great consumer thing, and that's exactly what we need. Because noone cares about "pro" audio solutions which are a nightmare to configure.
PA goes far beyond you KDE/gnome to embedded systems with android and webos. Having different volume controls for different ergimes is very handy there.
The discussion would stop once and for all, if there would simply be a dummy package available by the repositories of all the distros who make PA a dependency.
This idea is plain ridiculous. Please stop embarassing yourself like this.
Neither the OP nor I have started this discussion on several other lists, where it was a thread some days ago. All the time there are averaged non-pro-audio users having trouble with PA.
And now I shut up, Ralf
-- Leonid Isaev GnuPG key ID: 164B5A6D Key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
Am Sat, 28 Jan 2012 13:14:47 -0600 schrieb Leonid Isaev <lisaev@umail.iu.edu>:
PA is a great consumer thing, and that's exactly what we need.
That may be exactly what you need, but not what we need. Otherwise we all could stick with Windows. You can read your e-mails and write some letters with Windows. So why using Linux?
Because noone cares about "pro" audio solutions which are a nightmare to configure.
I don't need to configure anything to get my M-Audio Audiophile 24/96 to get running perfectly with ALSA. And all the pro audio software work without any configuration out-of-the-box with this card and ALSA. What's not working with this card is PulseAudio, and to get it working with PulseAudio somehow I need to cripple it down to stereo with a nightmare of configuration. Heiko
On Sat, Jan 28, 2012 at 01:14:47PM -0600, Leonid Isaev wrote:
PA is a great consumer thing, and that's exactly what we need.
PA is indeed a great consumer thing, and it may be what you need. It is definitely not what some others need.
Because noone cares about "pro" audio solutions
You mean _you_ don't.
which are a nightmare to configure.
Very strange that you claim to have some knowledge on something you don't care about. Which 'pro' audio HW have you actually used ? On what experience is is your 'nightmare to configure' comment based ? Having used a significant percentage of what is available, and earning my daily pizza by providing services and consultancy mostly based on Linux audio using 'pro' HW, I can only say that your comment is pure nonsense. Ciao, -- FA Vor uns liegt ein weites Tal, die Sonne scheint - ein Glitzerstrahl.
On Sat, 2012-01-28 at 20:25 +0000, Fons Adriaensen wrote:
On Sat, Jan 28, 2012 at 01:14:47PM -0600, Leonid Isaev wrote:
PA is a great consumer thing, and that's exactly what we need.
PA is indeed a great consumer thing, and it may be what you need. It is definitely not what some others need.
Because noone cares about "pro" audio solutions
You mean _you_ don't.
which are a nightmare to configure.
Very strange that you claim to have some knowledge on something you don't care about. Which 'pro' audio HW have you actually used ? On what experience is is your 'nightmare to configure' comment based ?
Having used a significant percentage of what is available, and earning my daily pizza by providing services and consultancy mostly based on Linux audio using 'pro' HW, I can only say that your comment is pure nonsense.
I need to chime in here. (Hard to shut up) After some conversation off list I agree that a dummy package provided by the repositories might be a less good idea. But I noticed some lacks of knowhow. E.g. it's not a problem for a classic Jack only. Cards as the Envy24 ones (the OP already tried to explain this) or the RME (Fons already mentioned it) already don't work with PA. So if even software like GDM depends to PA (it might be a dependency of a dependency), it's ridiculous. Of cause, it's possible to use another login manager, but someday too many apps might depend on PA, that don't need PA. The different "solutions" to turn off PA often don't work. "autospawn = no" might work for Arch Linux, but AFAIK some distros still kept disadvantages of PA when using this. Cheers, Ralf
On Sat, Jan 28, 2012 at 6:05 PM, Fons Adriaensen <fons@linuxaudio.org> wrote:
If you use such cards you probably have Jack running, and if you really want PA you can configure it as a Jack client.
For what it's worth, PA and Jack have a protocol to peacefully coexist. So, if you use Jack, even if PA is installed and running, PA will move out of the way and everything should "just work". -t
On Sat, 2012-01-28 at 18:30 +0100, Tom Gundersen wrote:
On Sat, Jan 28, 2012 at 6:05 PM, Fons Adriaensen <fons@linuxaudio.org> wrote:
If you use such cards you probably have Jack running, and if you really want PA you can configure it as a Jack client.
For what it's worth, PA and Jack have a protocol to peacefully coexist. So, if you use Jack, even if PA is installed and running, PA will move out of the way and everything should "just work".
-t
Sorry, I can't be quiet, because this isn't true. Audio in for my RME HDSPe AIO worked, but audio out didn't work. I had to replace PA by a dummy package for my Arch Linux install. Even after pulseaudio --kill nothing changed. Btw. sometimes I'm using my RME card without Jack, but ALSA only. Why should I use Jack to listen to YouTube? - Ralf
On Sat, Jan 28, 2012 at 7:59 PM, Ralf Mardorf <ralf.mardorf@alice-dsl.net> wrote:
On Sat, 2012-01-28 at 18:30 +0100, Tom Gundersen wrote:
For what it's worth, PA and Jack have a protocol to peacefully coexist. So, if you use Jack, even if PA is installed and running, PA will move out of the way and everything should "just work".
Sorry, I can't be quiet, because this isn't true.
It should be possible, though I don't use Jack, so this is all I know: <http://trac.jackaudio.org/wiki/JackDbusPackaging> -t
On Jan 29, 2012 3:29 AM, "Tom Gundersen" <teg@jklm.no> wrote:
On Sat, Jan 28, 2012 at 7:59 PM, Ralf Mardorf <ralf.mardorf@alice-dsl.net> wrote:
On Sat, 2012-01-28 at 18:30 +0100, Tom Gundersen wrote:
For what it's worth, PA and Jack have a protocol to peacefully coexist. So, if you use Jack, even if PA is installed and running, PA will move out of the way and everything should "just work".
Sorry, I can't be quiet, because this isn't true.
It should be possible, though I don't use Jack, so this is all I know:
<http://trac.jackaudio.org/wiki/JackDbusPackaging>
-t
It is true, using jack 2 and pulse. Lots of hear say and too little actual knowledge in these sort of threads... "Alsa works perfectly for me, pulse doesn't, it sucks and its maintainer has a secret agenda against all Linux pros...."
On Sun, 2012-01-29 at 07:22 +0800, Oon-Ee Ng wrote:
On Jan 29, 2012 3:29 AM, "Tom Gundersen" <teg@jklm.no> wrote:
On Sat, Jan 28, 2012 at 7:59 PM, Ralf Mardorf <ralf.mardorf@alice-dsl.net> wrote:
On Sat, 2012-01-28 at 18:30 +0100, Tom Gundersen wrote:
For what it's worth, PA and Jack have a protocol to peacefully coexist. So, if you use Jack, even if PA is installed and running, PA will move out of the way and everything should "just work".
Sorry, I can't be quiet, because this isn't true.
It should be possible, though I don't use Jack, so this is all I know:
<http://trac.jackaudio.org/wiki/JackDbusPackaging>
-t
It is true, using jack 2 and pulse. Lots of hear say and too little actual knowledge in these sort of threads... "Alsa works perfectly for me, pulse doesn't, it sucks and its maintainer has a secret agenda against all Linux pros...."
Are you a professional audio engineer using Linux audio? You're using Jack DBus? For what kind of productions? What setup do you use? Even if Jack DBus should be ok for my needs, it's uneconomic to switch back from familiar setup. A lot of people need to switch from GNOME to Xfce, not because of PA, since PA easily can be replaced by a dummy package, but because of other bad changes. You can't do such hard changes of the work flow in a professional environment from one day to the other, when several people are involved. FWIW I'm jobless at the moment, but my life career is audio and video engineer for around 30 years, from small studios to world famous companies. I might have less knowledge about Linux, but I know about professional audio work flow. Comments like you makes a majority of engineers use Apple and Windows for pro-audio, while Linux would be the better choice, if there wouldn't be such issues and comments like yours. Regards, Ralf
On Sun, 2012-01-29 at 10:46 +0100, Ralf Mardorf wrote:
On Sun, 2012-01-29 at 07:22 +0800, Oon-Ee Ng wrote:
On Jan 29, 2012 3:29 AM, "Tom Gundersen" <teg@jklm.no> wrote:
On Sat, Jan 28, 2012 at 7:59 PM, Ralf Mardorf <ralf.mardorf@alice-dsl.net> wrote:
On Sat, 2012-01-28 at 18:30 +0100, Tom Gundersen wrote:
For what it's worth, PA and Jack have a protocol to peacefully coexist. So, if you use Jack, even if PA is installed and running, PA will move out of the way and everything should "just work".
Sorry, I can't be quiet, because this isn't true.
It should be possible, though I don't use Jack, so this is all I know:
<http://trac.jackaudio.org/wiki/JackDbusPackaging>
-t
It is true, using jack 2 and pulse. Lots of hear say and too little actual knowledge in these sort of threads... "Alsa works perfectly for me, pulse doesn't, it sucks and its maintainer has a secret agenda against all Linux pros...."
Are you a professional audio engineer using Linux audio? You're using Jack DBus? For what kind of productions? What setup do you use?
Even if Jack DBus should be ok for my needs, it's uneconomic to switch back from familiar setup. ^^^^ away (English isn't my native language ;)
A lot of people need to switch from GNOME to Xfce, not because of PA, since PA easily can be replaced by a dummy package, but because of other bad changes. You can't do such hard changes of the work flow in a professional environment from one day to the other, when several people are involved.
FWIW I'm jobless at the moment, but my life career is audio and video engineer for around 30 years, from small studios to world famous companies. I might have less knowledge about Linux, but I know about professional audio work flow.
Comments like you makes a majority of engineers use Apple and Windows for pro-audio, while Linux would be the better choice, if there wouldn't be such issues and comments like yours.
Regards,
Ralf
On Jan 29, 2012 5:46 PM, "Ralf Mardorf" <ralf.mardorf@alice-dsl.net> wrote:
On Sun, 2012-01-29 at 07:22 +0800, Oon-Ee Ng wrote:
On Jan 29, 2012 3:29 AM, "Tom Gundersen" <teg@jklm.no> wrote:
On Sat, Jan 28, 2012 at 7:59 PM, Ralf Mardorf <ralf.mardorf@alice-dsl.net> wrote:
On Sat, 2012-01-28 at 18:30 +0100, Tom Gundersen wrote:
For what it's worth, PA and Jack have a protocol to peacefully coexist. So, if you use Jack, even if PA is installed and
will move out of the way and everything should "just work".
Sorry, I can't be quiet, because this isn't true.
It should be possible, though I don't use Jack, so this is all I know:
<http://trac.jackaudio.org/wiki/JackDbusPackaging>
-t It is true, using jack 2 and pulse. Lots of hear say and too little actual knowledge in these sort of threads... "Alsa works perfectly for me,
running, PA pulse
doesn't, it sucks and its maintainer has a secret agenda against all Linux pros...."
Are you a professional audio engineer using Linux audio? You're using Jack DBus? For what kind of productions? What setup do you use?
Even if Jack DBus should be ok for my needs, it's uneconomic to switch back from familiar setup.
No I am not, if I was I'd be ashamed to be criticizing a project without first getting my facts right.
A lot of people need to switch from GNOME to Xfce, not because of PA, since PA easily can be replaced by a dummy package, but because of other bad changes. You can't do such hard changes of the work flow in a professional environment from one day to the other, when several people are involved.
FWIW I'm jobless at the moment, but my life career is audio and video engineer for around 30 years, from small studios to world famous companies. I might have less knowledge about Linux, but I know about professional audio work flow.
Yes, why not generalize when a specific example is debunked? I'm sure all Linux installs MUST be ready to use out of the box for professional audio users. after all, the same is true for the other operating systems.
Comments like you makes a majority of engineers use Apple and Windows for pro-audio, while Linux would be the better choice, if there wouldn't be such issues and comments like yours.
No one here has claimed Linux to be the better choice (opinion) because systems are tools, not ideologies. Linux comes with disadvantages and advantages, in the case of audio you have choice (just like you can replace coreaudio on Macs, right), which comes at the cost of having to actually maintain your system and not expecting it to always work the same way. Just use windows and Apple already, Linux's pro audio is Jack, it is NOT ootb friendly (that's why is "pro"), and pulse does not change that. You're just looking for something to rant about related to Lennart, I think.
Regards,
Ralf
On Sun, 2012-01-29 at 18:13 +0800, Oon-Ee Ng wrote:
On Jan 29, 2012 5:46 PM, "Ralf Mardorf" <ralf.mardorf@alice-dsl.net> wrote:
On Sun, 2012-01-29 at 07:22 +0800, Oon-Ee Ng wrote:
On Jan 29, 2012 3:29 AM, "Tom Gundersen" <teg@jklm.no> wrote:
On Sat, Jan 28, 2012 at 7:59 PM, Ralf Mardorf <ralf.mardorf@alice-dsl.net> wrote:
On Sat, 2012-01-28 at 18:30 +0100, Tom Gundersen wrote:
For what it's worth, PA and Jack have a protocol to peacefully coexist. So, if you use Jack, even if PA is installed and
will move out of the way and everything should "just work".
Sorry, I can't be quiet, because this isn't true.
It should be possible, though I don't use Jack, so this is all I know:
<http://trac.jackaudio.org/wiki/JackDbusPackaging>
-t It is true, using jack 2 and pulse. Lots of hear say and too little actual knowledge in these sort of threads... "Alsa works perfectly for me,
running, PA pulse
doesn't, it sucks and its maintainer has a secret agenda against all Linux pros...."
Are you a professional audio engineer using Linux audio? You're using Jack DBus? For what kind of productions? What setup do you use?
Even if Jack DBus should be ok for my needs, it's uneconomic to switch back from familiar setup.
No I am not, if I was I'd be ashamed to be criticizing a project without first getting my facts right.
A lot of people need to switch from GNOME to Xfce, not because of PA, since PA easily can be replaced by a dummy package, but because of other bad changes. You can't do such hard changes of the work flow in a professional environment from one day to the other, when several people are involved.
FWIW I'm jobless at the moment, but my life career is audio and video engineer for around 30 years, from small studios to world famous companies. I might have less knowledge about Linux, but I know about professional audio work flow.
Yes, why not generalize when a specific example is debunked? I'm sure all Linux installs MUST be ready to use out of the box for professional audio users. after all, the same is true for the other operating systems.
Comments like you makes a majority of engineers use Apple and Windows for pro-audio, while Linux would be the better choice, if there wouldn't be such issues and comments like yours.
No one here has claimed Linux to be the better choice (opinion) because systems are tools, not ideologies. Linux comes with disadvantages and advantages, in the case of audio you have choice (just like you can replace coreaudio on Macs, right), which comes at the cost of having to actually maintain your system and not expecting it to always work the same way.
Just use windows and Apple already, Linux's pro audio is Jack, it is NOT ootb friendly (that's why is "pro"), and pulse does not change that. You're just looking for something to rant about related to Lennart, I think.
Regards,
Ralf
I never said anything against Lennart. I don't know him, I even didn't know that he has to do with PA, before Heiko or who ever it was has written about him. Why this assumption? Again, I never rant against Lennart! Quote any rant I have done! I claim that Linux is the best choice to go for pro-audio. Where didn't I get the facts right? Again: Do you know about problems when using Jack DBus? Have you ever used it? You might search the LAD and LAU archives before you claim, that I don't get the facts right. Regards, Ralf
On Sun, 2012-01-29 at 18:13 +0800, Oon-Ee Ng wrote:
Yes, why not generalize when a specific example is debunked?
About what kind of generalization are you talking? I'm serious, I don't understand what you are talking about.
I'm sure all Linux installs MUST be ready to use out of the box for professional audio users. after all, the same is true for the other operating systems.
I just ask that upgrades don't break a working machine, caused by unneeded dependencies. If a studio used GNOME, than an upgrade shouldn't add PA and break the machine. Only add dependencies if they are needed. PA isn't needed, it's optional. If upstream add it, it might be allowed to explain, why it isn't good to do so. I don't ask for a Linux that works OOTB. My arguments where about PA that doesn't work with professional RME cards, since I'm using a RME card. Without Jack and with PA such a card doesn't work. FWIW it's the same with Envy24 cards, the most used audio cards, when using software like Ardour, Qtractor etc., since RME cards are very expensive. A classic Jack also doesn't work when PA is installed and there are reasons to use a classic Jack. Why do you think it's packaged? Your assumptions are strange. Why are you doing this? Could you please become objective? Regards, Ralf
On Sun, Jan 29, 2012 at 11:50 AM, Ralf Mardorf <ralf.mardorf@alice-dsl.net> wrote:
I'm sure all Linux installs MUST be ready to use out of the box for professional audio users. after all, the same is true for the other operating systems.
I just ask that upgrades don't break a working machine, caused by unneeded dependencies. If a studio used GNOME, than an upgrade shouldn't add PA and break the machine. Only add dependencies if they are needed. PA isn't needed, it's optional. If upstream add it, it might be allowed to explain, why it isn't good to do so.
Sounds like possibly valid concerns. But this is not something to discuss here. Please contact gnome and/or pulseaudio if you have issues. We just package their software, we don't decide their priorities or policies. And I think this discussion has gone on for way too long... -t
Am Sun, 29 Jan 2012 11:58:31 +0100 schrieb Tom Gundersen <teg@jklm.no>:
Sounds like possibly valid concerns. But this is not something to discuss here. Please contact gnome and/or pulseaudio if you have issues.
This has already been tried at least with pulseaudio. Their reactions are known. Blame ALSA for PA's faults while ALSA supports those card perfectly since years, and crippling those audio cards down to stereo with some very strange ALSA configs, because PA's upstream just doesn't have the knowledge about those cards and about pro-audio. Maybe I'm not the best to explain the concepts of those audio cards, but that doesn't mean that I don't know anything about them. When I bought this card it took me a while until I got to know what they are doing and how they work, so maybe I can't explain it in detail. But that doesn't mean that I'm missing anything.
We just package their software, we don't decide their priorities or policies.
But you and the developers of the other distributions are the people who decide if they just want to package what upstream thinks should become a standard. So if every distribution just install PA as a dependency then nothing will change and a very big regression regarding audio will happen, because PA will indeed become a standard, and no pro-audio user will be able to hear and work with sound anymore. If the distros refuse to package those bad software dependencies, then also upstream probably has to change their minds. So I think this has to be discussed with downstream, too.
And I think this discussion has gone on for way too long...
Think about it again. Think again why this discussion about PA always pops up on every occasion in almost every mailing list and forum. Rethink if pro-audio users really have no knowledge about the underlying concepts. I bet pro-audio users have a lot more knowledge than PA upstream and all the people who claim that pro-audio users are missing something. I'm sure that this discussion will always pop up until these issues regarding PA are fixed. That said, it will end if either PA will fully support those audio cards and show that they learned about (pro-)audio or if PA wouldn't be installed as a dependency anymore by upstream as well as by downstream of all distros and just be treated as a normal and optional piece of software which can but doesn't need to be installed and used. Heiko
On Sun, Jan 29, 2012 at 02:46:37PM +0100, Heiko Baums wrote:
This has already been tried at least with pulseaudio. Their reactions are known. Blame ALSA for PA's faults while ALSA supports those card perfectly since years, and crippling those audio cards down to stereo with some very strange ALSA configs, because PA's upstream just doesn't have the knowledge about those cards and about pro-audio.
They *DO* know and understand the difference between consumer and 'pro' audio. PA just isn't meant for the latter. I wonder what your problem is. There is no audio production software I know of that uses or depends on PA. It's going to stay that way. So _it doesn't matter_ if PA doesn't support your soundcard. I'd even say it's a good thing that PA stays away from anything 'pro'. Ciao, -- FA Vor uns liegt ein weites Tal, die Sonne scheint - ein Glitzerstrahl.
Fons Adriaensen [2012.01.29 1442 +0000]:
On Sun, Jan 29, 2012 at 02:46:37PM +0100, Heiko Baums wrote:
This has already been tried at least with pulseaudio. Their reactions are known. Blame ALSA for PA's faults while ALSA supports those card perfectly since years, and crippling those audio cards down to stereo with some very strange ALSA configs, because PA's upstream just doesn't have the knowledge about those cards and about pro-audio.
They *DO* know and understand the difference between consumer and 'pro' audio. PA just isn't meant for the latter.
I wonder what your problem is. There is no audio production software I know of that uses or depends on PA. It's going to stay that way. So _it doesn't matter_ if PA doesn't support your soundcard. I'd even say it's a good thing that PA stays away from anything 'pro'.
I just posted a comment in this thread, observing that the problem is not pro-audio vs non-pro-audio hardware. The difference is between hardware that works and hardware that doesn't work, and the latter most certainly includes distinctly non-pro hardware that works great with ALSA but not with PA. Cheers, Norbert
On Sun, 2012-01-29 at 11:06 -0400, Norbert Zeh wrote:
Fons Adriaensen [2012.01.29 1442 +0000]:
On Sun, Jan 29, 2012 at 02:46:37PM +0100, Heiko Baums wrote:
This has already been tried at least with pulseaudio. Their reactions are known. Blame ALSA for PA's faults while ALSA supports those card perfectly since years, and crippling those audio cards down to stereo with some very strange ALSA configs, because PA's upstream just doesn't have the knowledge about those cards and about pro-audio.
They *DO* know and understand the difference between consumer and 'pro' audio. PA just isn't meant for the latter.
I wonder what your problem is. There is no audio production software I know of that uses or depends on PA. It's going to stay that way. So _it doesn't matter_ if PA doesn't support your soundcard. I'd even say it's a good thing that PA stays away from anything 'pro'.
I just posted a comment in this thread, observing that the problem is not pro-audio vs non-pro-audio hardware. The difference is between hardware that works and hardware that doesn't work, and the latter most certainly includes distinctly non-pro hardware that works great with ALSA but not with PA.
Cheers, Norbert
At least one user pointed out that he's using an Envy24 card, but he isn't using audio production software. He only use such a sound card to get better sound quality, than consumer crap will produce. Btw. a wise decision, a Hifi CD player is more expensive, than an Envy24 sound card, that at Ebay are available at around 30,-€. The other point is, that more and more depends to PA, even if it's unneeded. Comparable to Emacs depending to ConsoleKit. When will stop those dependency issues? Will Firefox become a dependency for leafpad next week? At the beginning of this discussion I pointed out, that most averaged desktop audio users on mailing lists are comfortable with PA, as long as they don't get issues, but once they run into PA related troubles, then they need some good advice. Cheers, Ralf -- Really hard to shut up :(.
Am Sun, 29 Jan 2012 14:42:33 +0000 schrieb Fons Adriaensen <fons@linuxaudio.org>:
They *DO* know and understand the difference between consumer and 'pro' audio.
I have another impression.
I wonder what your problem is. There is no audio production software I know of that uses or depends on PA. It's going to stay that way. So _it doesn't matter_ if PA doesn't support your soundcard. I'd even say it's a good thing that PA stays away from anything 'pro'.
I didn't say anything about pro-audio software, I've spoken about DEs like Gnome 3 and some distros which want to have PA installed as a dependency and probably don't work anymore without PA. If this is or at least will be the case then also the pro-audio software won't work anymore with those. Heiko
On Sun, Jan 29, 2012 at 10:02:25PM +0100, Heiko Baums wrote:
Am Sun, 29 Jan 2012 14:42:33 +0000 schrieb Fons Adriaensen <fons@linuxaudio.org>:
They *DO* know and understand the difference between consumer and 'pro' audio.
I have another impression.
Could be. My impression is based on talking with LP face to face. And yours ?
I wonder what your problem is. There is no audio production software I know of that uses or depends on PA. It's going to stay that way. So _it doesn't matter_ if PA doesn't support your soundcard. I'd even say it's a good thing that PA stays away from anything 'pro'.
I didn't say anything about pro-audio software, I've spoken about DEs like Gnome 3 and some distros which want to have PA installed as a dependency and probably don't work anymore without PA. If this is or at least will be the case then also the pro-audio software won't work anymore with those.
I fully agree that designing Gnome or KDE so they can't be installed easily without PA by a user who accepts the consequences of doing so (no desktop sounds) is a sign of *very crappy* engineering. OTOH, if you use one of those desktops you can just suspend PA, start Jack and your apps and go on. I don't use Gnome or KDE, I don't have PA installed so I can't talk from experience. But I know that people are doing this all the time. For example Joern Nettingsmeier, who is probably using the most complex and advanced pro audio setups ever done in Linux, apparently has no problem with this. Ciao, -- FA Vor uns liegt ein weites Tal, die Sonne scheint - ein Glitzerstrahl.
Am Sun, 29 Jan 2012 21:55:28 +0000 schrieb Fons Adriaensen <fons@linuxaudio.org>:
Could be. My impression is based on talking with LP face to face. And yours ?
My is based on a bug report, upstream's solution for closing this bug report - this weird ALSA configuration which cripples those cards to pure stereo cards - and their response to the reopening of this bug report.
I fully agree that designing Gnome or KDE so they can't be installed easily without PA by a user who accepts the consequences of doing so (no desktop sounds) is a sign of *very crappy* engineering.
OTOH, if you use one of those desktops you can just suspend PA, start Jack and your apps and go on. I don't use Gnome or KDE, I don't have PA installed so I can't talk from experience. But I know that people are doing this all the time. For example Joern Nettingsmeier, who is probably using the most complex and advanced pro audio setups ever done in Linux, apparently has no problem with this.
OK, looks like there is a working workaround, but not a real solution. The solution would be a better engineering. Heiko
On Sun, Jan 29, 2012 at 11:17:38PM +0100, Heiko Baums wrote:
My is based on a bug report, upstream's solution for closing this bug report - this weird ALSA configuration which cripples those cards to pure stereo cards - and their response to the reopening of this bug report.
The ALSA 'route' device doesn't cripple the card, it just reduces it to what PA is able to use. Even if PA would accept the card with its full channel count there are no PA enabled apps that could all those channels, and that's probably a good thing. Just imagine PA venturing into 'pro audio' territory - that would be a real disaster. -- FA Vor uns liegt ein weites Tal, die Sonne scheint - ein Glitzerstrahl.
On Sun, Jan 29, 2012 at 10:02 PM, Heiko Baums <lists@baums-on-web.de> wrote:
I didn't say anything about pro-audio software, I've spoken about DEs like Gnome 3 and some distros which want to have PA installed as a dependency and probably don't work anymore without PA. If this is or at least will be the case then also the pro-audio software won't work anymore with those.
You seem to possess the misconception that the existence of PA on a system is somehow in conflict with pro-audio software.
On Sun, Jan 29, 2012 at 4:12 PM, Jan Steffens <jan.steffens@gmail.com> wrote:
You seem to possess the misconception that the existence of PA on a system is somehow in conflict with pro-audio software.
It's true that professional users typically make some compromises to have the best system for audio. But.. not using PulseAudio isn't really a compromise, one is not losing anything. There are other kind of examples. Professional musicians are not interested in battery file but in a system with realtime preemption tuned for performance. There is no joy in a long battery life with lots noises coming out of the speakers... Not for most of them at least. PulseAudio is even worse. It does not work at all for professional sound cards and professional audio software. What's the point to have it, since it's a complex and buggy system and you can have exactly the same features using alsa, jack and alsa-plugins? Professional audio system with low latency requires other set of priorities. Arch is filling this need as far as I see. One can set such a system very easily. But some care is wise to keep things simple, including not enforcing the use of useless heavy tools.
^^^battery life
Heiko Baums [2012.01.29 1446 +0100]:
Am Sun, 29 Jan 2012 11:58:31 +0100 schrieb Tom Gundersen <teg@jklm.no>:
Sounds like possibly valid concerns. But this is not something to discuss here. Please contact gnome and/or pulseaudio if you have issues.
This has already been tried at least with pulseaudio. Their reactions are known. Blame ALSA for PA's faults while ALSA supports those card perfectly since years, and crippling those audio cards down to stereo with some very strange ALSA configs, because PA's upstream just doesn't have the knowledge about those cards and about pro-audio.
Maybe I'm not the best to explain the concepts of those audio cards, but that doesn't mean that I don't know anything about them. When I bought this card it took me a while until I got to know what they are doing and how they work, so maybe I can't explain it in detail. But that doesn't mean that I'm missing anything.
We just package their software, we don't decide their priorities or policies.
But you and the developers of the other distributions are the people who decide if they just want to package what upstream thinks should become a standard. So if every distribution just install PA as a dependency then nothing will change and a very big regression regarding audio will happen, because PA will indeed become a standard, and no pro-audio user will be able to hear and work with sound anymore. If the distros refuse to package those bad software dependencies, then also upstream probably has to change their minds.
So I think this has to be discussed with downstream, too.
And I think this discussion has gone on for way too long...
Think about it again. Think again why this discussion about PA always pops up on every occasion in almost every mailing list and forum. Rethink if pro-audio users really have no knowledge about the underlying concepts. I bet pro-audio users have a lot more knowledge than PA upstream and all the people who claim that pro-audio users are missing something.
I'm sure that this discussion will always pop up until these issues regarding PA are fixed. That said, it will end if either PA will fully support those audio cards and show that they learned about (pro-)audio or if PA wouldn't be installed as a dependency anymore by upstream as well as by downstream of all distros and just be treated as a normal and optional piece of software which can but doesn't need to be installed and used.
Let me chime in here to add an important point to this discussion. The whole discussion so far sounds as if PA works great with non-pro cards and breaks only on pro cards. That's not the case: PA has problems even with what is probably the lowest end of chips: built-in audio chips on all my motherboards. And the behaviour I observed is exactly what Heiko and Ralf observed too: everything works great with ALSA and starts to act up when using PA. Things I observed (on Ubuntu, Mint, openSUSE, Arch...so it's not distro-specific) were way too low input (mic) and output volumes even when setting the volume controls to 100%. I really wanted to use PA because it offers something ALSA does not: simultaneous audio streams from different applications (i.e., when firing up Windows in a VirtualBox, it does not hog my audio). So I googled for hours, read through forum posts, etc. and all I could find were hacks that either didn't work at all or resulted in the right volume but at completely unacceptable distortion levels. So, I'm almost certain that I am doing something wrong with configuring my audio setup using PA, but the whole point of PA as I understand it is to make using audio easier, at least for completely standard desktop audio use, which is what I want. So, either it should work out of the box or, similar to the arch way, there should be clear documentation on how to configure things right. The former is not the case on my hardware, and hours of googling did not lead me to the latter. So, to me it feels like this "standard" is moving us way too close to Windows land for my taste: if you know the magic incantation, then all will just work, but you have to be a member of our guild to be taught the incantation. As many others, I am happily running without PA and will probably be able to continue to do so for a long time because I don't even use Gnome or KDE. I just felt the need to add to the discussion because some people in this thread defend PA as the golden bullet for desktop audio use, which it absolutely isn't in my experience. If this was a result of using hardware that simply isn't supported well by linux drivers, then that would be my fault, but, as already said, plain ALSA works simply great. Throw PA into the mix, and things start to go wonky. Cheers, Norbert
On 29-01-2012 15:03, Norbert Zeh wrote:
As many others, I am happily running without PA and will probably be able to continue to do so for a long time because I don't even use Gnome or KDE. I just felt the need to add to the discussion because some people in this thread defend PA as the golden bullet for desktop audio use, which it absolutely isn't in my experience. If this was a result of using hardware that simply isn't supported well by linux drivers, then that would be my fault, but, as already said, plain ALSA works simply great. Throw PA into the mix, and things start to go wonky.
Currently I am also a happy pa user and I haven't experienced any of the most common problems that affected pa users, but before I had to use ossv4 because plain alsa would output crappy sound until some major driver rework landed on the kernel. I've seen a small part of both worlds and I know how frustrating it is when things don't work when and how they should, but as with most things, usually the blame isn't on one side only. I know that alsa devs and pa dev(s) already did their fair share of blame throwing, it might be a case of pa missing some important features/support or doing something that doesn't make sense but I wouldn't discard the possibility of bugs in drivers for less common cards or many workarounds/fixes still missing in drivers for really cheap and sometimes broken cards/chips/hardware implementations. Take as an example the recent problem with KDE (I think it was KDE) and open source graphics drivers. Drivers advertised support for some modernish opengl features, KDE tried to used them, but as they were never really widely used and tested there were lots of problems and in some cases the advertised support wasn't even implemented in the drivers, the only thing that was missing was software to expose the problems. Any problems and feature requests should be reported upstream, at least let the blame "brainstorming" happen at a level where it might do some good, even if the respective devs don't want to acknowledge the problems they might silently fix things or make them work better :p -- Mauro Santos
On Sun, Jan 29, 2012 at 11:03:13AM -0400, Norbert Zeh wrote:
Things I observed (on Ubuntu, Mint, openSUSE, Arch...so it's not distro-specific) were way too low input (mic) and output volumes even when setting the volume controls to 100%. I really wanted to use PA because it offers something ALSA does not: simultaneous audio streams from different applications (i.e., when firing up Windows in a VirtualBox, it does not hog my audio). So I googled for hours, read through forum posts, etc. and all I could find were hacks that either didn't work at all or resulted in the right volume but at completely unacceptable distortion levels.
hey funny you mention it, when I came from ubuntu I configured alsa/dmix on arch and for the first time since I was using linux I heard sound from multiple applications at once... we could just settle that the depth of support varies between the two. Also, duplicate efforts are a common linux problem, and maybe some people would like to see pa devs on alsa/dmix. Saying such a thing is ridiculous though, since one will not be able to change things. I use xdm which doesn't depend on mesa/opengl stuff yet, nor pa, and it's actually possible to get most features that come with gdm, eg. session chooser, working with xdm. Whenever I want to get comfortable, I also try to get in touch with upstream when I think about adding features or have patches already, and I'm pretty much addicted to the additional effort linux is asking from me. I hope I won't stop learning new stuff soon, I might just go and buy such a pro audio card for teh arghs to patch the hell out of pa. Okay, I'm not *that* bored... :) cheers! mar77i
On Sun, 2012-01-29 at 16:57 +0100, Martti Kühne wrote:
it's actually possible to get most features that come with gdm, eg. session chooser, working with xdm.
This was the same for GDM. What would you do if the next upgrade will make XDM depend to PA? Of cause, you'll simply install another login manager. But what will you do if really important applications get such an unneeded dependency and it will break your work flow completely? That's the point. Again and again and again, it's no problem as long as it is for PA only and you've the knowledge to build a dummy package. Fortunately some packaging things for Arch are completely different to some old major distros. So, in this case it seems to be an issue cause upstream, but the more people understand what's the problem is, the better WE can inform upstream. Reading the last mails, there are a lot of misunderstandings, e.g. simply use jackdbus etc.. Btw. for other distros software sometimes is picked to pieces, e.g. libjack and jackd and all the times there were issues related to this. Regarding to this Jack isn't issue for any distro I know today, but dependency hell still is an issue, even for Arch. On Sun, 2012-01-29 at 15:52 +0000, Mauro Santos wrote: I know that alsa devs and pa dev(s) already did their fair share of
blame throwing, it might be a case of pa missing some important features/support or doing something that doesn't make sense but I wouldn't discard the possibility of bugs in drivers for less common cards
What are "less common" audio cards? Envy24 is a very common microchip used by tons of audio cards, not only for audio production. RME are the only good supported, professional cards for Linux, that's why they are not exotic for audio production. Those cards have drivers that work. When I've got a set up and I'll upgrade it, it's ok if things get borked, because of a new sound server. But if a group of people file bug reports, than it's ignorant not to fix the new sound server, but instead to demand that it must become dependency for more and more software even if it has nothing to do with audio. - Ralf
On 29 January 2012 18:44, Ralf Mardorf <ralf.mardorf@alice-dsl.net> wrote:
[snip] When I've got a set up and I'll upgrade it, it's ok if things get borked, because of a new sound server. But if a group of people file bug reports, than it's ignorant not to fix the new sound server, but instead to demand that it must become dependency for more and more software even if it has nothing to do with audio.
- Ralf
GDM has to do with audio. It supports everything gnome wants to support. Which means it needs audio to either play a sound when you input a wrong password or to read the usernames aloud in case the user has visibility problems. It might work without pulseaudio (dummy package), sure, but it might not work as intended. The guys at the Gnome project decided they want pulseaudio. Now you can either try and convince them to drop support or convince the PulseAudio team to fix it's problems. -- Thanasis Georgiou
On Sun, Jan 29, 2012 at 5:52 PM, Thanasis Georgiou <sakisds.s@gmail.com>wrote:
On 29 January 2012 18:44, Ralf Mardorf <ralf.mardorf@alice-dsl.net> wrote:
[snip] When I've got a set up and I'll upgrade it, it's ok if things get borked, because of a new sound server. But if a group of people file bug reports, than it's ignorant not to fix the new sound server, but instead to demand that it must become dependency for more and more software even if it has nothing to do with audio.
- Ralf
GDM has to do with audio. It supports everything gnome wants to support. Which means it needs audio to either play a sound when you input a wrong password or to read the usernames aloud in case the user has visibility problems. It might work without pulseaudio (dummy package), sure, but it might not work as intended. The guys at the Gnome project decided they want pulseaudio. Now you can either try and convince them to drop support or convince the PulseAudio team to fix it's problems.
Indeed, this should be the thing the complainers _should_ be doing. Archlinux ships vanilla upstream, so you're really barking at the wrong tree here. Please consider asking either PA for help or ditch it.
-- Thanasis Georgiou
-- Jelle van der Waa
Am Sun, 29 Jan 2012 18:35:07 +0100 schrieb Jelle van der Waa <jelle@vdwaa.nl>:
Indeed, this should be the thing the complainers _should_ be doing. Archlinux ships vanilla upstream, so you're really barking at the wrong tree here. Please consider asking either PA for help or ditch it.
I don't think this is the totally wrong place, maybe not the very best, but not the worst. Because even if this mailing list is generally distribution specific and the Arch Linux devs try their best to keep PA optional, it's not quite unlikely that other people read this mailing list. Sometimes important changes come from downstream to upstream. Tom also mentioned that regarding the FHS. He told me - I'm not sure anymore if he did this on the list or in a private e-mail - that the new directory structures are first tested in the distros and then will be worked into the new FHS. So those new directory structures are first discussed in the distro specific mailing lists, too, like it has been done on this list with the discussion about /var/run and /run recently. So I think those discussions don't necessarily need to, but can be quite important. If nobody opens his mouth no matter where, nothing will change. Heiko
On Sun, Jan 29, 2012 at 05:44:46PM +0100, Ralf Mardorf wrote:
On Sun, 2012-01-29 at 16:57 +0100, Martti Kühne wrote:
it's actually possible to get most features that come with gdm, eg. session chooser, working with xdm.
This was the same for GDM. What would you do if the next upgrade will make XDM depend to PA? Of cause, you'll simply install another login manager. But what will you do if really important applications get such an unneeded dependency and it will break your work flow completely?
Umm, I'd focus efforts and patch it already out there. Or maybe I'd write my own display manager. XDM is, as the name implies, intended as a sane default, if you don't like it you're invited to replace it with something more fitting for your purposes. Actually a recurring trend in the linux world is the origin of software right out of this kind of flamewar-fermented discussions, and new solutions pop up where software that has reached a certain age gets feature bloated and unfitting for your particular purpose. So, you're the guy to change that and write a new display manager for X? I'd happily help you. However this is a downstream mailing list that does not benefit of this discussion, because the only thing I've been reading for two days now is that there are ppl pissed with dumb upstream decisions... and it's still not an arch problem. You cannot expect us, as users of this distro to solve the issues you create yourself through unflexible decision making and this non-coder's attitude. You want to focus on more important things, then do that already. I really expected you'd guess that some time.
That's the point. Again and again and again, it's no problem as long as it is for PA only and you've the knowledge to build a dummy package.
Great. So the patches for the actual problem - GDM - are out next week? Leave a message if you need any help with that. You would naturally start with $ cd ~/abs; cp /var/abs/extra/gdm .; cd gdm; makepkg -o; cd src/*/
Fortunately some packaging things for Arch are completely different to some old major distros. So, in this case it seems to be an issue cause upstream, but the more people understand what's the problem is, the better WE can inform upstream.
Yup. I did have trouble with opencbm, and sorting it out I used sed, source diving and reading about make/workingset magic for a few hours. Oh I do read stuff and have no idea about Xlib, and I still manage to set up a more or less crappy desktop environment based on st, dwm, and sandy - incidentally all low-sloc suckless apps which are small enough so I am actually able to debug my self-induced problems. Can't tell how much time I spent on reading xlib manuals to get to a solution more by accident... don't care, either, because it's fun.
When I've got a set up and I'll upgrade it, it's ok if things get borked, because of a new sound server. But if a group of people file bug reports, than it's ignorant not to fix the new sound server, but instead to demand that it must become dependency for more and more software even if it has nothing to do with audio.
yeah, if you'do not have a linus (in the software sense) and rms (in an ideologic sense) sitting on some dictatorship form of running things around here (is it godwin time yet?), all the other wannabes would fork linux to death. I do support the freedom of choice, but I do not feel obliged to patch gdm for you, because it's just not currently my problem. cheers! mar77i
On Sun, Jan 29, 2012 at 11:52 AM, Martti Kühne <mysatyre@gmail.com> wrote:
On Sun, Jan 29, 2012 at 05:44:46PM +0100, Ralf Mardorf wrote:
On Sun, 2012-01-29 at 16:57 +0100, Martti Kühne wrote:
it's actually possible to get most features that come with gdm, eg. session chooser, working with xdm.
This was the same for GDM. What would you do if the next upgrade will make XDM depend to PA? Of cause, you'll simply install another login manager. But what will you do if really important applications get such an unneeded dependency and it will break your work flow completely?
Umm, I'd focus efforts and patch it already out there. Or maybe I'd write my own display manager. XDM is, as the name implies, intended as a sane default, if you don't like it you're invited to replace it with something more fitting for your purposes.
Actually a recurring trend in the linux world is the origin of software right out of this kind of flamewar-fermented discussions, and new solutions pop up where software that has reached a certain age gets feature bloated and unfitting for your particular purpose. So, you're the guy to change that and write a new display manager for X? I'd happily help you.
However this is a downstream mailing list that does not benefit of this discussion, because the only thing I've been reading for two days now is that there are ppl pissed with dumb upstream decisions... and it's still not an arch problem. You cannot expect us, as users of this distro to solve the issues you create yourself through unflexible decision making and this non-coder's attitude. You want to focus on more important things, then do that already. I really expected you'd guess that some time.
^^^^ i second that emotion!
That's the point. Again and again and again, it's no problem as long as it is for PA only and you've the knowledge to build a dummy package.
Great. So the patches for the actual problem - GDM - are out next week? Leave a message if you need any help with that. You would naturally start with
$ cd ~/abs; cp /var/abs/extra/gdm .; cd gdm; makepkg -o; cd src/*/
^^^^ indeed!
Fortunately some packaging things for Arch are completely different to some old major distros. So, in this case it seems to be an issue cause upstream, but the more people understand what's the problem is, the better WE can inform upstream.
Yup. I did have trouble with opencbm, and sorting it out I used sed, source diving and reading about make/workingset magic for a few hours. Oh I do read stuff and have no idea about Xlib, and I still manage to set up a more or less crappy desktop environment based on st, dwm, and sandy - incidentally all low-sloc suckless apps which are small enough so I am actually able to debug my self-induced problems. Can't tell how much time I spent on reading xlib manuals to get to a solution more by accident... don't care, either, because it's fun.
^^^^ hooray!
When I've got a set up and I'll upgrade it, it's ok if things get borked, because of a new sound server. But if a group of people file bug reports, than it's ignorant not to fix the new sound server, but instead to demand that it must become dependency for more and more software even if it has nothing to do with audio.
yeah, if you'do not have a linus (in the software sense) and rms (in an ideologic sense) sitting on some dictatorship form of running things around here (is it godwin time yet?), all the other wannabes would fork linux to death. I do support the freedom of choice, but I do not feel obliged to patch gdm for you, because it's just not currently my problem.
^^^^ down with big brother! kill the beast! ... soooo, how about an `arch-offtopic` list? then at least we'd have somewhere to send these tangents, under pain of DEATH (er, temp ban perhaps), vs. begging and pleading for them to die ... since there is an obvious refusal to take them to the forum, or a blog, or a diary under the pillow. (it would be cool if you could re-assign a Message-ID to a specific list ...) who's with me? my phone is crying wolf so often i miss stuff i actually *do* want to read ... i like this list and would rather hang around. i still fail to see any concrete problems ... and ftw, the OP's question was answered on message #8, and concluded with "[...] no problem at all. i just like to understand whats going on [...]". ... a true champion! -- C Anthony
On Sun, Jan 29, 2012 at 12:08:27PM -0600, C Anthony Risinger wrote:
... soooo, how about an `arch-offtopic` list? then at least we'd have somewhere to send these tangents, under pain of DEATH (er, temp ban perhaps), vs. begging and pleading for them to die ... since there is an obvious refusal to take them to the forum, or a blog, or a diary under the pillow. (it would be cool if you could re-assign a Message-ID to a specific list ...)
who's with me?
+1, wondering why no one picked that up yet.
On Mon, Jan 30, 2012 at 4:17 PM, Martti Kühne <mysatyre@gmail.com> wrote:
On Sun, Jan 29, 2012 at 12:08:27PM -0600, C Anthony Risinger wrote:
... soooo, how about an `arch-offtopic` list? then at least we'd have somewhere to send these tangents, under pain of DEATH (er, temp ban perhaps), vs. begging and pleading for them to die ... since there is an obvious refusal to take them to the forum, or a blog, or a diary under the pillow. (it would be cool if you could re-assign a Message-ID to a specific list ...)
who's with me?
+1, wondering why no one picked that up yet.
It's easy enough for me to mute the threads I don't want to listen to - no matter what ML.
On Mon, Jan 30, 2012 at 4:28 PM, Karol Blazewicz <karol.blazewicz@gmail.com> wrote:
It's easy enough for me to mute the threads I don't want to listen to - no matter what ML.
How do you do that?
On Mon, Jan 30, 2012 at 4:34 PM, SanskritFritz <sanskritfritz@gmail.com> wrote:
On Mon, Jan 30, 2012 at 4:28 PM, Karol Blazewicz <karol.blazewicz@gmail.com> wrote:
It's easy enough for me to mute the threads I don't want to listen to - no matter what ML.
How do you do that?
I'm using gmail and it's under the 'more' button / list (first one on the right when you select or read / reply to a message).
On Mon, Jan 30, 2012 at 4:37 PM, Karol Blazewicz <karol.blazewicz@gmail.com> wrote:
On Mon, Jan 30, 2012 at 4:34 PM, SanskritFritz <sanskritfritz@gmail.com> wrote:
On Mon, Jan 30, 2012 at 4:28 PM, Karol Blazewicz <karol.blazewicz@gmail.com> wrote:
It's easy enough for me to mute the threads I don't want to listen to - no matter what ML.
How do you do that?
I'm using gmail and it's under the 'more' button / list (first one on the right when you select or read / reply to a message).
I meant the standard gmail webmail client https://mail.google.com. I have no idea how to use any e-mail app.
On Mon, Jan 30, 2012 at 4:37 PM, Karol Blazewicz <karol.blazewicz@gmail.com> wrote:
On Mon, Jan 30, 2012 at 4:34 PM, SanskritFritz <sanskritfritz@gmail.com> wrote:
On Mon, Jan 30, 2012 at 4:28 PM, Karol Blazewicz <karol.blazewicz@gmail.com> wrote:
It's easy enough for me to mute the threads I don't want to listen to - no matter what ML.
How do you do that?
I'm using gmail and it's under the 'more' button / list (first one on the right when you select or read / reply to a message).
Ah, so you are using Filter messages. I hoped there was a really easy way, like a 'mute' button that is thread aware :) Anyway, thanks for the advice.
On Mon, Jan 30, 2012 at 4:43 PM, SanskritFritz <sanskritfritz@gmail.com> wrote:
On Mon, Jan 30, 2012 at 4:37 PM, Karol Blazewicz
I'm using gmail and it's under the 'more' button / list (first one on the right when you select or read / reply to a message).
Ah, so you are using Filter messages. I hoped there was a really easy way, like a 'mute' button that is thread aware :) Anyway, thanks for the advice.
Not sure if we are on the same page, because there's another option too: 'Filter messages like these', but I haven't tried it yet. It's enough that the whole thread (based on the title I guess) is moved out of my sight, but I still can access it, if I want. I'm not sure if I want an advanced AI filtering of my messages ;P
2012/1/30 Karol Blazewicz <karol.blazewicz@gmail.com>:
On Mon, Jan 30, 2012 at 4:43 PM, SanskritFritz <sanskritfritz@gmail.com> wrote:
On Mon, Jan 30, 2012 at 4:37 PM, Karol Blazewicz
I'm using gmail and it's under the 'more' button / list (first one on the right when you select or read / reply to a message).
Ah, so you are using Filter messages. I hoped there was a really easy way, like a 'mute' button that is thread aware :) Anyway, thanks for the advice.
Not sure if we are on the same page, because there's another option too: 'Filter messages like these', but I haven't tried it yet. It's enough that the whole thread (based on the title I guess) is moved out of my sight, but I still can access it, if I want.
I'm not sure if I want an advanced AI filtering of my messages ;P
The major off-topics that see discussion here all have their own mailing lists, why not discuss it there? gnome lists: http://mail.gnome.org/mailman/listinfo/ pulse audio's discussion list: http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
On Mon, Jan 30, 2012 at 5:25 PM, Stefan Wilkens <stefanwilkens@gmail.com> wrote:
The major off-topics that see discussion here all have their own mailing lists, why not discuss it there?
gnome lists: http://mail.gnome.org/mailman/listinfo/ pulse audio's discussion list: http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
In the case of PA, +1, as it doesn't seem to be an Arch-focused topic.
On 01/30/12 at 04:43pm, SanskritFritz wrote:
On Mon, Jan 30, 2012 at 4:37 PM, Karol Blazewicz <karol.blazewicz@gmail.com> wrote:
On Mon, Jan 30, 2012 at 4:34 PM, SanskritFritz <sanskritfritz@gmail.com> wrote:
On Mon, Jan 30, 2012 at 4:28 PM, Karol Blazewicz <karol.blazewicz@gmail.com> wrote:
It's easy enough for me to mute the threads I don't want to listen to - no matter what ML.
How do you do that?
I'm using gmail and it's under the 'more' button / list (first one on the right when you select or read / reply to a message).
Ah, so you are using Filter messages. I hoped there was a really easy way, like a 'mute' button that is thread aware :) Anyway, thanks for the advice.
No, it's as you say -- under the More button, there is a 'Mute' button that will simply mute the thread. This is built into gmail. Tim
On Mon, Jan 30, 2012 at 4:52 PM, Tim Stella <denstark@gmail.com> wrote:
On 01/30/12 at 04:43pm, SanskritFritz wrote:
On Mon, Jan 30, 2012 at 4:37 PM, Karol Blazewicz <karol.blazewicz@gmail.com> wrote:
On Mon, Jan 30, 2012 at 4:34 PM, SanskritFritz <sanskritfritz@gmail.com> wrote:
On Mon, Jan 30, 2012 at 4:28 PM, Karol Blazewicz <karol.blazewicz@gmail.com> wrote:
It's easy enough for me to mute the threads I don't want to listen to - no matter what ML.
How do you do that?
I'm using gmail and it's under the 'more' button / list (first one on the right when you select or read / reply to a message).
Ah, so you are using Filter messages. I hoped there was a really easy way, like a 'mute' button that is thread aware :) Anyway, thanks for the advice.
No, it's as you say -- under the More button, there is a 'Mute' button that will simply mute the thread. This is built into gmail.
Found the problem. The Mute button works only in the Inbox. I have a rule that applies a label for the mailing list, and moves them out of the inbox, hence there is no mute button :( Thanks guys for the help.
Am Mon, 30 Jan 2012 16:17:48 +0100 schrieb Martti Kühne <mysatyre@gmail.com>:
On Sun, Jan 29, 2012 at 12:08:27PM -0600, C Anthony Risinger wrote:
... soooo, how about an `arch-offtopic` list? then at least we'd have somewhere to send these tangents, under pain of DEATH (er, temp ban perhaps), vs. begging and pleading for them to die ... since there is an obvious refusal to take them to the forum, or a blog, or a diary under the pillow. (it would be cool if you could re-assign a Message-ID to a specific list ...)
who's with me?
+1, wondering why no one picked that up yet.
This wouldn't change much. The original topic was Arch related. The discussion about PA etc. evolved from this. So such a discussion wouldn't be switched to another mailing list. Same for any other similar discussions. See my try to change the subject from mount to PA. The discussion about PA has mostly been continued under the original subject. And there's another disadvantage. This arch-offtopic list would most likely not read by so many people and probably not by the "right" people whatever that might mean. A new mailing-list arch-offtopic would only be used for discussions which are originally be totally offtopic. And probably not even then, if someone isn't aware that his topic is offtopic. So if such a discussion would indeed be moved to an arch-offtopic list this would mean people can directly shut their mouth. So almost no chance for changes. People who are not interested in a thread can either ignore this thread, just filter it out or move its e-mails to /dev/null with their e-mail clients. Heiko
On Mon, Jan 30, 2012 at 10:43 AM, Heiko Baums <lists@baums-on-web.de> wrote:
This wouldn't change much. The original topic was Arch related. The discussion about PA etc. evolved from this. So such a discussion wouldn't be switched to another mailing list. Same for any other similar discussions. See my try to change the subject from mount to PA. The discussion about PA has mostly been continued under the original subject.
in the forums threads can be locked and what not -- there simply needs to be more aggressive enforcement/definition of the expected lines of conversation. if the description is too vague, clarify it. it people misstep, inform them. if they continue, warn them. if they refuse, temp ban them. if they chronically disregard everyone's time and patience, perma-boot them. no different than IRC or any other medium.
And there's another disadvantage. This arch-offtopic list would most likely not read by so many people and probably not by the "right" people whatever that might mean.
yeah? arch-general already has plenty of the "right" people missing. this gets said all the time "you need to raise bugreport, no one here". i've seen plenty of "well, i'm done with this list" by such people. this point is a noop imo, because if you want action you have to channel it appropriately, not sound off again and again hoping for *someone else* to pick up the slack. a really famous guy once said "be the change you wish to see [...]". make a conscious effort to understand why things are not working as you believe they should. respect the goals of the developers you are conflicted with. communicate clearly/respectably/persistently to make yourself known. recognize that you may be misinformed or flat out wrong in your understandings. find the solution. find a workaround. find an alternative. move forward. ... anything else causes no real work, only the constant energy expenditure of competing forces [ http://en.wikipedia.org/wiki/Work_%28physics%29 ]
A new mailing-list arch-offtopic would only be used for discussions which are originally be totally offtopic. And probably not even then, if someone isn't aware that his topic is offtopic.
nah, just like in IRC ... "#arch-offtopic please."
So if such a discussion would indeed be moved to an arch-offtopic list this would mean people can directly shut their mouth. So almost no chance for changes.
sure that's a possibility, but far less probable because it's the equivalent of a brick wall. some refuse to use more general medium like forums etc, and while i can respect that, this isn't a newsgroup system with thousands of channels. this is a specific mailing list that people join for a highly related reasons. /methinks if you rant on a newsgroup they too will quickly tell you to beat it. an alternative list *creates* an *appropriate* channel to *refer* them too vs. slamming the door in the face and wondering why they keep chattering on the porch.
People who are not interested in a thread can either ignore this thread, just filter it out or move its e-mails to /dev/null with their e-mail clients.
not always, and i use a mobile 70%+ of the time. i don't want to create a new filter for every long-winded thread to nowhere. maybe i can create a label -> trash, and flag multiple conversations ... maybe i can't. why should i? ... you know what's way cooler? believing others are capable of respecting each other's time, and the reason others join a list in the first place (ie. the expected boundaries). another alternative is to move away from mailman oldness, and use something like lamson/librelist, which can spawn lists on the fly in a democratic way. then people can talk about whatever they want 'till blue in the face. with a small amount of work we could enable the community to moderate it too, with a command system similar to majordomo (i use this setup now, straightforward to add). but, as it stands, i'm not going to go out of my way to quash the inconsiderations of others, because it's even simpler to unsubscribe. -- C Anthony
Am Mon, 30 Jan 2012 12:14:01 -0600 schrieb C Anthony Risinger <anthony@xtfx.me>:
not always, and i use a mobile 70%+ of the time. i don't want to create a new filter for every long-winded thread to nowhere. maybe i can create a label -> trash, and flag multiple conversations ... maybe i can't. why should i?
Because you don't want to see those e-mails. What do you think to how many mailing lists I am subscribed and in how many threads I'm not interested even on arch-general, aur-general etc. You know what I do with those threads? What anyone else would do. I just ignore them and delete those e-mails, because they may be important and interesting to other people, maybe to the devs, but not to me. Do I tell the people to shut up and not discuss their Nvidia problems because I have an ATI card and am not affected by Nvidia issues? For me discussions about Nvidia are not necessary, for Nvidia users they likely are. For you discussions about PA may be unnecessary, for pro-audio users they are important. Or what do you mean, why there came so much feedback from so many people incl. pro-audio users and why this thread got that long? If your mobile is not capable to handle such e-mail filters, just don't use your mobile for reading such mailing lists or buy a more capable one.
... you know what's way cooler? believing others are capable of respecting each other's time, and the reason others join a list in the first place (ie. the expected boundaries).
Oh, you mean because I should respect your time I should shut up and suspend my judgement? You really mean I should let myself censored because of your time? What about respecting other people's opinion? If such a discussion is unimportant to you and you're not interested in it, just ignore it. I think such a discussions like this one about PA is important, even if it's on an Arch related mailing list. But the problem with PA e.g. resp. this ongoing dependency hell is a general one and Arch is part of the "general" Linux community. And probably such a discussion is read by other more "important" people and then brought to the "right" place, etc. And again, this discussion about PA has evolved from an Arch related topic. So should this discussion just be stopped, because it gets off-topic somehow and you are not interested in it? I guess you should think about that. Heiko
On Mon, Jan 30, 2012 at 12:43 PM, Heiko Baums <lists@baums-on-web.de> wrote:
Am Mon, 30 Jan 2012 12:14:01 -0600 schrieb C Anthony Risinger <anthony@xtfx.me>:
not always, and i use a mobile 70%+ of the time. i don't want to create a new filter for every long-winded thread to nowhere. maybe i can create a label -> trash, and flag multiple conversations ... maybe i can't. why should i?
Because you don't want to see those e-mails.
What do you think to how many mailing lists I am subscribed and in how many threads I'm not interested even on arch-general, aur-general etc. You know what I do with those threads? What anyone else would do. I just ignore them and delete those e-mails, because they may be important and interesting to other people, maybe to the devs, but not to me.
you're not understanding what i've written, or simply being argumentative. i never said -- or even implied -- that only messages interesting to me should be disallowed. i said we are all expected to maintain a high-level of relevancy -- and quality -- to Arch linux problems, directions, and decisions. the 3-ish threads that spawned are irrelevant, and blatantly contradict this expectation. there are no problems we can fix. there are no issues we can address. there is only "the world is against me and my crew"-esque rambling. now, do i believe pro-audio, or pro-*, or hobbyist-*, can ask questions and offer input? of course i do! i even find quite a bit interesting. however one agenda is not weighted differently than the rest, and all forms of constructive conversation *must* have *some* kind of attainable or at least *****discernible***** goal/path, of which the recent PA threads are 100% devoid. ... apply the same logic used in a forum. why am i explaining this? you don't ask Ubuntu questions in the Newbie forum.
Do I tell the people to shut up and not discuss their Nvidia problems because I have an ATI card and am not affected by Nvidia issues?
we both know this is misrepresentative of what i've stated.
For me discussions about Nvidia are not necessary, for Nvidia users they likely are. For you discussions about PA may be unnecessary, for pro-audio users they are important. Or what do you mean, why there came so much feedback from so many people incl. pro-audio users and why this thread got that long?
i've seen several people attribute that PA works fine with the proaudio related tools. i read others validate the use case of PA and acknowledge it's peaceful coexistence. i've watched a handful continuously muddy the water, despite glaring gaps in their linux knowledge or potential solutions. many of the "dependency hell" garbage has nothing to do with PA, or any software, but rather the inability for any known binary package manager to properly express near limitless configurations. tl;dr ... i have no !@#$%^& idea.
If your mobile is not capable to handle such e-mail filters, just don't use your mobile for reading such mailing lists or buy a more capable one.
my phone runs android 4, it probably could handle it. alas, this is about cleaning up the neighborhood, not avoiding certain parks and streets.
... you know what's way cooler? believing others are capable of respecting each other's time, and the reason others join a list in the first place (ie. the expected boundaries).
Oh, you mean because I should respect your time I should shut up and suspend my judgement? You really mean I should let myself censored because of your time? What about respecting other people's opinion?
well, yes, in fact i do. i didn't join to endure prolonged outbursts stemming from a lack of self-control. think about why you are here. think about why hundreds of others are here. try to play nice, or vent frustrations on a medium under your control. i dont think i'm the minority here ;-) but maybe.
If such a discussion is unimportant to you and you're not interested in it, just ignore it.
and in most cases i do, with relatively high tolerance. but guys, seriously ... PA ... !@#$%^& seriously. find a solution, find a workaround, accept it, use a new DE, write a new package manager, use a new distro, compile from scratch or ABS ... ANYTHING CONSTRUCTIVE. ANYTHING. oooor just STFU about it, until you think of a new action item. please. i beg of you. find an outlet that produces meaningful advances in your agenda.
I think such a discussions like this one about PA is important, even if it's on an Arch related mailing list. But the problem with PA e.g. resp. this ongoing dependency hell is a general one and Arch is part of the "general" Linux community. And probably such a discussion is read by other more "important" people and then brought to the "right" place, etc.
the "right" people are simply those who "do" constructive things. and that is the crux of why this and similar topics piss people off -- the loudest voices are not in that group.
And again, this discussion about PA has evolved from an Arch related topic. So should this discussion just be stopped, because it gets off-topic somehow and you are not interested in it?
... say what? mount -> init -> systemd -> Lennart Poettering -> pulseaudio -> linux-dependency-hell-WTF-this-is-mega-crap? ehm ... sure ... if you lump natural mating, selective breeding, and gene-splicingly-genetic-engineering together under one umbrella term, and call it "evolution".
I guess you should think about that.
you're absolutely right! ok-let-me-think-about-that-no. sorry bud. this is exhausting, and just pollutes further ... it's all you from here. i'm not an enemy, just a friend who wants to help you make real progress. -- C Anthony
On Sun, 2012-01-29 at 18:52 +0100, Martti Kühne wrote:
Great. So the patches for the actual problem - GDM - are out next week? Leave a message if you need any help with that. You would naturally start with
Why do you diss me? It's not the problem. If it would be GDM only than simply use this: https://aur.archlinux.org/packages.php?ID=48718 Why is there no chance to talk seriously about a problem? ./configure --disable-pulse when compiling gnome-settings-daemon should do this for this and some other situations, but that was not what we try to explain as the problem.
but I do not feel obliged to patch gdm for you, because it's just not currently my problem.
And I don't need your help regarding to this issue, because this isn't the issue. There's no patch needed, it's just a thing of configuring gnome-settings-daemon, IF THIS THREAD WOULD BE ABOUT GDM AND PA, but it isn't. Btw. haven't you noticed that I was quiet for the last mails? Now everybody knows you are an expert, able to patch GDM and I'm an idiot unable to patch GDM :D. There's no need for a patch and such a contest is wasting time. It's not important what I'm unable or able to do. This isn't a competition. Everybody and I understand that the problem is upstream and any request here is useless. No need to diss anybody. Regards, Ralf
On Sun, Jan 29, 2012 at 07:28:31PM +0100, Ralf Mardorf wrote:
./configure --disable-pulse when compiling gnome-settings-daemon should do this for this and some other situations, but that was not what we try to explain as the problem.
Awesome, is this in aur yet? :D cheers! mar77i
On Sun, Jan 29, 2012 at 7:47 PM, Martti Kühne <mysatyre@gmail.com> wrote:
On Sun, Jan 29, 2012 at 07:28:31PM +0100, Ralf Mardorf wrote:
./configure --disable-pulse when compiling gnome-settings-daemon should do this for this and some other situations, but that was not what we try to explain as the problem.
Awesome, is this in aur yet? :D
cheers! mar77i
On Sun, Jan 29, 2012 at 7:28 PM, Ralf Mardorf <ralf.mardorf@alice-dsl.net> wrote:
It's not the problem. If it would be GDM only than simply use this: https://aur.archlinux.org/packages.php?ID=48718
-- Kwpolska <http://kwpolska.tk> stop html mail | always bottom-post www.asciiribbon.org | www.netmeister.org/news/learn2quote.html GPG KEY: 5EAAEA16 | Arch Linux x86_64, zsh, mutt, vim. # vim:set textwidth=70:
On Sun, 29 Jan 2012 17:44:46 +0100 Ralf Mardorf <ralf.mardorf@alice-dsl.net> wrote:
On Sun, 2012-01-29 at 16:57 +0100, Martti Kühne wrote:
it's actually possible to get most features that come with gdm, eg. session chooser, working with xdm.
This was the same for GDM. What would you do if the next upgrade will make XDM depend to PA? Of cause, you'll simply install another login manager. But what will you do if really important applications get such an unneeded dependency and it will break your work flow completely? That's the point. Again and again and again, it's no problem as long as it is for PA only and you've the knowledge to build a dummy package.
So how exactly does an unwanted dep break your workflow? So XDM depends on PA -- big deal -- noone forces you to actually use PA. Just get your job done and in the evening rebuild the package.
What are "less common" audio cards? Envy24 is a very common microchip used by tons of audio cards, not only for audio production. RME are the only good supported, professional cards for Linux, that's why they are not exotic for audio production. Those cards have drivers that work.
When I've got a set up and I'll upgrade it, it's ok if things get borked, because of a new sound server. But if a group of people file bug reports, than it's ignorant not to fix the new sound server, but instead to demand that it must become dependency for more and more software even if it has nothing to do with audio.
PA, gnome, consolekit are essentially redhat things and are very closely tight to fedora. These people are trying to produce a great OS. They don't have to care about other linuxes. Do you have to pay for PA/gnome? If you are sooooo unhappy with PA -- fork it and develop it the way you like.
- Ralf
-- Leonid Isaev GnuPG key ID: 164B5A6D Key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
Hi :) the real issue isn't solved, but here are two hints how to get rid of PA for current Arch Linux, to stop the never ending, useless discussion. On Sun, 2012-01-29 at 13:23 -0600, Leonid Isaev wrote:
Just get your job done and in the evening rebuild the package.
I'm using this package since I'm using audio with Arch Linux $ ls /usr/src/pulseaudio-dummy -l Dec 23 18:10 PKGBUILD Jan 15 01:43 pulseaudio-dummy-1.0-1-any.pkg.tar.xz I'm in no hurry ;). Anyway those solutions might be helpful for others: gnome-settings-daemon-nopulse 3.2.2-1 is available at https://aur.archlinux.org/packages.php?ID=48718 I'm using a pulseaudio-dummy package. $ cat /usr/src/pulseaudio-dummy/PKGBUILD pkgname=pulseaudio-dummy pkgver=1.0 pkgrel=1 pkgdesc="A dummy package that pretends to provide pulseaudio." arch=('any') url="" license=('BSD') provides=('pulseaudio') conflicts=('pulseaudio') source=() Both posted several times before. Btw. somebody from this list explained me how to build dummy-packages for Arch Linux, by this example, since I'm new to Arch. A dummy-package IMO is the best way to go, since it protect against installing PA, what ever I do. So I can install what ever GNOME or KDE app I like and if I should install GNOME3, I could upgrade gnome-settings-daemon from extra, without taking care about PA. Perhaps this could damage an app, but I never experienced this for another Linux install I used. This are just workarounds that don't solve the essence of that issue. Ok, the essence has to be clarified with upstream.
Do you have to pay for PA/gnome?
I'm using XFCE. The sub-thread was about issues caused by the policy of PA, not about my personal problems I might or might not have. :) Ralf PS: I suspect [solved] is for "silence", regarding to the S/N ratio.
On Sun, 29 Jan 2012 21:27:46 +0100 Ralf Mardorf <ralf.mardorf@alice-dsl.net> wrote:
Hi :)
the real issue isn't solved, but here are two hints how to get rid of PA for current Arch Linux, to stop the never ending, useless discussion.
On Sun, 2012-01-29 at 13:23 -0600, Leonid Isaev wrote:
Just get your job done and in the evening rebuild the package.
I'm using this package since I'm using audio with Arch Linux $ ls /usr/src/pulseaudio-dummy -l Dec 23 18:10 PKGBUILD Jan 15 01:43 pulseaudio-dummy-1.0-1-any.pkg.tar.xz I'm in no hurry ;).
Anyway those solutions might be helpful for others:
gnome-settings-daemon-nopulse 3.2.2-1 is available at https://aur.archlinux.org/packages.php?ID=48718
I'm using a pulseaudio-dummy package.
$ cat /usr/src/pulseaudio-dummy/PKGBUILD pkgname=pulseaudio-dummy pkgver=1.0 pkgrel=1 pkgdesc="A dummy package that pretends to provide pulseaudio." arch=('any') url="" license=('BSD') provides=('pulseaudio') conflicts=('pulseaudio') source=()
Both posted several times before. Btw. somebody from this list explained me how to build dummy-packages for Arch Linux, by this example, since I'm new to Arch.
A dummy-package IMO is the best way to go, since it protect against installing PA, what ever I do. So I can install what ever GNOME or KDE app I like and if I should install GNOME3, I could upgrade gnome-settings-daemon from extra, without taking care about PA.
The dependency problem which everyone seems to be concerned about is not going anywhere: any linux distro was, is and will be a "mix-and-match". Packagers try to enable maximum functionality -- hence you have unwanted applications -- but you can't expect them to satisfy your personal preferences. So if this situation bothers you there is only one realistic choice -- gentoo.
Perhaps this could damage an app, but I never experienced this for another Linux install I used.
This are just workarounds that don't solve the essence of that issue. Ok, the essence has to be clarified with upstream.
Do you have to pay for PA/gnome?
I'm using XFCE. The sub-thread was about issues caused by the policy of PA, not about my personal problems I might or might not have.
:) Ralf
PS: I suspect [solved] is for "silence", regarding to the S/N ratio.
-- Leonid Isaev GnuPG key ID: 164B5A6D Key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
On Sun, 29 Jan 2012 21:27:46 +0100 Ralf Mardorf wrote:
I know today, but dependency hell still is an issue, even for Arch.
Gnome was going to depend on Linux, precluding it from the BSDs and I guess custom kernels. Blanket dependencies have been regarded as one of the biggest problems with Linux for years, once said to be getting better finally and yet it appears to be getting worse. Should I be able to use Dolphin on xfce without installing hundreds of megabytes that then need to be updated. P.s. Pulse audio doesn't work with grsecurity kernels without pax marking (feature diabling). Alsa works fine. Please include that if you join the gnome mailing list. -- Kc
Am Sun, 29 Jan 2012 11:03:13 -0400 schrieb Norbert Zeh <nzeh@cs.dal.ca>:
Let me chime in here to add an important point to this discussion. The whole discussion so far sounds as if PA works great with non-pro cards and breaks only on pro cards. That's not the case: PA has problems even with what is probably the lowest end of chips: built-in audio chips on all my motherboards. And the behaviour I observed is exactly what Heiko and Ralf observed too: everything works great with ALSA and starts to act up when using PA.
Things I observed (on Ubuntu, Mint, openSUSE, Arch...so it's not distro-specific) were way too low input (mic) and output volumes even when setting the volume controls to 100%.
That's not the point with pro-audio hardware. The problem with ice1712 chips is that those chips aren't stereo or surround sound chips. Those cards have instead separate lines for in- and output. They can of course be mixed as normal stereo, but they can mixed however you want. Those cards don't have a master volume control or an amplifier, they only have attenuators. So those cards can't be handled like those consumer sound cards, and they need a special mixer and patch bay. ALSA delivers one in the package alsa-tools called envy24control. PA just knows pure stereo and maybe surround sound. PA wants to have a master volume control. PA doesn't have a mixer and patch bay for those cards. And the PA developers blame ALSA for this and just think crippling down those cards to pure stereo cards with an ominous ALSA configuration. Of course, this is a very dirty workaround to get those cards somehow working with PA, but with this configuration you disable all the other functionality of those cards. That is the problem. Well, it's not a problem as long as PA stays just optional so that people who like the features of PA and just use a consumer sound card can use PA and the pro-audio users don't need to use it. So the problem is that PA is made more and more as a standard by several up- and downstreams. That is what worries me.
I really wanted to use PA because it offers something ALSA does not: simultaneous audio streams from different applications (i.e., when firing up Windows in a VirtualBox, it does not hog my audio).
Simultaneous audio streams from different applications are mixed together by ALSA's dmix which is activated by default since years. I haven't tested sound from VirtualBox, yet. Heiko
On Sun, Jan 29, 2012 at 4:03 PM, Norbert Zeh <nzeh@cs.dal.ca> wrote:
Things I observed (on Ubuntu, Mint, openSUSE, Arch...so it's not distro-specific) were way too low input (mic) and output volumes even when setting the volume controls to 100%. I really wanted to use PA because it offers something ALSA does not: simultaneous audio streams from different applications (i.e., when firing up Windows in a VirtualBox, it does not hog my audio). So I googled for hours, read through forum posts, etc. and all I could find were hacks that either didn't work at all or resulted in the right volume but at completely unacceptable distortion levels.
So, I'm almost certain that I am doing something wrong with configuring my audio setup using PA,
This sounds like a good, old-fashioned bug, I don't think you did anything wrong in your setup. Most likely your sound driver (ALSA) is exporting the wrong dB information to PulseAudio which means that PA's volume calculations will be nonsense. Please file a bug against ALSA. Cheers, Tom
On Sun, 2012-01-29 at 22:41 +0100, Tom Gundersen wrote:
On Sun, Jan 29, 2012 at 4:03 PM, Norbert Zeh <nzeh@cs.dal.ca> wrote:
Things I observed (on Ubuntu, Mint, openSUSE, Arch...so it's not distro-specific) were way too low input (mic) and output volumes even when setting the volume controls to 100%. I really wanted to use PA because it offers something ALSA does not: simultaneous audio streams from different applications (i.e., when firing up Windows in a VirtualBox, it does not hog my audio). So I googled for hours, read through forum posts, etc. and all I could find were hacks that either didn't work at all or resulted in the right volume but at completely unacceptable distortion levels.
So, I'm almost certain that I am doing something wrong with configuring my audio setup using PA,
This sounds like a good, old-fashioned bug, I don't think you did anything wrong in your setup. Most likely your sound driver (ALSA) is exporting the wrong dB information to PulseAudio which means that PA's volume calculations will be nonsense. Please file a bug against ALSA.
Since the sound device is ok when using ALSA only, the +4dBu vs -10dBV information or any ratio dB to fader position or what ever you mean, must be somewhere provided correctly by ALSA. If such a dB issue should be the cause, than I suspect PA pulls this information from the wrong place. What happens, when using Arts or any other sound server? In case of doubt file a bug report to ALSA and PA. IIRC the sound device works correctly since years for ALSA, just when using PA there's distortion. Is it reasonable to assume that there's a bug for ALSA? Perhaps an user error? If the device should support +4dBu and -10dBV, than the user perhaps missed to choose the correct level. Nor ALSA neither PA does know what equipment is connected to the audio IOs.
On Sun, Jan 29, 2012 at 11:04 PM, Ralf Mardorf <ralf.mardorf@alice-dsl.net> wrote:
Since the sound device is ok when using ALSA only, the +4dBu vs -10dBV information or any ratio dB to fader position or what ever you mean, must be somewhere provided correctly by ALSA. If such a dB issue should be the cause, than I suspect PA pulls this information from the wrong place. What happens, when using Arts or any other sound server?
ALSA is not using this information in the same way (if at all). It is a well known problem that PA will act crazy if the dB values from ALSA are wrong, but ALSA itself mostly does not care (because the user is setting all the mixer level themselves, unlike in PA where there are heuristics doing clever stuff). To learn more, run test and find the correct values that can be reported to ALSA, see: <http://pulseaudio.org/wiki/BadDecibel>.
In case of doubt file a bug report to ALSA and PA.
Sure, but do the test above first. It will save some time.
IIRC the sound device works correctly since years for ALSA, just when using PA there's distortion. Is it reasonable to assume that there's a bug for ALSA?
In this case, this is a well known class of bugs, so yes that's reasonable (but not certain).
Perhaps an user error? If the device should support +4dBu and -10dBV, than the user perhaps missed to choose the correct level. Nor ALSA neither PA does know what equipment is connected to the audio IOs.
The user should not need to know about dB levels when using PA, so this is a software bug (somewhere). -t
On Sun, Jan 29, 2012 at 11:33:34PM +0100, Tom Gundersen wrote:
ALSA is not using this information in the same way (if at all). It is a well known problem that PA will act crazy if the dB values from ALSA are wrong, but ALSA itself mostly does not care (because the user is setting all the mixer level themselves, unlike in PA where there are heuristics doing clever stuff).
There is *no* way PA or anything could ever guess the correct electrical levels (e.g. setting a -10dB/+4dB switch that some soundcards offer) because that depends on what the user has connected to his/her card. The whole mixer control issue is a complete mess, and it's neither ALSA's or PA's fault. The blame has to go to the manufacturers of the audio HW. In some cases the 'normal' setting for a mixer gain is the maximum one, in others it's way below that because the HW is designed to provide a way to boost PCM levels that are too low. And there's no way to find out - in both cases the maximum will be labeled '0dB'. And that's only *one* control, in most cases there are at least two. A trained audio engineer knows how to find out such things and get them right, but the average user is completely lost if there is more than one control that affects volume. All PA should be doing is to provide sensible digital (pcm) levels. The rest, like it or not, has to be done by the user. Another blame has to go to most apps that provide 'desktop' sounds, in almost all cases the level is way too high. Even if I would want a beep or 'plioung' at some times I don't expect it to be as loud as the music. Yet most such apps output near to maximum level. Ciao, -- FA Vor uns liegt ein weites Tal, die Sonne scheint - ein Glitzerstrahl.
On Sun, 2012-01-29 at 23:11 +0000, Fons Adriaensen wrote:
A trained audio engineer knows how to find out such things and get them right, but the average user is completely lost if there is more than one control that affects volume.
So I have translated the text correctly. Comparing two 1s sinus signals at what frequency ever, in a chain of faders, one sinus signal after the other, by listening, for calibrating. Good luck! I wonder about the magic workaround mentioned on the website. Cheers, Ralf
On Mon, Jan 30, 2012 at 12:28:00AM +0100, Ralf Mardorf wrote:
On Sun, 2012-01-29 at 23:11 +0000, Fons Adriaensen wrote:
A trained audio engineer knows how to find out such things and get them right, but the average user is completely lost if there is more than one control that affects volume.
So I have translated the text correctly. Comparing two 1s sinus signals at what frequency ever, in a chain of faders, one sinus signal after the other, by listening, for calibrating. Good luck!
Yes, it's nonsense, there's no good solution for this. And, correcting myself, in a sense it's ALSA's fault. On Windows almost every soundcard has its own specific driver and mixer app. So things can be initialised to defaults that work. ALSA tries to have as much common code as possible. It makes sense from a SW engineering point of view, but it is completely out of touch with reality. Besides all that: Ralf, it would probably enhance your 'street value' on the Arch list if you could restrain yourself a bit. Ciao, -- FA Vor uns liegt ein weites Tal, die Sonne scheint - ein Glitzerstrahl.
On Sun, 2012-01-29 at 23:33 +0100, Tom Gundersen wrote:
On Sun, Jan 29, 2012 at 11:04 PM, Ralf Mardorf <ralf.mardorf@alice-dsl.net> wrote:
Since the sound device is ok when using ALSA only, the +4dBu vs -10dBV information or any ratio dB to fader position or what ever you mean, must be somewhere provided correctly by ALSA. If such a dB issue should be the cause, than I suspect PA pulls this information from the wrong place. What happens, when using Arts or any other sound server?
ALSA is not using this information in the same way (if at all). It is a well known problem that PA will act crazy if the dB values from ALSA are wrong, but ALSA itself mostly does not care (because the user is setting all the mixer level themselves, unlike in PA where there are heuristics doing clever stuff).
To learn more, run test and find the correct values that can be reported to ALSA, see: <http://pulseaudio.org/wiki/BadDecibel>.
In case of doubt file a bug report to ALSA and PA.
Sure, but do the test above first. It will save some time.
IIRC the sound device works correctly since years for ALSA, just when using PA there's distortion. Is it reasonable to assume that there's a bug for ALSA?
In this case, this is a well known class of bugs, so yes that's reasonable (but not certain).
Perhaps an user error? If the device should support +4dBu and -10dBV, than the user perhaps missed to choose the correct level. Nor ALSA neither PA does know what equipment is connected to the audio IOs.
The user should not need to know about dB levels when using PA, so this is a software bug (somewhere).
The +4dBu and -10dBV issue is related to the analog IOs and the connected audio equipment, so it's impossible for any software to know what dB to choose, since they can't detect the connected analog gear. This is another issue: "If (when flat volumes are enabled in PulseAudio) the playback volume of one stream changes whenever another stream is played, this is most likely caused be incorrect dB attenuation data exposed by the ALSA kernel driver. [snip] There's a temporary workaround to make PA skip the invalid dB data. But ha! I won't write down how that works here, to make sure that you really file that bug. Muahaha. Mauahahahahah! " I'm not sure if I translated the complete text correctly. Especially this is hard to understand: "If the third and fourth parameter to dbverify are ommited, the tool will test the loudest volume setting against the softest one. If those arguments are specified the tool will compare these two discrete volumes. It is advisable to play around with these values to compare multiple volume steps of the hardware. It is especially wise to pick your own values if the lowest hw volume setting is too silent to be audible. That said it might make sense to omit these arguments when starting your testing. This will then also show you the available volume step range of your card and you can then pick other values to tes from that range. The tool will play a 1s sine wave twice and in a loop, and attenuate it once in software and once in hardware. The effect should be that the wave should have the same volume both times if the dB information is reliable. If the dB data is not correct, then they will have different volumes. [snip] If this listening test reveals that the dB information of your driver is not correct" What I'm able to translate is very strange.
Tom Gundersen [2012.01.29 2241 +0100]:
On Sun, Jan 29, 2012 at 4:03 PM, Norbert Zeh <nzeh@cs.dal.ca> wrote:
Things I observed (on Ubuntu, Mint, openSUSE, Arch...so it's not distro-specific) were way too low input (mic) and output volumes even when setting the volume controls to 100%. I really wanted to use PA because it offers something ALSA does not: simultaneous audio streams from different applications (i.e., when firing up Windows in a VirtualBox, it does not hog my audio). So I googled for hours, read through forum posts, etc. and all I could find were hacks that either didn't work at all or resulted in the right volume but at completely unacceptable distortion levels.
So, I'm almost certain that I am doing something wrong with configuring my audio setup using PA,
This sounds like a good, old-fashioned bug, I don't think you did anything wrong in your setup. Most likely your sound driver (ALSA) is exporting the wrong dB information to PulseAudio which means that PA's volume calculations will be nonsense. Please file a bug against ALSA.
Thanks, Tom. Now that I know where to look next, I'll play with this next time I have some spare time for this kind of stuff. Cheers, Norbert
On Sun, Jan 29, 2012 at 11:50 PM, Norbert Zeh <nzeh@cs.dal.ca> wrote:
Thanks, Tom. Now that I know where to look next, I'll play with this next time I have some spare time for this kind of stuff.
I recommend going to #systemd on freenode if you have data/questions, they are very friendly and helpful. Cheers, Tom
On 29-01-2012 10:50, Ralf Mardorf wrote:
I just ask that upgrades don't break a working machine, caused by unneeded dependencies. If a studio used GNOME, than an upgrade shouldn't add PA and break the machine.
Deploying untested updates/upgrades on production machines is asking for trouble, regardless of what is getting updated/upgraded. Just my 2 cents. -- Mauro Santos
On Sun, 2012-01-29 at 11:07 +0000, Mauro Santos wrote:
On 29-01-2012 10:50, Ralf Mardorf wrote:
I just ask that upgrades don't break a working machine, caused by unneeded dependencies. If a studio used GNOME, than an upgrade shouldn't add PA and break the machine.
Deploying untested updates/upgrades on production machines is asking for trouble, regardless of what is getting updated/upgraded.
Just my 2 cents.
<ralf.mardorf@alice-dsl.net> wrote:
I'm sure all Linux installs MUST be ready to use out of the box for
Full ACK! For a production machine everybody should make backups, real snapshots, that means not sync the backup, but to keep several backups. Upgrades never should be done during a production. But backups have to be done sometimes and then they shouldn't break a machine, caused by forcing to add dependencies, that shouldn't be dependencies. On Sun, 2012-01-29 at 11:58 +0100, Tom Gundersen wrote: On Sun, Jan 29, 2012 at 11:50 AM, Ralf Mardorf professional audio
users. after all, the same is true for the other operating systems.
I just ask that upgrades don't break a working machine, caused by unneeded dependencies. If a studio used GNOME, than an upgrade shouldn't add PA and break the machine. Only add dependencies if they are needed. PA isn't needed, it's optional. If upstream add it, it might be allowed to explain, why it isn't good to do so.
Sounds like possibly valid concerns. But this is not something to discuss here. Please contact gnome and/or pulseaudio if you have issues. We just package their software, we don't decide their priorities or policies.
And I think this discussion has gone on for way too long...
Passing from pillar to post. A community should think about marginalized groups too. Where ever WE try to explain the problem, it ends like this, or more worse with assumptions similar to those from Oon-Ee Ng. If anybody should have diss somebody named Lennart, it's not fair to put the blame on me. I switched to Arch, because the distros I used before already become hard to use. Talking about PA here, is to prevent Arch to become hard to use too. From that standpoint it belongs to a discussion at some Arch mailing list. If Arch-"general" isn't the right place, it would be nice to add a list Arch-"discussion", Arch-"sandbox" or what ever. 0,02€, Ralf PS: I tried to be quiet, but since others continued with claims that are wrong, I couldn't. Audio users tried to explain that WE experienced "things" as borked and people who never have done audio productions send links and claimed that we don't know the facts. Our experiences aren't experiences, but hearsay only. Is enlightenment unwanted?
On Sat, Jan 28, 2012 at 5:29 PM, Heiko Baums <lists@baums-on-web.de> wrote:
My impression recently was that there are a lot of people doing and inventing a lot of things on their own which has almost nothing to do with any Linux standards, particularly again Lennart Poettering, and that some other distros just take Lennart's ideas without thinking about it, while other distros don't do this, etc.
There has been a lot of changes lately, this is true. However, a lot of effort has been put into reaching consensus between the distros and the relevant upstream projects. Much more so now than before. It is my impression that a majority of the ideas have originated in Debian and Fedora, but I don't really care who came up with what idea as long as we end up with the best ideas in the end (and possibly more importantly, that we all end up with the same ideas). As far as I can tell the different changes are receiving a lot of scrutiny within the different distros before being adopted (as one would expect); and overall we are all moving in the same direction. -t
On Sat, Jan 28, 2012 at 06:46:20PM +0100, Tom Gundersen wrote:
There has been a lot of changes lately, this is true. However, a lot of effort has been put into reaching consensus between the distros and the relevant upstream projects. Much more so now than before.
It is my impression that a majority of the ideas have originated in Debian and Fedora, but I don't really care who came up with what idea as long as we end up with the best ideas in the end (and possibly more importantly, that we all end up with the same ideas). As far as I can tell the different changes are receiving a lot of scrutiny within the different distros before being adopted (as one would expect); and overall we are all moving in the same direction.
One consequence of all these changes is dependency creep. Just one example: emacs depends (via gconf) on consolekit. I've been using emacs for > 15 years or so, and I've never seen it depend on PAM or Kerberos, SSH authentication subsystems, etc. It has no reason to depend on consolekit. And if it does by transitivity that should make its maintainers think twice. Allowing such a dependeny to exist is *bad engineering*. If this trend continues it will end with everything depending on everything. Which means there is no more choice. I know it's not and Arch thing, but still this is cause for concern. Ciao, -- FA Vor uns liegt ein weites Tal, die Sonne scheint - ein Glitzerstrahl.
On Sat, 2012-01-28 at 20:40 +0000, Fons Adriaensen wrote:
One consequence of all these changes is dependency creep. Just one example: emacs depends (via gconf) on consolekit. I've been using emacs for > 15 years or so, and I've never seen it depend on PAM or Kerberos, SSH authentication subsystems, etc. It has no reason to depend on consolekit. And if it does by transitivity that should make its maintainers think twice.
Allowing such a dependeny to exist is *bad engineering*. If this trend continues it will end with everything depending on everything. Which means there is no more choice. I know it's not and Arch thing, but still this is cause for concern.
And this becomes a fashion. Pulseaudio is an unneeded dependency for several software. 4 years ago: https://bugs.launchpad.net/consolekit/+bug/148454/+activity Today: [spinymouse@archlinux ~]$ ps -Lf -C console-kit-daemon UID PID PPID LWP C NLWP STIME TTY TIME CMD root 861 1 861 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 862 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 863 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 864 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 865 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 866 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 867 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 868 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 869 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 870 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 871 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 872 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 873 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 874 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 875 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 876 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 877 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 878 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 879 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 880 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 881 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 882 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 883 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 884 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 885 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 886 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 887 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 888 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 889 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 890 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 891 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 892 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 893 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 894 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 895 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 896 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 897 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 898 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 899 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 900 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 901 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 902 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 903 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 904 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 905 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 906 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 907 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 908 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 909 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 910 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 911 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 912 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 913 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 914 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 915 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 916 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 917 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 918 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 919 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 920 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 921 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 922 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 923 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 925 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 926 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon
On Sat, 28 Jan 2012 22:37:37 +0100 Ralf Mardorf <ralf.mardorf@alice-dsl.net> wrote:
On Sat, 2012-01-28 at 20:40 +0000, Fons Adriaensen wrote:
One consequence of all these changes is dependency creep. Just one example: emacs depends (via gconf) on consolekit. I've been using emacs for > 15 years or so, and I've never seen it depend on PAM or Kerberos, SSH authentication subsystems, etc. It has no reason to depend on consolekit. And if it does by transitivity that should make its maintainers think twice.
Allowing such a dependeny to exist is *bad engineering*. If this trend continues it will end with everything depending on everything. Which means there is no more choice. I know it's not and Arch thing, but still this is cause for concern.
And this becomes a fashion. Pulseaudio is an unneeded dependency for several software.
4 years ago: https://bugs.launchpad.net/consolekit/+bug/148454/+activity
Today: [spinymouse@archlinux ~]$ ps -Lf -C console-kit-daemon UID PID PPID LWP C NLWP STIME TTY TIME CMD root 861 1 861 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 862 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 863 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 864 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 865 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 866 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 867 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 868 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 869 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 870 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 871 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 872 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 873 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 874 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 875 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 876 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 877 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 878 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 879 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 880 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 881 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 882 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 883 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 884 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 885 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 886 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 887 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 888 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 889 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 890 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 891 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 892 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 893 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 894 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 895 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 896 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 897 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 898 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 899 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 900 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 901 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 902 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 903 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 904 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 905 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 906 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 907 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 908 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 909 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 910 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 911 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 912 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 913 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 914 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 915 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 916 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 917 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 918 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 919 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 920 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 921 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 922 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 923 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 925 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 926 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon
Yeah, about CK: https://www.libreoffice.org/bugzilla/show_bug.cgi?id=17720 -- Leonid Isaev GnuPG key ID: 164B5A6D Key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
On Sat, Jan 28, 2012 at 10:37 PM, Ralf Mardorf <ralf.mardorf@alice-dsl.net> wrote:
On Sat, 2012-01-28 at 20:40 +0000, Fons Adriaensen wrote:
One consequence of all these changes is dependency creep. Just one example: emacs depends (via gconf) on consolekit. I've been using emacs for > 15 years or so, and I've never seen it depend on PAM or Kerberos, SSH authentication subsystems, etc. It has no reason to depend on consolekit. And if it does by transitivity that should make its maintainers think twice.
Allowing such a dependeny to exist is *bad engineering*. If this trend continues it will end with everything depending on everything. Which means there is no more choice. I know it's not and Arch thing, but still this is cause for concern.
And this becomes a fashion. Pulseaudio is an unneeded dependency for several software.
4 years ago: https://bugs.launchpad.net/consolekit/+bug/148454/+activity
Today: [spinymouse@archlinux ~]$ ps -Lf -C console-kit-daemon UID PID PPID LWP C NLWP STIME TTY TIME CMD root 861 1 861 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 862 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 863 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 864 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 865 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 866 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 867 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 868 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 869 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 870 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 871 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 872 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 873 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 874 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 875 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 876 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 877 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 878 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 879 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 880 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 881 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 882 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 883 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 884 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 885 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 886 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 887 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 888 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 889 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 890 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 891 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 892 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 893 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 894 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 895 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 896 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 897 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 898 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 899 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 900 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 901 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 902 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 903 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 904 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 905 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 906 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 907 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 908 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 909 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 910 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 911 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 912 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 913 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 914 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 915 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 916 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 917 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 918 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 919 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 920 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 921 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 922 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 923 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 925 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon root 861 1 926 0 65 21:06 ? 00:00:00 /usr/sbin/console-kit-daemon --no-daemon
And this is not so much bad as it is an ugly way of watching all 64 VTs. I don't think this is going to get fixed, seeing as upstream is deprecating ConsoleKit in favor of Logind (tied to Systemd).
On Sat, 28 Jan 2012 20:40:51 +0000 Fons Adriaensen <fons@linuxaudio.org> wrote:
On Sat, Jan 28, 2012 at 06:46:20PM +0100, Tom Gundersen wrote:
There has been a lot of changes lately, this is true. However, a lot of effort has been put into reaching consensus between the distros and the relevant upstream projects. Much more so now than before.
It is my impression that a majority of the ideas have originated in Debian and Fedora, but I don't really care who came up with what idea as long as we end up with the best ideas in the end (and possibly more importantly, that we all end up with the same ideas). As far as I can tell the different changes are receiving a lot of scrutiny within the different distros before being adopted (as one would expect); and overall we are all moving in the same direction.
One consequence of all these changes is dependency creep. Just one example: emacs depends (via gconf) on consolekit. I've been using emacs for > 15 years or so, and I've never seen it depend on PAM or Kerberos, SSH authentication subsystems, etc. It has no reason to depend on consolekit. And if it does by transitivity that should make its maintainers think twice.
http://www.gnu.org/software/emacs/NEWS.23.2 Care to file a bug?
Allowing such a dependeny to exist is *bad engineering*. If this trend continues it will end with everything depending on everything. Which means there is no more choice. I know it's not and Arch thing, but still this is cause for concern.
Ciao,
-- Leonid Isaev GnuPG key ID: 164B5A6D Key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
On Sat, Jan 28, 2012 at 03:41:06PM -0600, Leonid Isaev wrote:
This doesn't provide any reason why emacs should depend on consolekit for its functionality. It only says it depends on gconf to find out a 'default font', and that you can opt out at compile time. I may depend on my local garage to keep my car in order, but that doesn't mean I have to depend on it for anything else. I don't have to buy my carrots where the mechanic gets them. Things like gconf impose an 'all or nothing' dependency and that is where it all goes wrong, and why no app should have a compiled-in dependency on them. It's easy enough to make this a run-time choice. Ciao, -- FA Vor uns liegt ein weites Tal, die Sonne scheint - ein Glitzerstrahl.
It would be nice to have a sandbox, a list to discuss things like this. I guess non of those is the right place: http://mailman.archlinux.org/mailman/listinfo So a last note by me, then I'll be quiet. On Sat, 2012-01-28 at 17:29 +0100, Heiko Baums wrote:
Am Sat, 28 Jan 2012 15:09:30 +0100 schrieb Tom Gundersen <teg@jklm.no>:
Have you tried after this fix was released: <http://git.alsa-project.org/?p=alsa-lib.git;a=commitdiff;h=d3906a93072171e5b5f4000d4a228af4eb8fa253>?
Like I've written in another e-mail in this thread:
And, no, artificially crippling a (semi-)professional audio card down to stereo with a strange ALSA configuration is not a solution for this. And, no, it's not ALSA's fault like Lennart Poettering says, it's PulseAudio's fault.
When Suse switched to PA years ago, they blamed users for not understanding Linux, the audio experts from Suse forums didn't know how to fix it, but they were sure, stupid users like me must have broken their Suse, because stupid users like me are to stupid to install Suse from DVD. They called me a troll. This is how I fixed Suse a long time ago and this solution wasn't from any Suse experts, this and other hints are from the Linux "pro-"audio community. [root@archlinux spinymouse]# mount /dev/sda7 /mnt/suse11.2 [root@archlinux spinymouse]# cat /mnt/suse11.2/usr/share/alsa/cards/ICE1712.conf [snip] <confdir:pcm/front.conf> ICE1712.pcm.front.0 { @args [ CARD ] @args.CARD { type string } type route ttable.0.0 1 ttable.1.1 1 slave.pcm { type hw card $CARD } #### fix PA issue #### slave.format S32_LE slave.channels 10 ###################### } [snip] IMO it make no sense to discuss the PA issue, especially not when the thread is about "mount". I wonder why distros not simply provide dummy packages to replace the PA packages, if users prefer not to install PA. It's not secure to think that some distro doesn't force users to install PA, e.g. for Debian GNOME2 didn't force you to install it, but with the upgrade to GNOME3, they introduced it. And there's absolutely no reason to do it. GNOME3 on Debian did run and audio wasn't broken, when I replaced PA by a self-build dummy package. Yes, I already wrote this in another thread. So arguing a user should use another DE, if he doesn't like PA, isn't a solution. Btw. here on Arch I wish to be free to use GDM even if my DE is XFCE. I installed a dummy for PA here too. I really wonder why DM needs PA ;). As I mentioned before, most users and developers praise PA, even some pro-audio developers aren't against PA, so we should learn to live with it. More OT: We should pray not to get tons of sub-versions for different versions of jack ;) [root@archlinux spinymouse]# pacman -Ss jack2 | grep / community/jack2 1.9.8-1 [installed] community/jack2-dbus 1.9.8-1 multilib/jack2-dbus-multilib 1.9.8-1 multilib/jack2-multilib 1.9.8-1 kxstudio-free/jack2-dbus-ladish 1.9.7-3 kxstudio-free/jack2-ladish 1.9.7-3 fortunately we're still free to use packages for a classic "jack", build to connect and not to refuse connections.
This is what is done by this fix. But those (semi-)professional audio cards with an ice1712 chip aren't SoundBlaster like stereo sound cards for playing some games. They work completely different, because they have several separate channels which can be mixed however you want (of course to normal stereo, too, but not only). Look at the only working mixer for this card, envy24control in alsa-tools (or alsa-tools-ice1712 from AUR), to get a clue. [snip]
On 28-01-12 17:29, Heiko Baums wrote:
Am Sat, 28 Jan 2012 15:09:30 +0100 schrieb Tom Gundersen<teg@jklm.no>:
Apologies for the late reply, but the length of the thread kept me off for a while. [...]
The different usecases of /media and /mnt are explained in the FHS link you provided.
I don't see any difference there. Optical media contain a filesystem and harddisks contain filesystems. Both are usually mounted temporarily. So what's the difference?
There is actually a *HUGE* difference, but there is also some history involved in this. I don't have links handy, but i'm sure google can help you out here. Also, this is just my understanding of it, so YMMV. First: harddisk were considered fixed. If they were there when the system started up, one could mostly assume they would stay there. Besides those "always there" blockdevices, there were also CD-ROMs with their removable media. Since the *device* would probably stay where it was, it was easy to create an entry in /etc/fstab for those so users could use them and rely on where they would show up. Some distro's chose to use /mnt as a mountpoint for CD-Roms, some others created subdirectories below /mnt. Despite these small differences, the general behavior was well understood and workable. Then came USB (and other removable) storage and the trouble began. Now there were *devices* that would appear and disappear while the system was still running. I think that there were a couple of solutions to handle this situation, but no real standard. I'm not sure how the standardization went, but it ended up with the current /media hierarchy. No more fixed entries in /etc/fstab to allow users to mount and use those devices, but dynamically created mountpoints and possibly also auto-mounting. This way the system doesn't need any info on possible storage media beforehand, but everything is created on the fly, when needed. Quite a nice and elegant solution, if you ask me. With this in mind, the FHS decisions seem fairly logical: - /mnt is used in different ways, so it's best to steer away from it - /media is where we mount removable storage. It has not (much) tradition behind it, so it's easy to create a new standard with it. Hope that helps. mvg, Guus
On Sat, Jan 28, 2012 at 12:56 AM, Fons Adriaensen <fons@linuxaudio.org> wrote:
On Sat, Jan 28, 2012 at 12:50:09AM +0100, Tom Gundersen wrote:
On Sat, Jan 28, 2012 at 12:35 AM, G. Schlisio <g.schlisio@gmx.de> wrote:
Am 28.01.2012 00:26, schrieb G. Schlisio:
Hi all, i used to keep a folder in /media to serve as mountpoint if some manual mountis was needed. since some days, this folder disappeared, even if created again. is there any change in filesystems, kernel or whatsoever changing behavior there, is it intended (if so, why?) or a bug? every hint appreciated.
If you are using initscripts this should not happen.
If you are using systemd it should. The justification being that /media is meant for ephemeral mount points (i.e. stuff created by udisks et al.).
Wouldn't most users associate /media with cd, dvd etc. ? Seems like on odd name for what systemd uses it for.
cd, dvd, usb sticks, etc are examples of the kind of temporary mount points created by udisks under /media. They are created on insertion and deleted on removal. Hence, there is no need to preserve the contents of /media and having it on tmpfs makes sense. That said, it seems to be agreement among the upstream devs that /media is a broken concept and systemd/udisks will likely introduce a user specific replacement, which will no longer be in the root fs. -t
On Sat, 28 Jan 2012 00:26:38 +0100 "G. Schlisio" <g.schlisio@gmx.de> wrote:
Hi all, i used to keep a folder in /media to serve as mountpoint if some manual mountis was needed. since some days, this folder disappeared, even if created again. is there any change in filesystems, kernel or whatsoever changing behavior there, is it intended (if so, why?) or a bug? every hint appreciated. georg
That is what /mnt is for... Do you have systemd? -- Leonid Isaev GnuPG key ID: 164B5A6D Key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
Am 28.01.2012 00:46, schrieb Leonid Isaev:
On Sat, 28 Jan 2012 00:26:38 +0100 "G. Schlisio"<g.schlisio@gmx.de> wrote:
Hi all, i used to keep a folder in /media to serve as mountpoint if some manual mountis was needed. since some days, this folder disappeared, even if created again. is there any change in filesystems, kernel or whatsoever changing behavior there, is it intended (if so, why?) or a bug? every hint appreciated. georg That is what /mnt is for... Do you have systemd?
jipp, just switched to systemd. so thats why… sometimes i need more than 1 mountpoint, but still you are right. thanks and sorry for the noise.
On Sat, 28 Jan 2012 00:49:03 +0100 "G. Schlisio" <g.schlisio@gmx.de> wrote:
Am 28.01.2012 00:46, schrieb Leonid Isaev:
On Sat, 28 Jan 2012 00:26:38 +0100 "G. Schlisio"<g.schlisio@gmx.de> wrote:
Hi all, i used to keep a folder in /media to serve as mountpoint if some manual mountis was needed. since some days, this folder disappeared, even if created again. is there any change in filesystems, kernel or whatsoever changing behavior there, is it intended (if so, why?) or a bug? every hint appreciated. georg That is what /mnt is for... Do you have systemd?
jipp, just switched to systemd. so thats why… sometimes i need more than 1 mountpoint, but still you are right. thanks and sorry for the noise.
But why can't you create the same dir structure under /mnt? -- Leonid Isaev GnuPG key ID: 164B5A6D Key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
Am 28.01.2012 01:02, schrieb Leonid Isaev:
On Sat, 28 Jan 2012 00:49:03 +0100 "G. Schlisio"<g.schlisio@gmx.de> wrote:
Am 28.01.2012 00:46, schrieb Leonid Isaev:
On Sat, 28 Jan 2012 00:26:38 +0100 "G. Schlisio"<g.schlisio@gmx.de> wrote:
Hi all, i used to keep a folder in /media to serve as mountpoint if some manual mountis was needed. since some days, this folder disappeared, even if created again. is there any change in filesystems, kernel or whatsoever changing behavior there, is it intended (if so, why?) or a bug? every hint appreciated. georg That is what /mnt is for... Do you have systemd?
jipp, just switched to systemd. so thats why… sometimes i need more than 1 mountpoint, but still you are right. thanks and sorry for the noise. But why can't you create the same dir structure under /mnt? i can (an will) of course. until now /media was the place. no problem at all. i just like to understand whats going on, you know…
participants (23)
-
Ben Tartsa
-
Bernardo Barros
-
C Anthony Risinger
-
Fons Adriaensen
-
G. Schlisio
-
Guus Snijders
-
Heiko Baums
-
Jan Steffens
-
Jelle van der Waa
-
Karol Blazewicz
-
Kevin Chadwick
-
Kwpolska
-
Leonid Isaev
-
Martti Kühne
-
Mauro Santos
-
Norbert Zeh
-
Oon-Ee Ng
-
Ralf Mardorf
-
SanskritFritz
-
Stefan Wilkens
-
Thanasis Georgiou
-
Tim Stella
-
Tom Gundersen