[arch-general] polkit package upgrade patch
As it's been marked out-of-date for a while, and I'm interested in it, I've done the work to upgrade the polkit package to 0.107. I've tested this package locally. The main value of this upgrade (for me at least) is systemd integration, including proper systemd-style bus activation. This now wants a dedicated user and group, by default 'polkitd'. I re-used 102, which was listed as 'policykit' in the UID/GID database. Hopefully it really was unused. The build depends on this user and group already being present (otherwise 'make install' fails to chown some directories, and polkitd fails to read them and dies). It now depends on 'js', which I added. Addition of one more 8 MB dep doesn't seem a problem. As we now have pambase, the shipped pam config, which just uses system-auth, is useful to us. I removed the old, locally written, pam file. Let me know if you'd rather I put this patch in the bugtracker.
On Fri, Aug 3, 2012 at 2:01 AM, Ray Kohler <ataraxia937@gmail.com> wrote:
As it's been marked out-of-date for a while, and I'm interested in it, I've done the work to upgrade the polkit package to 0.107. I've tested this package locally. The main value of this upgrade (for me at least) is systemd integration, including proper systemd-style bus activation.
Unfortunately, enabling systemd support removes consolekit support, screwing over everyone not running systemd.
This now wants a dedicated user and group, by default 'polkitd'. I re-used 102, which was listed as 'policykit' in the UID/GID database. Hopefully it really was unused. The build depends on this user and group already being present (otherwise 'make install' fails to chown some directories, and polkitd fails to read them and dies).
Ah, that sucks. Any suggestions on how to handle this when building in clean chroots?
It now depends on 'js', which I added. Addition of one more 8 MB dep doesn't seem a problem.
As we now have pambase, the shipped pam config, which just uses system-auth, is useful to us. I removed the old, locally written, pam file.
Let me know if you'd rather I put this patch in the bugtracker.
On Thu, Aug 2, 2012 at 8:40 PM, Jan Steffens <jan.steffens@gmail.com> wrote:
On Fri, Aug 3, 2012 at 2:01 AM, Ray Kohler <ataraxia937@gmail.com> wrote:
As it's been marked out-of-date for a while, and I'm interested in it, I've done the work to upgrade the polkit package to 0.107. I've tested this package locally. The main value of this upgrade (for me at least) is systemd integration, including proper systemd-style bus activation.
Unfortunately, enabling systemd support removes consolekit support, screwing over everyone not running systemd.
Ah, I didn't know about that. Are you sure that's still the model used here with this upstream support? How would I test? I am running systemd, but I also use consolekit.
This now wants a dedicated user and group, by default 'polkitd'. I re-used 102, which was listed as 'policykit' in the UID/GID database. Hopefully it really was unused. The build depends on this user and group already being present (otherwise 'make install' fails to chown some directories, and polkitd fails to read them and dies).
Ah, that sucks. Any suggestions on how to handle this when building in clean chroots?
I did my builds by building a broken package first (the 'make install' failure doesn't actually cause the build to fail), installing that (which created the user and group), and then building it again (getting a working package this time). Not very satisfactory, and not workable in a build chroot. Possibly it would work to allow the directories to get the wrong owner, and then chown them after make install, using the intended numeric UID/GID directly. Not very safe, as we might have polkitd:polkitd being something other than 102:102 on some systems for some reason.
I also need a newer version of polkit, since the current one (105) broke compatibility with kdeplasma-applets-networkmanagement On Fri, Aug 3, 2012 at 12:05 AM, Ray Kohler <ataraxia937@gmail.com> wrote:
On Thu, Aug 2, 2012 at 8:40 PM, Jan Steffens <jan.steffens@gmail.com> wrote:
On Fri, Aug 3, 2012 at 2:01 AM, Ray Kohler <ataraxia937@gmail.com> wrote:
As it's been marked out-of-date for a while, and I'm interested in it, I've done the work to upgrade the polkit package to 0.107. I've tested this package locally. The main value of this upgrade (for me at least) is systemd integration, including proper systemd-style bus activation.
Unfortunately, enabling systemd support removes consolekit support, screwing over everyone not running systemd.
Ah, I didn't know about that. Are you sure that's still the model used here with this upstream support? How would I test? I am running systemd, but I also use consolekit.
This now wants a dedicated user and group, by default 'polkitd'. I re-used 102, which was listed as 'policykit' in the UID/GID database. Hopefully it really was unused. The build depends on this user and group already being present (otherwise 'make install' fails to chown some directories, and polkitd fails to read them and dies).
Ah, that sucks. Any suggestions on how to handle this when building in clean chroots?
I did my builds by building a broken package first (the 'make install' failure doesn't actually cause the build to fail), installing that (which created the user and group), and then building it again (getting a working package this time). Not very satisfactory, and not workable in a build chroot. Possibly it would work to allow the directories to get the wrong owner, and then chown them after make install, using the intended numeric UID/GID directly. Not very safe, as we might have polkitd:polkitd being something other than 102:102 on some systems for some reason.
-- Martin Código de novios Falabella: 585855-00 (gracias!) No envíen archivos pesados por mail. Usen DropBox <https://www.dropbox.com/referrals/NTIwODk0MDk> (2GB + *500MB bonus*) o SpiderOak<https://spideroak.com/download/referral/dd6b3051b5f1f10a5674d694f22dd3e8>(tras registrarse vayan a 'buy more space' e ingresen el código "worldbackupday" --> *8GB*)
On Aug 6, 2012 7:48 PM, "Martin Zecher" <mzecher@gmail.com> wrote:
I also need a newer version of polkit, since the current one (105) broke compatibility with kdeplasma-applets-networkmanagement
On Fri, Aug 3, 2012 at 12:05 AM, Ray Kohler <ataraxia937@gmail.com> wrote:
On Thu, Aug 2, 2012 at 8:40 PM, Jan Steffens <jan.steffens@gmail.com> wrote:
On Fri, Aug 3, 2012 at 2:01 AM, Ray Kohler <ataraxia937@gmail.com> wrote:
As it's been marked out-of-date for a while, and I'm interested in
it,
I've done the work to upgrade the polkit package to 0.107. I've tested this package locally. The main value of this upgrade (for me at least) is systemd integration, including proper systemd-style bus activation.
Unfortunately, enabling systemd support removes consolekit support, screwing over everyone not running systemd.
Ah, I didn't know about that. Are you sure that's still the model used here with this upstream support? How would I test? I am running systemd, but I also use consolekit.
This now wants a dedicated user and group, by default 'polkitd'. I re-used 102, which was listed as 'policykit' in the UID/GID database. Hopefully it really was unused. The build depends on this user and group already being present (otherwise 'make install' fails to chown some directories, and polkitd fails to read them and dies).
Ah, that sucks. Any suggestions on how to handle this when building in clean chroots?
I did my builds by building a broken package first (the 'make install' failure doesn't actually cause the build to fail), installing that (which created the user and group), and then building it again (getting a working package this time). Not very satisfactory, and not workable in a build chroot. Possibly it would work to allow the directories to get the wrong owner, and then chown them after make install, using the intended numeric UID/GID directly. Not very safe, as we might have polkitd:polkitd being something other than 102:102 on some systems for some reason.
-- Martin
Código de novios Falabella: 585855-00 (gracias!)
No envíen archivos pesados por mail. Usen DropBox <https://www.dropbox.com/referrals/NTIwODk0MDk> (2GB + *500MB bonus*) o SpiderOak< https://spideroak.com/download/referral/dd6b3051b5f1f10a5674d694f22dd3e8 (tras registrarse vayan a 'buy more space' e ingresen el código "worldbackupday" --> *8GB*)
JGC: I have been using the newer polkit locally without problems for some months. Let me know if you want me to push it to testing. Tom
Yes, please! Putting it in testing may solve my issues with networkmanagement applet. On Mon, Aug 6, 2012 at 2:04 PM, Tom Gundersen <teg@jklm.no> wrote:
On Aug 6, 2012 7:48 PM, "Martin Zecher" <mzecher@gmail.com> wrote:
I also need a newer version of polkit, since the current one (105) broke compatibility with kdeplasma-applets-networkmanagement
On Fri, Aug 3, 2012 at 12:05 AM, Ray Kohler <ataraxia937@gmail.com>
wrote:
On Thu, Aug 2, 2012 at 8:40 PM, Jan Steffens <jan.steffens@gmail.com> wrote:
On Fri, Aug 3, 2012 at 2:01 AM, Ray Kohler <ataraxia937@gmail.com> wrote:
As it's been marked out-of-date for a while, and I'm interested in
it,
I've done the work to upgrade the polkit package to 0.107. I've tested this package locally. The main value of this upgrade (for me at least) is systemd integration, including proper systemd-style bus activation.
Unfortunately, enabling systemd support removes consolekit support, screwing over everyone not running systemd.
Ah, I didn't know about that. Are you sure that's still the model used here with this upstream support? How would I test? I am running systemd, but I also use consolekit.
This now wants a dedicated user and group, by default 'polkitd'. I re-used 102, which was listed as 'policykit' in the UID/GID database. Hopefully it really was unused. The build depends on this user and group already being present (otherwise 'make install' fails to chown some directories, and polkitd fails to read them and dies).
Ah, that sucks. Any suggestions on how to handle this when building in clean chroots?
I did my builds by building a broken package first (the 'make install' failure doesn't actually cause the build to fail), installing that (which created the user and group), and then building it again (getting a working package this time). Not very satisfactory, and not workable in a build chroot. Possibly it would work to allow the directories to get the wrong owner, and then chown them after make install, using the intended numeric UID/GID directly. Not very safe, as we might have polkitd:polkitd being something other than 102:102 on some systems for some reason.
-- Martin
Código de novios Falabella: 585855-00 (gracias!)
No envíen archivos pesados por mail. Usen DropBox <https://www.dropbox.com/referrals/NTIwODk0MDk> (2GB + *500MB bonus*) o SpiderOak< https://spideroak.com/download/referral/dd6b3051b5f1f10a5674d694f22dd3e8 (tras registrarse vayan a 'buy more space' e ingresen el código "worldbackupday" --> *8GB*)
JGC: I have been using the newer polkit locally without problems for some months. Let me know if you want me to push it to testing.
Tom
-- Martin Código de novios Falabella: 585855-00 (gracias!) No envíen archivos pesados por mail. Usen DropBox <https://www.dropbox.com/referrals/NTIwODk0MDk> (2GB + *500MB bonus*) o SpiderOak<https://spideroak.com/download/referral/dd6b3051b5f1f10a5674d694f22dd3e8>(tras registrarse vayan a 'buy more space' e ingresen el código "worldbackupday" --> *8GB*)
On Tue, Aug 7, 2012 at 10:59 PM, Martin Zecher <mzecher@gmail.com> wrote:
Yes, please! Putting it in testing may solve my issues with networkmanagement applet.
I didn't put it in testing as I guess it needs some discussion. However, I committed what I have to svn so that everyone can have a look easily, and I uploaded the packages here: <https://dev.archlinux.org/~tomegun/>. This should work on both systemd and non-systemd systems. It would particularly be interesting to get feedback from someone using networkmanger to see if there are issues with the interaction there. -t
On Wed, 2012-08-08 at 00:10 +0200, Tom Gundersen wrote:
On Tue, Aug 7, 2012 at 10:59 PM, Martin Zecher <mzecher@gmail.com> wrote:
Yes, please! Putting it in testing may solve my issues with networkmanagement applet.
I didn't put it in testing as I guess it needs some discussion. However, I committed what I have to svn so that everyone can have a look easily, and I uploaded the packages here: <https://dev.archlinux.org/~tomegun/>.
This should work on both systemd and non-systemd systems. It would particularly be interesting to get feedback from someone using networkmanger to see if there are issues with the interaction there.
-t
Hi I'm not running KDE, but Xfce, with $ pacman -Qi networkmanager Name : networkmanager Version : 0.9.4.0-6 $ pacman -Qi polkit Name : polkit Version : 0.105-1 and I'm nearly Poettering-free, so no PA, no systemd, just some libsystemd or so, regarding to dependencies. $ sudo pacman -U polkit-0.107-1-x86_64.pkg.tar.xz Targets (2): js-1.8.5-3 polkit-0.107-1 *restart* If you receive this mail, then NM still works at the moment with $ pacman -Qi polkit Name : polkit Version : 0.107-1 URL : http://www.freedesktop.org/wiki/Software/PolicyKit Licenses : LGPL Groups : None Provides : None Depends On : glib2 pam expat libsystemd js Optional Deps : None Required By : accountsservice colord consolekit gconf networkmanager polkit-gnome polkit-qt rtkit udisks udisks2 upower Conflicts With : None Replaces : policykit Installed Size : 1812.00 KiB Packager : Tom Gundersen <teg@jklm.no> Architecture : x86_64 Build Date : Tue 07 Aug 2012 11:58:36 PM CEST Install Date : Wed 08 Aug 2012 12:20:46 AM CEST Install Reason : Installed as a dependency for another package Install Script : Yes Description : Application development toolkit for controlling system-wide privileges Hth, Ralf
On Wed, Aug 8, 2012 at 12:26 AM, Ralf Mardorf <ralf.mardorf@alice-dsl.net> wrote:
Hi I'm not running KDE, but Xfce, with
$ pacman -Qi networkmanager Name : networkmanager Version : 0.9.4.0-6 $ pacman -Qi polkit Name : polkit Version : 0.105-1
and I'm nearly Poettering-free, so no PA, no systemd, just some libsystemd or so, regarding to dependencies.
$ sudo pacman -U polkit-0.107-1-x86_64.pkg.tar.xz Targets (2): js-1.8.5-3 polkit-0.107-1
*restart*
If you receive this mail, then NM still works at the moment with
$ pacman -Qi polkit Name : polkit Version : 0.107-1 URL : http://www.freedesktop.org/wiki/Software/PolicyKit Licenses : LGPL Groups : None Provides : None Depends On : glib2 pam expat libsystemd js Optional Deps : None Required By : accountsservice colord consolekit gconf networkmanager polkit-gnome polkit-qt rtkit udisks udisks2 upower Conflicts With : None Replaces : policykit Installed Size : 1812.00 KiB Packager : Tom Gundersen <teg@jklm.no> Architecture : x86_64 Build Date : Tue 07 Aug 2012 11:58:36 PM CEST Install Date : Wed 08 Aug 2012 12:20:46 AM CEST Install Reason : Installed as a dependency for another package Install Script : Yes Description : Application development toolkit for controlling system-wide privileges
That's useful, thanks. -t
On 08/08/2012 01:26 AM, Ralf Mardorf wrote:
On Wed, 2012-08-08 at 00:10 +0200, Tom Gundersen wrote:
On Tue, Aug 7, 2012 at 10:59 PM, Martin Zecher <mzecher@gmail.com> wrote:
Yes, please! Putting it in testing may solve my issues with networkmanagement applet.
I didn't put it in testing as I guess it needs some discussion. However, I committed what I have to svn so that everyone can have a look easily, and I uploaded the packages here: <https://dev.archlinux.org/~tomegun/>.
This should work on both systemd and non-systemd systems. It would particularly be interesting to get feedback from someone using networkmanger to see if there are issues with the interaction there.
-t
Hi I'm not running KDE, but Xfce, with
$ pacman -Qi networkmanager Name : networkmanager Version : 0.9.4.0-6 $ pacman -Qi polkit Name : polkit Version : 0.105-1
Do you also have network-manager-applet? The old polkit console+systemd patch broke the applet not the daemon.
and I'm nearly Poettering-free, so no PA, no systemd, just some libsystemd or so, regarding to dependencies.
$ sudo pacman -U polkit-0.107-1-x86_64.pkg.tar.xz Targets (2): js-1.8.5-3 polkit-0.107-1
*restart*
If you receive this mail, then NM still works at the moment with
$ pacman -Qi polkit Name : polkit Version : 0.107-1 URL : http://www.freedesktop.org/wiki/Software/PolicyKit Licenses : LGPL Groups : None Provides : None Depends On : glib2 pam expat libsystemd js Optional Deps : None Required By : accountsservice colord consolekit gconf networkmanager polkit-gnome polkit-qt rtkit udisks udisks2 upower Conflicts With : None Replaces : policykit Installed Size : 1812.00 KiB Packager : Tom Gundersen <teg@jklm.no> Architecture : x86_64 Build Date : Tue 07 Aug 2012 11:58:36 PM CEST Install Date : Wed 08 Aug 2012 12:20:46 AM CEST Install Reason : Installed as a dependency for another package Install Script : Yes Description : Application development toolkit for controlling system-wide privileges
Hth, Ralf
-- Ionuț
On Wed, 2012-08-08 at 03:33 +0300, Ionut Biru wrote:
Do you also have network-manager-applet? The old polkit console+systemd patch broke the applet not the daemon.
[spinymouse@archlinux ~]$ grep DAEMONS /etc/rc.conf # DAEMONS DAEMONS=(69switch_xorg.conf hwclock syslog-ng !network !netfs crond acpid dbus networkmanager rtirq) [spinymouse@archlinux ~]$ pacman -Qi network-manager-applet Name : network-manager-applet Version : 0.9.4.1-1 URL : http://www.gnome.org/projects/NetworkManager/ Licenses : GPL Groups : None Provides : None Depends On : networkmanager libgnome-keyring polkit-gnome gtk3 libnotify gnome-icon-theme mobile-broadband-provider-info gconf iso-codes Optional Deps : gnome-bluetooth: for PAN/DUN support Required By : None Conflicts With : None Replaces : None Installed Size : 5520.00 KiB Packager : Jan Alexander Steffens (heftig) <jan.steffens@gmail.com> Architecture : x86_64 Build Date : Tue 27 Mar 2012 12:31:46 PM CEST Install Date : Thu 31 May 2012 03:28:01 PM CEST Install Reason : Explicitly installed Install Script : Yes Description : GNOME frontends to NetWorkmanager
On Wed, 2012-08-08 at 02:45 +0200, Ralf Mardorf wrote:
On Wed, 2012-08-08 at 03:33 +0300, Ionut Biru wrote:
Do you also have network-manager-applet? The old polkit console+systemd patch broke the applet not the daemon.
[spinymouse@archlinux ~]$ grep DAEMONS /etc/rc.conf # DAEMONS DAEMONS=(69switch_xorg.conf hwclock syslog-ng !network !netfs crond acpid dbus networkmanager rtirq)
[spinymouse@archlinux ~]$ pacman -Qi network-manager-applet Name : network-manager-applet Version : 0.9.4.1-1 URL : http://www.gnome.org/projects/NetworkManager/ Licenses : GPL Groups : None Provides : None Depends On : networkmanager libgnome-keyring polkit-gnome gtk3 libnotify gnome-icon-theme mobile-broadband-provider-info gconf iso-codes Optional Deps : gnome-bluetooth: for PAN/DUN support Required By : None Conflicts With : None Replaces : None Installed Size : 5520.00 KiB Packager : Jan Alexander Steffens (heftig) <jan.steffens@gmail.com> Architecture : x86_64 Build Date : Tue 27 Mar 2012 12:31:46 PM CEST Install Date : Thu 31 May 2012 03:28:01 PM CEST Install Reason : Explicitly installed Install Script : Yes Description : GNOME frontends to NetWorkmanager
PS: The applet is active in the Xfce panel.
On Tue, Aug 7, 2012 at 6:10 PM, Tom Gundersen <teg@jklm.no> wrote:
On Tue, Aug 7, 2012 at 10:59 PM, Martin Zecher <mzecher@gmail.com> wrote:
Yes, please! Putting it in testing may solve my issues with networkmanagement applet.
I didn't put it in testing as I guess it needs some discussion. However, I committed what I have to svn so that everyone can have a look easily, and I uploaded the packages here: <https://dev.archlinux.org/~tomegun/>.
This should work on both systemd and non-systemd systems. It would particularly be interesting to get feedback from someone using networkmanger to see if there are issues with the interaction there.
This works for me also. I have both logind and consolekit sessions active. I'll note that I had to manually reload the dbus config, as it tries to reload automatically before the install script runs, and chokes on the polkitd user not being known yet.
On 8 August 2012 00:10, Tom Gundersen <teg@jklm.no> wrote:
On Tue, Aug 7, 2012 at 10:59 PM, Martin Zecher <mzecher@gmail.com> wrote:
Yes, please! Putting it in testing may solve my issues with networkmanagement applet.
I didn't put it in testing as I guess it needs some discussion. However, I committed what I have to svn so that everyone can have a look easily, and I uploaded the packages here: <https://dev.archlinux.org/~tomegun/>.
This should work on both systemd and non-systemd systems. It would particularly be interesting to get feedback from someone using networkmanger to see if there are issues with the interaction there.
-t
Works fine here with the "nearly Poettering-free" system. I'm using KDE networkmanager applet. I tested a system-wide wifi connection and it worked fine. Lukas
On Wednesday 08 Aug 2012 09:38:40 Lukas Jirkovsky wrote:
Works fine here with the "nearly Poettering-free" system. I'm using KDE networkmanager applet. I tested a system-wide wifi connection and it worked fine.
Are you able to use KDE without all the Poettering stuff? -- Cheers and Regards Jayesh Badwaik stop html mail | always bottom-post www.asciiribbon.org | www.netmeister.org/news/learn2quote.html
On 08/08/12 10:52, Jayesh Badwaik wrote:
On Wednesday 08 Aug 2012 09:38:40 Lukas Jirkovsky wrote:
Works fine here with the "nearly Poettering-free" system. I'm using KDE networkmanager applet. I tested a system-wide wifi connection and it worked fine.
Are you able to use KDE without all the Poettering stuff?
What if Poettering writes a kernel patch, are you going to stop using linux then? The poettering rants are a bit silly, since multiple devs work on Pulseaudio and Systemd. But back on topic, yes you can run KDE fine without Pulseaudio or Systemd. -- Jelle van der Waa
On Wednesday 08 Aug 2012 11:50:33 Jelle van der Waa wrote:
What if Poettering writes a kernel patch, are you going to stop using linux then? The poettering rants are a bit silly, since multiple devs work on Pulseaudio and Systemd.
But back on topic, yes you can run KDE fine without Pulseaudio or Systemd.
I had a feeling that this might be taken as an anti-Poettering comment, hence I regretted not putting "Poettering" in quotes. I am a user of KDE with complete Pulseaudio setup and I love it for my normal desktop use. My wondering was just an casual curiosity and also, I could find no other keyword in this context which would have got me the answer I wanted. So if someone from systemd and pulseaudio is reading this thread, awesome job people. I like your stuff. -- Cheers and Regards Jayesh Badwaik stop html mail | always bottom-post www.asciiribbon.org | www.netmeister.org/news/learn2quote.html
On 08/08/2012 05:50 AM, Jelle van der Waa wrote:
On 08/08/12 10:52, Jayesh Badwaik wrote:
On Wednesday 08 Aug 2012 09:38:40 Lukas Jirkovsky wrote:
Works fine here with the "nearly Poettering-free" system. I'm using KDE networkmanager applet. I tested a system-wide wifi connection and it worked fine. Are you able to use KDE without all the Poettering stuff?
What if Poettering writes a kernel patch, are you going to stop using linux then? The poettering rants are a bit silly, since multiple devs work on Pulseaudio and Systemd.
But back on topic, yes you can run KDE fine without Pulseaudio or Systemd.
what if one wants a system not unlike a Unix system?
On Wed, Aug 8, 2012 at 2:25 PM, Baho Utot <baho-utot@columbus.rr.com> wrote:
what if one wants a system not unlike a Unix system?
Might be too late, but you could try contacting: <http://sco.com/>. -t
On 08/08/2012 08:30 AM, Tom Gundersen wrote:
On Wed, Aug 8, 2012 at 2:25 PM, Baho Utot <baho-utot@columbus.rr.com> wrote:
what if one wants a system not unlike a Unix system? Might be too late, but you could try contacting: <http://sco.com/>.
-t
They just filed chapter7 Maybe I can pick up a bargin
Thanks a lot for the package, but unfortunately I'm still experiencing this bug: https://bbs.archlinux.org/viewtopic.php?id=144763 https://bugs.gentoo.org/show_bug.cgi?id=421577 Because of the rules posted in gentoo's bugs, I thought I could fix this annoyance with polkit 107 but wasn't the case. I guess I'll have to wait for a networkmanager update then. On Wed, Aug 8, 2012 at 8:37 AM, Baho Utot <baho-utot@columbus.rr.com> wrote:
On 08/08/2012 08:30 AM, Tom Gundersen wrote:
On Wed, Aug 8, 2012 at 2:25 PM, Baho Utot <baho-utot@columbus.rr.com> wrote:
what if one wants a system not unlike a Unix system?
Might be too late, but you could try contacting: <http://sco.com/>.
-t
They just filed chapter7
Maybe I can pick up a bargin
-- Martin Código de novios Falabella: 585855-00 (gracias!) No envíen archivos pesados por mail. Usen DropBox <https://www.dropbox.com/referrals/NTIwODk0MDk> (2GB + *500MB bonus*) o SpiderOak<https://spideroak.com/download/referral/dd6b3051b5f1f10a5674d694f22dd3e8>(tras registrarse vayan a 'buy more space' e ingresen el código "worldbackupday" --> *8GB*)
Long-term report: The NM applet within the Xfce panel still is ok. I expect to get issues from time to time using NM, but until now even those didn't happen. Again, no systemd ;). OT: Btw. it would be nice if everybody has got the choice to use or not to use systemd. IMO there's no need to talk about pros and cons, Poettering again and again. I suspect we use different mail clients, daemons etc. too.
On 08/10/2012 08:11 AM, Ralf Mardorf wrote:
OT: Btw. it would be nice if everybody has got the choice to use or not to use systemd. IMO there's no need to talk about pros and cons, Poettering again and again. I suspect we use different mail clients, daemons etc. too.
Sadly, I don't think in the long run that will be possible, given that systemd has taken over udev and udev is now a part of systemd. In April 2012, udev's source tree was merged into systemd.
On Fri, Aug 10, 2012 at 2:47 PM, Baho Utot <baho-utot@columbus.rr.com> wrote:
On 08/10/2012 08:11 AM, Ralf Mardorf wrote:
OT: Btw. it would be nice if everybody has got the choice to use or not to use systemd. IMO there's no need to talk about pros and cons, Poettering again and again. I suspect we use different mail clients, daemons etc. too.
Sadly, I don't think in the long run that will be possible, given that systemd has taken over udev and udev is now a part of systemd.
In April 2012, udev's source tree was merged into systemd.
That's not a problem. We currently use udev from the sysntemd-tools package with initsrcipts (as well as many other tools that systemd provides), and I do not expect this to cause problems anytime soon. The only issue I see with supporting more than one init system is that it means more work for the packagers. -t
On 08/10/2012 08:54 AM, Tom Gundersen wrote:
On 08/10/2012 08:11 AM, Ralf Mardorf wrote:
OT: Btw. it would be nice if everybody has got the choice to use or not to use systemd. IMO there's no need to talk about pros and cons, Poettering again and again. I suspect we use different mail clients, daemons etc. too.
Sadly, I don't think in the long run that will be possible, given that systemd has taken over udev and udev is now a part of systemd.
In April 2012, udev's source tree was merged into systemd. That's not a problem. We currently use udev from the sysntemd-tools
On Fri, Aug 10, 2012 at 2:47 PM, Baho Utot <baho-utot@columbus.rr.com> wrote: package with initsrcipts (as well as many other tools that systemd provides), and I do not expect this to cause problems anytime soon.
The only issue I see with supporting more than one init system is that it means more work for the packagers.
-t
Yes but part of systemd is installed with udev as I understand it? Have you tried to strip out udev from systemd so you can use sysvinit without anything from systemd ?
On Fri, Aug 10, 2012 at 3:05 PM, Baho Utot <baho-utot@columbus.rr.com> wrote:
Yes but part of systemd is installed with udev as I understand it?
Have you tried to strip out udev from systemd so you can use sysvinit without anything from systemd ?
The systemd daemon is not installed. However, lots of little tools are (look in /usr/lib/systemd/systemd-*), including udev. Udev would work without any of the other tools, but initscripts use them all, so removing them would not be a good idea. -t
On Fri, 2012-08-10 at 08:47 -0400, Baho Utot wrote:
On 08/10/2012 08:11 AM, Ralf Mardorf wrote:
OT: Btw. it would be nice if everybody has got the choice to use or not to use systemd. IMO there's no need to talk about pros and cons, Poettering again and again. I suspect we use different mail clients, daemons etc. too.
Sadly, I don't think in the long run that will be possible, given that systemd has taken over udev and udev is now a part of systemd.
In April 2012, udev's source tree was merged into systemd.
At the moment it is possible :). Once systemd should work for everybody, it would be ok to switch. I just hope there will be no switch until systemd could cause issues. I'm very pissed about how PA was hammered in Linux. It has broken many working systems and many people testing Linux for the first time, directly throw Linux away, since nobody likes a default install with broken audio. PA until today is pure crap for MOST computer users (including those who try to switch to Linux), I don't like to hear again and again, that it does work for most Linux users, I even DOUBT that very much.
On 10 Aug 2012 22:52, "Ralf Mardorf" <ralf.mardorf@alice-dsl.net> wrote:
. PA until today is pure crap for MOST computer users (including those who try to switch to Linux), I don't like to hear again and again, that it does work for most Linux users, I even DOUBT that very much.
This again? Let's paraphrase:- Software X sucks for most users, since I've personally read 3 million separate user complaints. Don't tell me I'm wrong because I know I'm not. I don't care that all the biggest distros use software X, their users obviously don't play music. Oh, and very few people actually use simple stereo audio chips, the majority of people use multi channel audio cards to listen to their YouTube. Copy, paste, on all the mailing lists I frequent. Do you have any idea how ridiculous this sounds, after a while?
On Fri, 2012-08-10 at 23:50 +0800, Oon-Ee Ng wrote:
On 10 Aug 2012 22:52, "Ralf Mardorf" <ralf.mardorf@alice-dsl.net> wrote:
. PA until today is pure crap for MOST computer users (including those who try to switch to Linux), I don't like to hear again and again, that it does work for most Linux users, I even DOUBT that very much.
This again? Let's paraphrase:- Software X sucks for most users, since I've personally read 3 million separate user complaints. Don't tell me I'm wrong because I know I'm not. I don't care that all the biggest distros use software X, their users obviously don't play music. Oh, and very few people actually use simple stereo audio chips, the majority of people use multi channel audio cards to listen to their YouTube.
Copy, paste, on all the mailing lists I frequent.
Do you have any idea how ridiculous this sounds, after a while?
I tried to avoid this OT, apologize. I always forget that Linux is the most used OS in the universe and that I'm the only one who isn't fine with some rulings. However, the topic is "polkit package upgrade patch". As already reported, both, the version from the repositories + this patched version works with the NM applet on my Xfce, unfortunately the patched version brakes Thunar.
On Aug 10, 2012 5:59 PM, "Ralf Mardorf" <ralf.mardorf@alice-dsl.net> wrote:
As already reported, both, the version from the repositories + this patched version works with the NM applet on my Xfce, unfortunately the patched version brakes Thunar.
Thanks. Tom
On Fri, 10 Aug 2012 18:04:39 +0200 Tom Gundersen <teg@jklm.no> wrote:
On Aug 10, 2012 5:59 PM, "Ralf Mardorf" <ralf.mardorf@alice-dsl.net> wrote:
As already reported, both, the version from the repositories + this patched version works with the NM applet on my Xfce, unfortunately the patched version brakes Thunar.
Thanks.
Tom
Except mounting issues, do I correctly understand that polkit 0.107 enables correct seat/session assigment in conjuction with systemd-logind even without a login helper (like {G,K}DM)? Thanks. -- Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
On Aug 10, 2012 6:32 PM, "Leonid Isaev" <lisaev@umail.iu.edu> wrote:
On Fri, 10 Aug 2012 18:04:39 +0200 Tom Gundersen <teg@jklm.no> wrote:
On Aug 10, 2012 5:59 PM, "Ralf Mardorf" <ralf.mardorf@alice-dsl.net>
wrote:
As already reported, both, the version from the repositories + this patched version works with the NM applet on my Xfce, unfortunately the patched version brakes Thunar.
Thanks.
Tom
Except mounting issues, do I correctly understand that polkit 0.107 enables correct seat/session assigment in conjuction with systemd-logind even without a login helper (like {G,K}DM)?
No. That is a separate problem. The patched version will ask logind for information about the session, but for that to work, a pam session must have been set up correctly and be registered with logind. For this a login manager (our an xinit hack) is needed. Tom
On Fri, 2012-08-10 at 11:31 -0500, Leonid Isaev wrote:
On Fri, 10 Aug 2012 18:04:39 +0200 Tom Gundersen <teg@jklm.no> wrote:
On Aug 10, 2012 5:59 PM, "Ralf Mardorf" <ralf.mardorf@alice-dsl.net> wrote:
As already reported, both, the version from the repositories + this patched version works with the NM applet on my Xfce, unfortunately the patched version brakes Thunar.
Thanks.
Tom
Except mounting issues, do I correctly understand that polkit 0.107 enables correct seat/session assigment in conjuction with systemd-logind even without a login helper (like {G,K}DM)?
Thanks.
No, I'm not using systemd-logind, but $ pacman -Qi gdm Name : gdm Version : 3.4.1-2 $ ls /etc/systemd/logind.conf ls: cannot access /etc/systemd/logind.conf: No such file or directory Yes, GDM for starting Xfce, while not using PA, perhaps a strange combination. Regards, Ralf
On 08/10/2012 11:50 AM, Oon-Ee Ng wrote:
On 10 Aug 2012 22:52, "Ralf Mardorf" <ralf.mardorf@alice-dsl.net> wrote:
. PA until today is pure crap for MOST computer users (including those who try to switch to Linux), I don't like to hear again and again, that it does work for most Linux users, I even DOUBT that very much.
This again? Let's paraphrase:- Software X sucks for most users, since I've personally read 3 million separate user complaints. Don't tell me I'm wrong because I know I'm not. I don't care that all the biggest distros use software X, their users obviously don't play music. Oh, and very few people actually use simple stereo audio chips, the majority of people use multi channel audio cards to listen to their YouTube.
Copy, paste, on all the mailing lists I frequent.
Do you have any idea how ridiculous this sounds, after a while? I don't wish to get into that particular disagreement but......
pulse audio doesn't work for me in the two boxen I have it on. It just gets in the way and when it is removed I can set my audio just how I want it. With pulse it just takes over the master volume when it try to adjust audio in an application cranking the master volume to full. Without pulse it just works the way I like it to be. So count me as one of the ones who doesn't like pulse audio.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/10/2012 09:02 AM, Baho Utot wrote:
On 08/10/2012 11:50 AM, Oon-Ee Ng wrote:
On 10 Aug 2012 22:52, "Ralf Mardorf" <ralf.mardorf@alice-dsl.net> wrote:
. PA until today is pure crap for MOST computer users (including those who try to switch to Linux), I don't like to hear again and again, that it does work for most Linux users, I even DOUBT that very much.
This again? Let's paraphrase:-
<snip>
Copy, paste, on all the mailing lists I frequent.
Perhaps the fact that so many people--myself included--have had problems with PulseAudio that are most easily solved by removing PulseAudio ought to be taken into consideration. But PulseAudio evangelists rarely, if ever, respond meaningfully to this point. That suggests that the attachment to PulseAudio is based in emotion rather than in reason. Emotion is a legitimate basis for decisionmaking. But it is also legitimate for others to choose what works for them.
Do you have any idea how ridiculous this sounds, after a while?
I don't wish to get into that particular disagreement but......
pulse audio doesn't work for me in the two boxen I have it on. It just gets in the way and when it is removed I can set my audio just how I want it.
It's interesting that there is so much evangelism for PulseAudio. If it really worked as advertised, 1) such evangelism would not be necessary, and 2) the topic might not come up so often. But what's really interesting is that the topic appears even here on an Arch mailing list, since Arch--as far as I know--wouldn't foist PulseAudio on anybody unless they wanted it. - -- David Benfell benfell@parts-unknown.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQJX3FAAoJELT202JKF+xpLRgP/jA788xHe6kTka8WnDQW6W+e HD/8o3xeIdJA2sSh8wjDS7jqvacd8yp5sHZNa7P1r5AcOfx4paUniitvNaBfLmhC yY2MfsSM/iLIzgTWOWbKZNBSFt8uxPd52oD2JyEgS9l9dRPl13DSlRy9ZC2+94Kt TdAg7sL+23DTtFhLsa2z54rlglwGblo41QaEp8MMPUcy1HpaFKcwpEw9TSVKD71D WPo7JVQZF3y8eOtNEaRzHZKYOaTmoqarn32VR26jp4Dw9Wzr3OWpCgYIkRwR+2eI rjsdYVFasMs+BbKjafl6hTVH9ky1INgmXcYBpDGQrim3qCEWVlLcw3PAyKMnXpet g4SHT4owYqrWfTABVaTcHX+C6BjIVoNMOjdN78gHVBqPcaO4QevdDKp6cFeu90b1 bQ3C/YYHev+A8KLCv02bbwTws0uKtcS/AbaSgBjNXRV45RNZ+myzDDNqMtH5z6DM lZC+ywkNZlHW3mFqsBOfrQq2KjwUW2/F6JoIvvX+7PspFXxP7B+s1djKHL7i2VVU 5t+g/EJFxgn4DxTUxa6qOheJEBntqUUj5whNNVHJ5+XMnba/iVs6HMhrfQKsDZCJ QkClneV14dkuvtS//X+PCJ4qXkcA0096hNwk6QI7bL4gMHZaEjcctK1XRybL1bs7 ppoIXsSYeEWd8kiWkM3T =a0+y -----END PGP SIGNATURE-----
On Fri, Aug 10, 2012 at 12:02:50PM -0400, Baho Utot wrote:
With pulse it just takes over the master volume when it try to adjust audio in an application cranking the master volume to full. Without pulse it just works the way I like it to be. So count me as one of the ones who doesn't like pulse audio.
:-) Give anyone who's not an audio engineer two volume controls in series and the result will be either noise & interference or distortion or both. So imagine the average desktop user who gets five or so of them: - one provided by the application (player or something) - one provided by PA or similar, - probably two by the soundcard mixer, - and finally one on his/her cheap 'multimedia speakers'. The first and second ones will be digital, unless one of them tries to control the soundcard mixer. The soundcard mixer controls could be digital or analog or an undocumented mix of both. The last one is probably analog. The probability of getting any decent sound out of such a mess is smallish. Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)
On Sun, Aug 12, 2012 at 12:03 AM, Fons Adriaensen <fons@linuxaudio.org> wrote:
So imagine the average desktop user who gets five or so of them:
- one provided by the application (player or something) - one provided by PA or similar, - probably two by the soundcard mixer,
PA combines these three into one. So the non-audio-engineer user should have a lot bigger chance of not messing things up with PA compared to with pure ALSA (where you do have to fiddle with all the mixers and the application mixer on top). Sorry if this was what you were trying to point out. -t
On Sun, Aug 12, 2012 at 12:15:14AM +0200, Tom Gundersen wrote:
On Sun, Aug 12, 2012 at 12:03 AM, Fons Adriaensen <fons@linuxaudio.org> wrote:
So imagine the average desktop user who gets five or so of them:
- one provided by the application (player or something) - one provided by PA or similar, - probably two by the soundcard mixer,
PA combines these three into one. So the non-audio-engineer user should have a lot bigger chance of not messing things up with PA compared to with pure ALSA (where you do have to fiddle with all the mixers and the application mixer on top). Sorry if this was what you were trying to point out.
Obviously you're not a sound engineer, or you would know that is pure nonsense. First, PA has no visibility on whatever internal volume control an app provides. It just doesn't know about it. All it gets is the output from the app. Second, PA has no way to know how to correctly use the soundcard controls, or even to know what exactly they control and how they do it. On some cards the 'master' is digital scaling before the D/A converter. On some others it controls an analog gain stage after the converter. The correct way to use those is completely different. Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)
On Sun, Aug 12, 2012 at 12:31 AM, Fons Adriaensen <fons@linuxaudio.org> wrote:
First, PA has no visibility on whatever internal volume control an app provides. It just doesn't know about it. All it gets is the output from the app.
This is not correct. If the app has proper PA support (such as all KDE apps, and probably all gnome apps), then PA does the app specific mixing, not the app itself. Moreover, if only one app is playing sound then PA does no mixing at all, but passes it all directly to ALSA (and sets ALSA's controls of course).
Second, PA has no way to know how to correctly use the soundcard controls, or even to know what exactly they control and how they do it. On some cards the 'master' is digital scaling before the D/A converter. On some others it controls an analog gain stage after the converter. The correct way to use those is completely different.
If I understand correctly ALSA provides lots of meta-information about the controllers to PA. Before PA this meta information was ignored, and it is due to bugs in that that PA had a bad reputation in the beginning. PA has heuristics to try to do the best it can with the information provided to it. Are you saying that an unqualified user is likely to get a better result than these heuristics? It seems that what you are saying should mean that ALAS is clearly not good enough, and that we need something more, such as PA to deal with getting the mixing right, as it is too hard for users. -t
On Sun, Aug 12, 2012 at 12:41:24AM +0200, Tom Gundersen wrote:
On Sun, Aug 12, 2012 at 12:31 AM, Fons Adriaensen <fons@linuxaudio.org> wrote:
First, PA has no visibility on whatever internal volume control an app provides. It just doesn't know about it. All it gets is the output from the app.
This is not correct. If the app has proper PA support (such as all KDE apps, and probably all gnome apps), then PA does the app specific mixing, not the app itself.
That doesn't stop the app from having its own internal volume control that PA doesn't know about.
Moreover, if only one app is playing sound then PA does no mixing at all, but passes it all directly to ALSA (and sets ALSA's controls of course).
If that is true it is completely wrong from the start. Because that setup can't be maintained when a second app starts playing which can happen at any time. Suppose that first (single) app has its volume set to some low value, and PA uses the soundcard PCM gain control to achieve that as you claim it does. Now suddenly there's a second app which wants a higher level. The only way to achieve that is to raise the hardware gain - you can't compensate for a low setting there by sending a louder signal, it would just clip. So PA now has to adjust the hardware gain and at the same time start scaling down the output from the first app. It's impossible to do that in any acceptable way. Simple fact is that most soundcards, even if they have a 'mixer', can't mix PCM signals (i.e. signals from the software) - they can mix in a CD player, or an external mic input etc.). So for anything coming from the system there is just one path, which has two controls, the 'PCM' and the 'master'. The only way to correctly use them if there if there is software mixing is to set them once to their correct values (which may depend on what is connected externally), and them leave them alone and do the rest in software. And then we haven't even touched the matter of different sample rates.
Second, PA has no way to know how to correctly use the soundcard controls, or even to know what exactly they control and how they do it. On some cards the 'master' is digital scaling before the D/A converter. On some others it controls an analog gain stage after the converter. The correct way to use those is completely different.
If I understand correctly ALSA provides lots of meta-information about the controllers to PA. Before PA this meta information was ignored, and it is due to bugs in that that PA had a bad reputation in the beginning.
'A lot of meta-information' LOL. It will provide some usually meaningless and inconsistent names of controls, their min and max values, and if you're extremely lucky maybe some indication mapping control values to dB, which may or may not be correct (and if it isn't that's not ALSA's fault, it just crappy and undocumented harware). All of that is visible in alsamixer.
PA has heuristics to try to do the best it can with the information provided to it. Are you saying that an unqualified user is likely to get a better result than these heuristics?
Yes, absolutely. It may take the user some time to understand the quirks of his soundcard (such as that it's not capable of outputting full digital level without distortion, no matter how the controls are set, or even crappier shortcomings). But he will usually find a way to get things working. Which is impossible without hearing the result. Maybe PA has some magic powers to do that. Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)
On Sun, Aug 12, 2012 at 1:23 AM, Fons Adriaensen <fons@linuxaudio.org> wrote:
If that is true it is completely wrong from the start. Because that setup can't be maintained when a second app starts playing which can happen at any time. Suppose that first (single) app has its volume set to some low value, and PA uses the soundcard PCM gain control to achieve that as you claim it does. Now suddenly there's a second app which wants a higher level. The only way to achieve that is to raise the hardware gain - you can't compensate for a low setting there by sending a louder signal, it would just clip. So PA now has to adjust the hardware gain and at the same time start scaling down the output from the first app. It's impossible to do that in any acceptable way.
Yet that's exactly what it does. And on my system (HDAudio) I have not noticed any changes in the volume of the first stream, even as the "Master" mixer control jumped levels. Maybe ask the devs for details.
On Sun, Aug 12, 2012 at 01:41:01AM +0200, Jan Steffens wrote:
On Sun, Aug 12, 2012 at 1:23 AM, Fons Adriaensen <fons@linuxaudio.org> wrote:
If that is true it is completely wrong from the start. Because that setup can't be maintained when a second app starts playing which can happen at any time. Suppose that first (single) app has its volume set to some low value, and PA uses the soundcard PCM gain control to achieve that as you claim it does. Now suddenly there's a second app which wants a higher level. The only way to achieve that is to raise the hardware gain - you can't compensate for a low setting there by sending a louder signal, it would just clip. So PA now has to adjust the hardware gain and at the same time start scaling down the output from the first app. It's impossible to do that in any acceptable way.
Yet that's exactly what it does. And on my system (HDAudio) I have not noticed any changes in the volume of the first stream, even as the "Master" mixer control jumped levels.
This is completely sick. Any audio engineer trying to use a mixer that way would (and should) be fired for gross incompetence - immediately. Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)
On Sun, Aug 12, 2012 at 2:05 AM, Fons Adriaensen <fons@linuxaudio.org> wrote:
This is completely sick. Any audio engineer trying to use a mixer that way would (and should) be fired for gross incompetence - immediately.
Argument by authority, nice. Care to elaborate? (Sorry to anyone who is sick of PA, but for once I'm seeing the chance to learn something from one of these threads ;-)). If the problem is too complex to explain in layman terms, that's understandable. However, is the problem one that would be unacceptable in a professional setting (e.g. a recording studio, ...) as it would cause subtle issues. Or is it a problem that I should be able to observe on my crappy speakers at home? If so, what am I listening for? How would I go about reproducing it? Cheers, Tom
On 12 August 2012 02:47, Tom Gundersen <teg@jklm.no> wrote:
On Sun, Aug 12, 2012 at 2:05 AM, Fons Adriaensen <fons@linuxaudio.org> wrote:
This is completely sick. Any audio engineer trying to use a mixer that way would (and should) be fired for gross incompetence - immediately.
Argument by authority, nice. Care to elaborate? (Sorry to anyone who is sick of PA, but for once I'm seeing the chance to learn something from one of these threads ;-)).
If the problem is too complex to explain in layman terms, that's understandable. However, is the problem one that would be unacceptable in a professional setting (e.g. a recording studio, ...) as it would cause subtle issues. Or is it a problem that I should be able to observe on my crappy speakers at home? If so, what am I listening for? How would I go about reproducing it?
Cheers,
Tom
One of my friends is an amateur musician. He told me about some problems that makes PA unusable for his work. First, it is having unpredictable latencies and size of buffers. And the second one was similar to the question – it was having one master channels instead of many mixers provided by card. I don't remember the exact reasons why it was bad though. I think it has something to do with small changes in the audio signal that may be raised by the connected equipment. Lukas
On Sun, Aug 12, 2012 at 02:47:59AM +0200, Tom Gundersen wrote:
Argument by authority, nice. Care to elaborate? (Sorry to anyone who is sick of PA, but for once I'm seeing the chance to learn something from one of these threads ;-)).
No authority needed here, it's just extremely clumsy to use a mixer that way, you'd need ten hands. For it means that whenever you want to adjust a single channnel you may have to adjust *all* others and the master at the same time.
If the problem is too complex to explain in layman terms, that's understandable. However, is the problem one that would be unacceptable in a professional setting (e.g. a recording studio, ...) as it would cause subtle issues. Or is it a problem that I should be able to observe on my crappy speakers at home? If so, what am I listening for? How would I go about reproducing it?
[1] The first and sufficient argument is that is completely *unnecessary* to do such things. Assume you have two or more apps producing sound, and one of them (A) has its volume set to max, so PA will set the master fader to max. Assume things are OK that way (which will probably be the case). Things will still work well when (A) happens to contribute nothing (i.e. while it outputs silence). So things will still work well when (A) isn't there at all. *There is no need to change anything at all* when (A) goes away, even if all others have their volume set to lower values. [2] As to technical arguments, I can try. First thing to know is that you shouldn't confuse 'level' (a property of signal), and 'gain' (the ratio of two levels, or difference if you think in dB). Both are usually expressed in dB, but that doesn't make them the same thing. Compare it to time: a instant (epoch) and a duration are both expressed in the same units but they are different things. For example the sum of two epochs doesn't have any meaning, while the sum of two durations has. And if some activity has a duration of 40 minutes, that doesn't mean it has to finish at 00:40. Similarly, if an apps has its gain set to -10 dB, that should not be taken to imply that it can't output more than -10 dB. On 'real' mixers (digital or analog) you normally have considerable 'headroom'. Setting your master fader to -20 dB does not mean you can't output more than -20 dB. For digital ones that means that they use internally a wider format (more bits) than on the external interfaces. So you can actually trade off input gains and master gain to some extent. Soundcard mixers are different. The PCM input to the mixer (i.e. the samples the SW provides) usually has the same format as the AD converter, e.g. 16 or 24 bits. That means that if the master is set to e.g. -20 dB, the card can't output any signal that is larger than -20 dB (w.r.t. its normal maximum level). Which is wrong. Assume you have two or more apps, all of them have their volume set to -20 dB. So PA will set the master output to -20 dB. Now even if all of these apps are limited to contributing -20 dB (but there is no reason why that should be), the sum of them can be higher, but your soundcard can't handle that. It all amounts to this: unless the user is using the soundcard's 'master' as his global volume control (similar to a volume knob on an external amplifier) it should be left at 0 dB. No software layer should ever touch it. [3] On many soundcards the master fader also controls the level of things that PA or any software layer doesn't know about, e.g. and external mic input. Which you'd use for karaoke, or to hear yourself in your headphones while skyping. That level must not depend on how other apps set their volume controls. Again the software should not touch the master gain. [4] You can't apply a soundcard mixer gain change at some exact point in a sample stream. So you can't change the master gain and change your internal scaling to compensate at exactly the same time. There will always be a glitch. -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)
On Sun, 2012-08-12 at 13:07 +0000, Fons Adriaensen wrote:
[4]
You can't apply a soundcard mixer gain change at some exact point in a sample stream. So you can't change the master gain and change your internal scaling to compensate at exactly the same time. There will always be a glitch.
That's the important point. And because look ahead for a realtime livestream is impossible without a time machine, you need to lower the level with a guess about the needed headroom, before you increase the other level, assumed we are near at margin of full scale.
On Sun, 2012-08-12 at 15:27 +0200, Ralf Mardorf wrote:
On Sun, 2012-08-12 at 13:07 +0000, Fons Adriaensen wrote:
[4]
You can't apply a soundcard mixer gain change at some exact point in a sample stream. So you can't change the master gain and change your internal scaling to compensate at exactly the same time. There will always be a glitch.
That's the important point. And because look ahead for a realtime livestream is impossible without a time machine, you need to lower the level with a guess about the needed headroom, before you increase the other level, assumed we are near at margin of full scale.
Or is it possible for software to be that fast, that it doesn't matter? Perhaps a look ahead is possible?
On Sun, 2012-08-12 at 15:31 +0200, Ralf Mardorf wrote:
On Sun, 2012-08-12 at 15:27 +0200, Ralf Mardorf wrote:
On Sun, 2012-08-12 at 13:07 +0000, Fons Adriaensen wrote:
[4]
You can't apply a soundcard mixer gain change at some exact point in a sample stream. So you can't change the master gain and change your internal scaling to compensate at exactly the same time. There will always be a glitch.
That's the important point. And because look ahead for a realtime livestream is impossible without a time machine, you need to lower the level with a guess about the needed headroom, before you increase the other level, assumed we are near at margin of full scale.
Or is it possible for software to be that fast, that it doesn't matter? Perhaps a look ahead is possible?
I know it anyway would cause a glitch, but perhaps that the volume can't be set at an exact point is for consumer usage quasi inaudible?
On Sun, Aug 12, 2012 at 3:07 PM, Fons Adriaensen <fons@linuxaudio.org> wrote:
it's just extremely clumsy to use a mixer that way, you'd need ten hands. For it means that whenever you want to adjust a single channnel you may have to adjust *all* others and the master at the same time.
Unlike humans, computers does not have a limited number of hands. This is not a priori a problem.
[1]
The first and sufficient argument is that is completely *unnecessary* to do such things.
Assume you have two or more apps producing sound, and one of them (A) has its volume set to max, so PA will set the master fader to max. Assume things are OK that way (which will probably be the case).
Things will still work well when (A) happens to contribute nothing (i.e. while it outputs silence). So things will still work well when (A) isn't there at all. *There is no need to change anything at all* when (A) goes away, even if all others have their volume set to lower values.
You have showed that it is unnecessary in one particular (very simple) case. However, you have not showed that it is unnecessary in all cases, so this is not really relevant (had we been talking about a human doing this, you'd have a point of course).
[2]
As to technical arguments, I can try. First thing to know is that you shouldn't confuse 'level' (a property of signal), and 'gain' (the ratio of two levels, or difference if you think in dB). Both are usually expressed in dB, but that doesn't make them the same thing. Compare it to time: a instant (epoch) and a duration are both expressed in the same units but they are different things. For example the sum of two epochs doesn't have any meaning, while the sum of two durations has. And if some activity has a duration of 40 minutes, that doesn't mean it has to finish at 00:40.
Similarly, if an apps has its gain set to -10 dB, that should not be taken to imply that it can't output more than -10 dB.
On 'real' mixers (digital or analog) you normally have considerable 'headroom'. Setting your master fader to -20 dB does not mean you can't output more than -20 dB. For digital ones that means that they use internally a wider format (more bits) than on the external interfaces. So you can actually trade off input gains and master gain to some extent.
Soundcard mixers are different. The PCM input to the mixer (i.e. the samples the SW provides) usually has the same format as the AD converter, e.g. 16 or 24 bits. That means that if the master is set to e.g. -20 dB, the card can't output any signal that is larger than -20 dB (w.r.t. its normal maximum level). Which is wrong. Assume you have two or more apps, all of them have their volume set to -20 dB.
This all makes sense. Thanks.
So PA will set the master output to -20 dB. Now even if all of these apps are limited to contributing -20 dB (but there is no reason why that should be), the sum of them can be higher, but your soundcard can't handle that.
That clearly would not work. Surely PA would need to adjust the master output to compensate for the number of channels? I don't know these implementation details, but I don't see how your arguments shows that this is impossible in general, just that the algorithm you outlined does not work.
[3]
On many soundcards the master fader also controls the level of things that PA or any software layer doesn't know about, e.g. and external mic input. Which you'd use for karaoke, or to hear yourself in your headphones while skyping. That level must not depend on how other apps set their volume controls. Again the software should not touch the master gain.
On soundcards where this is the case, then clearly this must be taken into account. However, that is not impossible. Either the information is given by ALSA, or a quirks table is needed. That does not mean that the general approach cannot work.
[4]
You can't apply a soundcard mixer gain change at some exact point in a sample stream. So you can't change the master gain and change your internal scaling to compensate at exactly the same time. There will always be a glitch.
Ok. This is what I was wondering about. I will try to listen for glitches then (I have not noticed any during my years of using PA, but I'll pay more attention). If it is true that a noticeable glitch is produced, then obviously you have a point, however if the glitch is not noticeable then I don't see the problem you have with PA. Clearly, PA is not meant for professional audio work. And it might be that for a professional all the PA logic is both unnecessary and maybe even detrimental (so you'd use jack or pure ALSA instead, that should not be a problem). However, that does not mean that PA is not a huge gain for the casual desktop user (assuming there are no bugs!). Thanks for the information. Tom
On Sun, 2012-08-12 at 16:00 +0200, Tom Gundersen wrote:
Ok. This is what I was wondering about. I will try to listen for glitches then (I have not noticed any during my years of using PA, but I'll pay more attention). If it is true that a noticeable glitch is produced, then obviously you have a point, however if the glitch is not noticeable then I don't see the problem you have with PA.
Clearly, PA is not meant for professional audio work. And it might be that for a professional all the PA logic is both unnecessary and maybe even detrimental (so you'd use jack or pure ALSA instead, that should not be a problem). However, that does not mean that PA is not a huge gain for the casual desktop user (assuming there are no bugs!).
Thanks for the information.
I was a pro analog audio engineer, working for an important company. I tried some stupid guesses, regarding to nowadays digital. IMO it's imaginable, even if some of my thoughts should be absolutely wrong, that for consumer usage, there "quasi" aren't audible steps. Anyway, PA isn't needed, so it should be an optional dependency. And it might work or not, the way it's done is insane. Analog audio engineers only have got two hands + flying faders :D, anyway, Fon's claim that it's sick, not sane or what ever he said is correct. There is a logical way to do such stuff with two hands only, without flying faders. Why should software not use this better style too? 2 cents, Ralf
On Sun, Aug 12, 2012 at 04:00:47PM +0200, Tom Gundersen wrote:
On Sun, Aug 12, 2012 at 3:07 PM, Fons Adriaensen <fons@linuxaudio.org> wrote:
it's just extremely clumsy to use a mixer that way, you'd need ten hands. For it means that whenever you want to adjust a single channnel you may have to adjust *all* others and the master at the same time.
Unlike humans, computers does not have a limited number of hands. This is not a priori a problem.
It's still like trying to start a 10-ton truck in 5th gear. If you do that on your first day on the job you'll be fired, not because your boss likes to show his authority but because you have shown your incompetence. And if a computerized system tries to do that (and maybe it could if it has very fine control over the engine and clutch) then there's clearly something wrong with it.
Things will still work well when (A) happens to contribute nothing (i.e. while it outputs silence). So things will still work well when (A) isn't there at all. *There is no need to change anything at all* when (A) goes away, even if all others have their volume set to lower values.
You have showed that it is unnecessary in one particular (very simple) case. However, you have not showed that it is unnecessary in all cases, so this is not really relevant (had we been talking about a human doing this, you'd have a point of course).
It is never necessary. It it were that would imply that a sound card without any gain controls (equivalent to a fixed 0 dB gain) would fail in some cases. It doesn't. In fact many PRO cards are just like that. If you have apps A, B, C with volumes a, b, c you can always set the HW gain to unity gain (0dB), and send s = a * A + b * B + c * C (1) to the soundcard. What would be the advantage of doing what PA does, which is * m = maximum of a, b, c) * Set the master to m, * send s = a/m * A + b/m * B + c/m * C (2) ??? It can only generate trouble, basically you forfeit any headroom the system would have.
So PA will set the master output to -20 dB. Now even if all of these apps are limited to contributing -20 dB (but there is no reason why that should be), the sum of them can be higher, but your soundcard can't handle that.
That clearly would not work. Surely PA would need to adjust the master output to compensate for the number of channels? I don't know these implementation details, but I don't see how your arguments shows that this is impossible in general, just that the algorithm you outlined does not work.
PA could leave some headroom and even adjust that in function of the number of sources. But it could also just leave the master gain alone, and compute (1) above instead of (2). Any advantage you or any user have from using PA 'things just work' would remain the same. But it's a lot simpler and doesn't have the problems (2) has. -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)
On Sun, 12 Aug 2012 15:01:06 +0000 Fons Adriaensen <fons@linuxaudio.org> wrote:
On Sun, Aug 12, 2012 at 04:00:47PM +0200, Tom Gundersen wrote:
On Sun, Aug 12, 2012 at 3:07 PM, Fons Adriaensen <fons@linuxaudio.org> wrote:
it's just extremely clumsy to use a mixer that way, you'd need ten hands. For it means that whenever you want to adjust a single channnel you may have to adjust *all* others and the master at the same time.
Unlike humans, computers does not have a limited number of hands. This is not a priori a problem.
It's still like trying to start a 10-ton truck in 5th gear. If you do that on your first day on the job you'll be fired, not because your boss likes to show his authority but because you have shown your incompetence. And if a computerized system tries to do that (and maybe it could if it has very fine control over the engine and clutch) then there's clearly something wrong with it.
Things will still work well when (A) happens to contribute nothing (i.e. while it outputs silence). So things will still work well when (A) isn't there at all. *There is no need to change anything at all* when (A) goes away, even if all others have their volume set to lower values.
You have showed that it is unnecessary in one particular (very simple) case. However, you have not showed that it is unnecessary in all cases, so this is not really relevant (had we been talking about a human doing this, you'd have a point of course).
It is never necessary. It it were that would imply that a sound card without any gain controls (equivalent to a fixed 0 dB gain) would fail in some cases. It doesn't. In fact many PRO cards are just like that.
If you have apps A, B, C with volumes a, b, c you can always set the HW gain to unity gain (0dB), and send
s = a * A + b * B + c * C (1)
Let me see if I understand. Capital A, B and C are bare intensities (in watts or logarithmic scale) sent from an app? If those are arbitrarily large, how do you make sure your speaker is not going to blow up?
to the soundcard. What would be the advantage of doing what PA does, which is
* m = maximum of a, b, c) * Set the master to m, * send
s = a/m * A + b/m * B + c/m * C (2)
???
It can only generate trouble, basically you forfeit any headroom the system would have.
So, the intention is to normalize to the loudest app?
So PA will set the master output to -20 dB. Now even if all of these apps are limited to contributing -20 dB (but there is no reason why that should be), the sum of them can be higher, but your soundcard can't handle that.
That clearly would not work. Surely PA would need to adjust the master output to compensate for the number of channels? I don't know these implementation details, but I don't see how your arguments shows that this is impossible in general, just that the algorithm you outlined does not work.
PA could leave some headroom and even adjust that in function of the number of sources. But it could also just leave the master gain alone, and compute (1) above instead of (2). Any advantage you or any user have from using PA 'things just work' would remain the same. But it's a lot simpler and doesn't have the problems (2) has.
-- Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
On Sun, Aug 12, 2012 at 5:01 PM, Fons Adriaensen <fons@linuxaudio.org> wrote:
If you have apps A, B, C with volumes a, b, c you can always set the HW gain to unity gain (0dB), and send
s = a * A + b * B + c * C (1)
to the soundcard. What would be the advantage of doing what PA does, which is
* m = maximum of a, b, c) * Set the master to m, * send
s = a/m * A + b/m * B + c/m * C (2)
Take a=0.00001 (or some other sufficiently small number), b=2*a and c=3*a. You then risk that with (1) you have s=0 due to rounding errors, whilst with (2) s>0. How big a problem this is in practice, I don't know. I'm a mathematician, and not a sound engineer. -t
Fons Adriaensen wrote:
It is never necessary. It it were that would imply that a sound card without any gain controls (equivalent to a fixed 0 dB gain) would fail in some cases. It doesn't. In fact many PRO cards are just like that.
If you have apps A, B, C with volumes a, b, c you can always set the HW gain to unity gain (0dB), and send
s = a * A + b * B + c * C (1)
to the soundcard. What would be the advantage of doing what PA does, which is
* m = maximum of a, b, c) * Set the master to m, * send
s = a/m * A + b/m * B + c/m * C (2)
???
It can only generate trouble, basically you forfeit any headroom the system would have.
Actually, that's one point where PA is right (even though it's wrong on a lot of other points): doing it like (2) avoids amplifying the quantification noise if the sound card applies the master gain in analog (or uses higher bit depths internally before the DACs as some do). When cascading amplifiers, it is always better to put the highest possible gain on the first stages (always leaving enough headroom to avoid clipping/distortion) so that later stages will not amplify the noise from the first stages (or so that they will reduce it along with the signal). The only case when this rule does not hold is when doing digital processing in floating point (because then the quantification noise is defined as a proportion of the actual signal instead of its potential maximum). Jerome -- mailto:jeberger@free.fr http://jeberger.free.fr Jabber: jeberger@jabber.fr
On Sun, 2012-08-12 at 19:38 +0200, "Jérôme M. Berger" wrote:
Fons Adriaensen wrote:
It is never necessary. It it were that would imply that a sound card without any gain controls (equivalent to a fixed 0 dB gain) would fail in some cases. It doesn't. In fact many PRO cards are just like that.
If you have apps A, B, C with volumes a, b, c you can always set the HW gain to unity gain (0dB), and send
s = a * A + b * B + c * C (1)
to the soundcard. What would be the advantage of doing what PA does, which is
* m = maximum of a, b, c) * Set the master to m, * send
s = a/m * A + b/m * B + c/m * C (2)
???
It can only generate trouble, basically you forfeit any headroom the system would have.
Actually, that's one point where PA is right (even though it's wrong on a lot of other points): doing it like (2) avoids amplifying the quantification noise if the sound card applies the master gain in analog (or uses higher bit depths internally before the DACs as some do).
When cascading amplifiers, it is always better to put the highest possible gain on the first stages (always leaving enough headroom to avoid clipping/distortion) so that later stages will not amplify the noise from the first stages (or so that they will reduce it along with the signal). The only case when this rule does not hold is when doing digital processing in floating point (because then the quantification noise is defined as a proportion of the actual signal instead of its potential maximum).
Jerome
If you do a mix you should keep the first stages within a good level that fits to the operating points of the op-amps, when ever possible, but you do the mix at that point, followed by sub groups followed by the master, the earlier the stage, the more you'll work with levels, you do less work for the sub groups and the most less work for for the master. You won't readjust the master continuous, especially not for a live stream. Regards, Ralf
Ralf Mardorf wrote:
On Sun, 2012-08-12 at 19:38 +0200, "Jérôme M. Berger" wrote:
Actually, that's one point where PA is right (even though it's wrong on a lot of other points): doing it like (2) avoids amplifying the quantification noise if the sound card applies the master gain in analog (or uses higher bit depths internally before the DACs as some do).
When cascading amplifiers, it is always better to put the highest possible gain on the first stages (always leaving enough headroom to avoid clipping/distortion) so that later stages will not amplify the noise from the first stages (or so that they will reduce it along with the signal). The only case when this rule does not hold is when doing digital processing in floating point (because then the quantification noise is defined as a proportion of the actual signal instead of its potential maximum).
Jerome
If you do a mix you should keep the first stages within a good level that fits to the operating points of the op-amps, when ever possible, but you do the mix at that point, followed by sub groups followed by the master, the earlier the stage, the more you'll work with levels, you do less work for the sub groups and the most less work for for the master. You won't readjust the master continuous, especially not for a live stream.
Two points: - You don't readjust the master continuously, but you don't add/remove sources on the fly either. You adjust the master in the beginning when you setup your system, but the reason you can do that is because you know exactly what sources you will have and what kinds of levels those sources generate. - "Keep the first stages within a good level that fits the operating points of the op-amps". In practice, this is done by using the maximum level that does not produce distortion. When talking digital signals, this means keep the level at 0dB for as long as possible. Jerome -- mailto:jeberger@free.fr http://jeberger.free.fr Jabber: jeberger@jabber.fr
On Mon, 2012-08-13 at 19:53 +0200, "Jérôme M. Berger" wrote:
Two points:
- You don't readjust the master continuously, but you don't add/remove sources on the fly either. You adjust the master in the beginning when you setup your system, but the reason you can do that is because you know exactly what sources you will have and what kinds of levels those sources generate.
That's "more "more"" or less true. But regarding to PA, PA can't have all this information ;). Yep, it's your argument, that what PA does is correct. You aren't completely wrong. I still vote for "headroom" and a classical analog style. Or much better "self responsibility", sorry, I couldn't resist. Use jackd, read the ffffffffff manual and control audio streams yourself. Automation always tends to fail. YMMV! Ralf
Ralf Mardorf wrote:
Or much better "self responsibility", sorry, I couldn't resist. Use jackd, read the ffffffffff manual and control audio streams yourself. Automation always tends to fail.
How I agree that manual control will give better results assuming one knows what he is doing, but... Tell me, have you calibrated your monitor? Most people are quite happy with "good enough" for things outside their main domains of activity/interest. You, as a sound engineer, will want more from your sound setup. People working in video or photography will want more from their displays. Others will be happy so long as their computer "just works(tm)". To each his own. Jerome -- mailto:jeberger@free.fr http://jeberger.free.fr Jabber: jeberger@jabber.fr
On Sun, Aug 12, 2012 at 07:38:58PM +0200, "Jérôme M. Berger" wrote:
Actually, that's one point where PA is right (even though it's wrong on a lot of other points): doing it like (2) avoids amplifying the quantification noise if the sound card applies the master gain in analog (or uses higher bit depths internally before the DACs as some do).
True, if the master is after the DAC, but even then irrelevant. Quantisation noise for a typical 20-bit (or even 16-bit) DA is low enough so it doesn't matter. See previous post.
When cascading amplifiers, it is always better to put the highest possible gain on the first stages (always leaving enough headroom to avoid clipping/distortion) so that later stages will not amplify the noise from the first stages (or so that they will reduce it along with the signal). The only case when this rule does not hold is when doing digital processing in floating point (because then the quantification noise is defined as a proportion of the actual signal instead of its potential maximum).
Correct again. But there's not reason why a software mixer shouldn't use floating point, or a fixed point format (e.g. 32 bit integers) that provides enough room above and below. Please don't tell me that PA is using 16-bit for its internal operations - that would really prove it's complete crap. Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)
On 13 Aug 2012 04:31, "Fons Adriaensen" <fons@linuxaudio.org> wrote:
Please don't tell me that PA is using 16-bit for its internal operations - that would really prove it's complete crap.
As far as I can recall from discussion on their list, it's floating point. And thanks for the explanations fons, I've always been impressed by your audio knowledge on this and other lists.
On Sun, Aug 12, 2012 at 04:00:47PM +0200, Tom Gundersen wrote:
You have showed that it is unnecessary in one particular (very simple) case. However, you have not showed that it is unnecessary in all cases, so this is not really relevant (had we been talking about a human doing this, you'd have a point of course).
I suspect that mathematical thinking is not your thing - no problem. For otherwise it would be clear that the 'simple' example I provided covers the general case. Let me try again. I write a PA-aware sound app X that * always sets its volume to 0 dB (max). * always outputs silence (zero valued samples). As soon as that app runs, PA will set the master gain to 0 dB and use software scaling on all other apps. Now there are two possibilities: * Either everything is OK (it will be), and we have shown that you can always leave the master gain at 0 dB, * or everything is not OK, and we have shown that PA fails. Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)
On Sun, Aug 12, 2012 at 5:27 PM, Fons Adriaensen <fons@linuxaudio.org> wrote:
On Sun, Aug 12, 2012 at 04:00:47PM +0200, Tom Gundersen wrote:
You have showed that it is unnecessary in one particular (very simple) case. However, you have not showed that it is unnecessary in all cases, so this is not really relevant (had we been talking about a human doing this, you'd have a point of course).
I suspect that mathematical thinking is not your thing - no problem. For otherwise it would be clear that the 'simple' example I provided covers the general case.
Let me try again. I write a PA-aware sound app X that
* always sets its volume to 0 dB (max). * always outputs silence (zero valued samples).
As soon as that app runs, PA will set the master gain to 0 dB and use software scaling on all other apps. Now there are two possibilities:
* Either everything is OK (it will be), and we have shown that you can always leave the master gain at 0 dB,
* or everything is not OK, and we have shown that PA fails.
Your argument was clear (I'm ok with maths :) ). I was just pointing out that the case where the hardware can always be set to 0dB is not the interesting one. You clearly want to avoid setting the hardware to >0dB if possible, but sometimes it is not possible (because you can't hear anything ;) ) so you have to have an algorithm to do it in the best way. Imagine you have two streams (A) which needs no software nor hardware gain, had it been played alone, and (B) which forces the hardware gain to be >0dB (and (A) to be scaled down in sw). If (B) goes away you clearly want to set the hw volume back to 0 and (A) to stop being scaled in sw. The second case, where the total gain should be <0dB, I would have thought intuitively that doing this purely in software (especially on very faint signals) would be less ideal than doing it in hw (you'd be throwing away the resolution, wouldn't you?), but I'll admit that I don't have the experience to talk about that with any authority. -t
On Sun, 12 Aug 2012 18:02:59 +0200 Tom Gundersen <teg@jklm.no> wrote:
On Sun, Aug 12, 2012 at 5:27 PM, Fons Adriaensen <fons@linuxaudio.org> wrote:
On Sun, Aug 12, 2012 at 04:00:47PM +0200, Tom Gundersen wrote:
You have showed that it is unnecessary in one particular (very simple) case. However, you have not showed that it is unnecessary in all cases, so this is not really relevant (had we been talking about a human doing this, you'd have a point of course).
I suspect that mathematical thinking is not your thing - no problem. For otherwise it would be clear that the 'simple' example I provided covers the general case.
Let me try again. I write a PA-aware sound app X that
* always sets its volume to 0 dB (max). * always outputs silence (zero valued samples).
As soon as that app runs, PA will set the master gain to 0 dB and use software scaling on all other apps. Now there are two possibilities:
* Either everything is OK (it will be), and we have shown that you can always leave the master gain at 0 dB,
* or everything is not OK, and we have shown that PA fails.
Your argument was clear (I'm ok with maths :) ). I was just pointing out that the case where the hardware can always be set to 0dB is not the interesting one.
You clearly want to avoid setting the hardware to >0dB if possible,
Correct me if I'm wrong but I don't think that's possible, because dB is normalized to max power (in watts = intensity).
but sometimes it is not possible (because you can't hear anything ;) ) so you have to have an algorithm to do it in the best way. Imagine you have two streams (A) which needs no software nor hardware gain, had it been played alone, and (B) which forces the hardware gain to be >0dB (and (A) to be scaled down in sw). If (B) goes away you clearly want to set the hw volume back to 0 and (A) to stop being scaled in sw.
The second case, where the total gain should be <0dB, I would have thought intuitively that doing this purely in software (especially on very faint signals) would be less ideal than doing it in hw (you'd be throwing away the resolution, wouldn't you?), but I'll admit that I don't have the experience to talk about that with any authority.
-t
-- Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
On Sun, Aug 12, 2012 at 6:10 PM, Leonid Isaev <lisaev@umail.iu.edu> wrote:
Correct me if I'm wrong but I don't think that's possible, because dB is normalized to max power (in watts = intensity).
If I understand correctly, 0dB is "don't apply any gain". On some chips, that's indeed the same as max, but I have had several laptops where that is not the case. -t
On Sun, 2012-08-12 at 11:10 -0500, Leonid Isaev wrote:
Correct me if I'm wrong but I don't think that's possible, because dB is normalized to max power (in watts = intensity).
You can boost a signal.
On Sun, 2012-08-12 at 18:15 +0200, Ralf Mardorf wrote:
On Sun, 2012-08-12 at 11:10 -0500, Leonid Isaev wrote:
Correct me if I'm wrong but I don't think that's possible, because dB is normalized to max power (in watts = intensity).
You can boost a signal.
... > 0dB for the result of an analog signal, you also can boost a digital signal, just the result needs to be <= 0dBFS for digital. For digital there's dB full-scale square wave and dB full-scale sine wave. http://en.wikipedia.org/wiki/DBFS
On Sun, Aug 12, 2012 at 11:10:10AM -0500, Leonid Isaev wrote:
Correct me if I'm wrong but I don't think that's possible, because dB is normalized to max power (in watts = intensity).
[ Tom & Leonid ]
Lots of questions...
I'll try to answer them, but not all at a time (I need to eat/sleep/etc) as well, and it may amount to crash course in audio engineering... Decibels. What '0 dB' means depends on the context, and usually for someone 'knowing the art' it is clear from the context. For gains it is just a ratio epxressed on a logarithmic scale. For signal levels it depends on the physics. For example, for electrical signals a common 'reference level' corresponding to '0dB' would be 0.775 volt RMS. That is usually notated just 'dB' or 'dBm' (the origin of this is that it represents 1 mW in a load of 600 Ohm). Or you could see dBV, which means 0 dB = 1 V RMS. For sound pressure levels, the reference is 2e-5 Pa (Pascal), which is around the hearing threshold at medium frequencies. So e.g. 90 dB SPL means a sound that is 1e9 times (a billion for the Americans) stronger (in power) than the hearing threshold. The large ratios are why a logarithmics scale is used in the first place. In a digital context, '0dB' usually means the RMS value of the highest sine wave amplitude that can be represented, unless you're talking about peak sample levels, where it means the highest possible sample value. This can be confusing. Resolution Assume you have a simple 16-bit consumer card, and forget about gain controls etc. for a moment, the samples produced by your app (e.g. a player) arrive unmodified at the DA converter. 16 bit means that there are 2^16 possible values for a sample. So the signal is quantised to the nearest level. Except in some special cases, the error (a rounding error) is random and appears as noise. For a 16-bit card, that noise will have a level that is 98 dB lower than the maximum amplitude sine wave it can produce. Let's assume the card is not really 'perfect' and you actually have 95 dB of dynamic range. OK, play back some music that has an high average level (i.e. using all bits most of the time), connect your card to and amp and speakers and adjust the volume on the amp so it is as loud as you would ever want it. Let's assume you now have something like 100 dB average sound pressure level. That is quite loud (your neighbours will complain) and more than enough to cause permanent hearing damage. Let's say that 100 dB average level corresponds to a peak level of 110 dB. Now stop the music. Assuming the sound card is the weakest part in the chain, you will now get a noise level of 110 - 95 = 15 dB. This is well below the ambient noise level in most places, so you won't hear it unless you stick your ears in the speakers. What does this mean ? It means that the dynamic range of 95 dB is more than enough. And if it isn't (as in a music studio where you'd want higher peak levels and the ambient noise level is lower) you just need a few more bits, maybe 20. You can reproduce sound at any level (below the maximum you set) without having to bother about 'resolution', by just scaling the samples you send to the soundcard, and without having to adjust any HW levels. Even if the signal is weak and doesn't use all bits there is no loss of quality - as the error (the noise) is well below the ambient level. If you don't believe this then ask yourself why speakers having an integrated amplifier and a digital input are so popular in professional circles. There is no 'volume' control on those (at least not one you'd normally use) the only way to play at low levels is by not using all the bits. All for now. -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)
On Sun, 2012-08-12 at 18:29 +0000, Fons Adriaensen wrote:
What does this mean ? It means that the dynamic range of 95 dB is more than enough. And if it isn't (as in a music studio where you'd want higher peak levels and the ambient noise level is lower) you just need a few more bits, maybe 20.
You can reproduce sound at any level (below the maximum you set) without having to bother about 'resolution'
I agree, wrote something similar already before. Btw. some oldish Sony recorders are at 16 bit and for the sound quality it's more important if the mixer is a Neve or Behringer ;), than how many bits are used for the sampling. E.g. http://www2.ak.tu-berlin.de/wwwlogic/Bilder2/24Spur.jpg 16bit AD and 18 bit DA.
On Sun, 2012-08-12 at 20:44 +0200, Ralf Mardorf wrote:
On Sun, 2012-08-12 at 18:29 +0000, Fons Adriaensen wrote:
What does this mean ? It means that the dynamic range of 95 dB is more than enough. And if it isn't (as in a music studio where you'd want higher peak levels and the ambient noise level is lower) you just need a few more bits, maybe 20.
You can reproduce sound at any level (below the maximum you set) without having to bother about 'resolution'
I agree, wrote something similar already before. Btw. some oldish Sony recorders are at 16 bit and for the sound quality it's more important if the mixer is a Neve or Behringer ;), than how many bits are used for the sampling. E.g. http://www2.ak.tu-berlin.de/wwwlogic/Bilder2/24Spur.jpg 16bit AD and 18 bit DA.
PS: Recordings 16bit. Those old monsters do sound amazing, with sane leveling < 6 dBFS and less.
On Sun, 2012-08-12 at 20:57 +0200, Ralf Mardorf wrote:
On Sun, 2012-08-12 at 20:44 +0200, Ralf Mardorf wrote:
On Sun, 2012-08-12 at 18:29 +0000, Fons Adriaensen wrote:
What does this mean ? It means that the dynamic range of 95 dB is more than enough. And if it isn't (as in a music studio where you'd want higher peak levels and the ambient noise level is lower) you just need a few more bits, maybe 20.
You can reproduce sound at any level (below the maximum you set) without having to bother about 'resolution'
I agree, wrote something similar already before. Btw. some oldish Sony recorders are at 16 bit and for the sound quality it's more important if the mixer is a Neve or Behringer ;), than how many bits are used for the sampling. E.g. http://www2.ak.tu-berlin.de/wwwlogic/Bilder2/24Spur.jpg 16bit AD and 18 bit DA.
PS: Recordings 16bit. Those old monsters do sound amazing, with sane leveling < 6 dBFS and less. ^^^^^^^ < -6 dBFS and lower ;) I missed the "-" and of course "<" + less/lower is tautological, but that's wanted.
Fons Adriaensen wrote:
16 bit means that there are 2^16 possible values for a sample. So the signal is quantised to the nearest level. Except in some special cases, the error (a rounding error) is random and appears as noise. For a 16-bit card, that noise will have a level that is 98 dB lower than the maximum amplitude sine wave it can produce. Let's assume the card is not really 'perfect' and you actually have 95 dB of dynamic range.
Where does that 98dB come from? A factor of 2 is roughly 3dB, so 16 bits should mean 3x16=48dB, no? Taking this figure, your example where the maximum level is set to 110dB will leave 62dB for pure noise, i.e between the level of a TV set and a handheld electric mixer (1) so perfectly audible. BTW, I generated a minimum amplitude signal in audacity and played it with my speaker volume set to max and it was perfectly audible (even with my window open and the birds singing outside). Since quantification noise is half that, it should be audible too.
If you don't believe this then ask yourself why speakers having an integrated amplifier and a digital input are so popular in professional circles. There is no 'volume' control on those (at least not one you'd normally use) the only way to play at low levels is by not using all the bits.
I doubt those use 16 bits input. Even low-end hi-fi digital recorders support 24 bits, which gives -72dB for the noise and starts indeed to be acceptable. But most end-user will simply set their system to "CD quality" (or leave it at the default which is usually that same 16bits 44kHz, whatever name the app chose to gave it).
But there's not reason why a software mixer shouldn't use floating point, or a fixed point format (e.g. 32 bit integers) that provides enough room above and below.
Well, 16 bits integers should be faster to process. The difference is not important when your computer is doing nothing but audio processing anyway, but we're talking end-user system here and sound mixing is simply a background process that should not take too much time from the real work of the computer, even if this results in less than optimal sound quality. You might argue that the difference in computing requirements is very little, but keep in mind that the "real work" could be a computer game where every cycle counts. This is especially true in the most common case where there is a single sound source: PA can send the sound directly to the sound card without wasting any time adjusting the gain in software first. Jerome (1) https://en.wikipedia.org/wiki/Sound_pressure#Examples_of_sound_pressure_and_... -- mailto:jeberger@free.fr http://jeberger.free.fr Jabber: jeberger@jabber.fr
On Mon, Aug 13, 2012 at 08:33:41PM +0200, "Jérôme M. Berger" wrote:
Fons Adriaensen wrote:
16 bit means that there are 2^16 possible values for a sample. So the signal is quantised to the nearest level. Except in some special cases, the error (a rounding error) is random and appears as noise. For a 16-bit card, that noise will have a level that is 98 dB lower than the maximum amplitude sine wave it can produce. Let's assume the card is not really 'perfect' and you actually have 95 dB of dynamic range.
Where does that 98dB come from? A factor of 2 is roughly 3dB, so 16 bits should mean 3x16=48dB, no? Taking this figure, your example where the maximum level is set to 110dB will leave 62dB for pure noise, i.e between the level of a TV set and a handheld electric mixer (1) so perfectly audible.
Sigh.... Is it *really* asking to much to look up and understand at least the *very very basics* before you post instead of showing your complete ignorance ??? Sorry if this sound harsh, but if you don't know where that 98 dB comes from your are not in any position to question what I wrote. And I am not providing free education. Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)
On Mon, 2012-08-13 at 20:33 +0200, "Jérôme M. Berger" wrote:
I doubt those use 16 bits input. Even low-end hi-fi digital recorders support 24 bits, which gives -72dB for the noise and starts indeed to be acceptable. But most end-user will simply set their system to "CD quality" (or leave it at the default which is usually that same 16bits 44kHz, whatever name the app chose to gave it).
The Sony gear I posted does record with 16bit only, it's still used by professionals and even at Ebay those oldish machines coast >4K$. Btw. from my consumer stuff: Sony DAT DTC-670 Dynamic > 90dB AIWA HD-S1 Dynamic > 85dB I'm missing analog tape saturation, I'm missing the punch of analog clipping, but the sound quality of 16bit 48KHz isn't missing anything, even if you record with to less level. For computers digital recordings can be bad, even with a RME card, as on my machine, this has to do with the complete chain, resp. chip set of your/my mobo. The quality of professional stand alone devices doesn't need more than 16bit 48KHz. It's not bad in the professional studio and we don't need to discuss CD and LP quality. Lower than 16bit 48KHz is evil at any level.
On Mon, 2012-08-13 at 21:26 +0200, Ralf Mardorf wrote:
On Mon, 2012-08-13 at 20:33 +0200, "Jérôme M. Berger" wrote:
I doubt those use 16 bits input. Even low-end hi-fi digital recorders support 24 bits, which gives -72dB for the noise and starts indeed to be acceptable. But most end-user will simply set their system to "CD quality" (or leave it at the default which is usually that same 16bits 44kHz, whatever name the app chose to gave it).
The Sony gear I posted does record with 16bit only, it's still used by professionals and even at Ebay those oldish machines coast >4K$.
Btw. from my consumer stuff:
Sony DAT DTC-670
Dynamic > 90dB
AIWA HD-S1
Dynamic > 85dB
I'm missing analog tape saturation, I'm missing the punch of analog clipping, but the sound quality of 16bit 48KHz isn't missing anything, even if you record with to less level. For computers digital recordings can be bad, even with a RME card, as on my machine, this has to do with the complete chain, resp. chip set of your/my mobo.
The quality of professional stand alone devices doesn't need more than 16bit 48KHz. It's not bad in the professional studio and we don't need to discuss CD and LP quality.
Lower than 16bit 48KHz is evil at any level.
Some chips work better at e.g. 96KHz, it doesn't depend to the KHz, simply to the chip.
On 13 August 2012 21:36, Ralf Mardorf <ralf.mardorf@alice-dsl.net> wrote:
On Mon, 2012-08-13 at 21:26 +0200, Ralf Mardorf wrote:
Some chips work better at e.g. 96KHz, it doesn't depend to the KHz, simply to the chip.
I always thought that these high sampling frequencies are used to avoid aliasing without need for a low-pass filter. Is that true, or am I completely wrong? Lukas
On Tue, Aug 14, 2012 at 08:59:07AM +0200, Lukas Jirkovsky wrote:
On 13 August 2012 21:36, Ralf Mardorf <ralf.mardorf@alice-dsl.net> wrote:
On Mon, 2012-08-13 at 21:26 +0200, Ralf Mardorf wrote:
Some chips work better at e.g. 96KHz, it doesn't depend to the KHz, simply to the chip.
I always thought that these high sampling frequencies are used to avoid aliasing without need for a low-pass filter. Is that true, or am I completely wrong?
Lukas
Sorry to the Arch hivemind that this first post on mine in this list has a negative tone. OK OK thanks for all the great knowledge being shared about audio, BUT aside from adding OT into the subject this discussion has gone so far off topic it does not even pertain to ARCHLINUX at all! So can i ask you all to please drop this & stop filling up my mailbox with unrelevant chit chat or take this to a more relevant place, you all have each others email address' so make your own personal thread. t0m5k1
On 08/14/2012 03:17 AM, Tom Rand wrote:
On Tue, Aug 14, 2012 at 08:59:07AM +0200, Lukas Jirkovsky wrote:
On 13 August 2012 21:36, Ralf Mardorf <ralf.mardorf@alice-dsl.net> wrote:
On Mon, 2012-08-13 at 21:26 +0200, Ralf Mardorf wrote:
Some chips work better at e.g. 96KHz, it doesn't depend to the KHz, simply to the chip.
I always thought that these high sampling frequencies are used to avoid aliasing without need for a low-pass filter. Is that true, or am I completely wrong?
Lukas
Sorry to the Arch hivemind that this first post on mine in this list has a negative tone.
OK OK thanks for all the great knowledge being shared about audio, BUT aside from adding OT into the subject this discussion has gone so far off topic it does not even pertain to ARCHLINUX at all!
So can i ask you all to please drop this & stop filling up my mailbox with unrelevant chit chat or take this to a more relevant place, you all have each others email address' so make your own personal thread.
t0m5k1
Why do I care if your mailbox is filling up ?
You are either trolling or don't understand that you are not one man group. We have guidelines: He asked politely; be respectful back but also for others here. On Aug 14, 2012, at 7:10 AM, Baho Utot <baho-utot@columbus.rr.com> wrote:
On 08/14/2012 03:17 AM, Tom Rand wrote:
On Tue, Aug 14, 2012 at 08:59:07AM +0200, Lukas Jirkovsky wrote:
On 13 August 2012 21:36, Ralf Mardorf <ralf.mardorf@alice-dsl.net> wrote:
On Mon, 2012-08-13 at 21:26 +0200, Ralf Mardorf wrote:
Some chips work better at e.g. 96KHz, it doesn't depend to the KHz, simply to the chip.
I always thought that these high sampling frequencies are used to avoid aliasing without need for a low-pass filter. Is that true, or am I completely wrong?
Lukas
Sorry to the Arch hivemind that this first post on mine in this list has a negative tone.
OK OK thanks for all the great knowledge being shared about audio, BUT aside from adding OT into the subject this discussion has gone so far off topic it does not even pertain to ARCHLINUX at all!
So can i ask you all to please drop this & stop filling up my mailbox with unrelevant chit chat or take this to a more relevant place, you all have each others email address' so make your own personal thread.
t0m5k1
Why do I care if your mailbox is filling up ?
On Tue, 2012-08-14 at 08:07 -0400, Alex Belanger wrote:
You are either trolling or don't understand that you are not one man group. We have guidelines: He asked politely; be respectful back but also for others here.
Top posting isn't nice too ;). However, some shared mails off-list, if a discussion should be continued off list, I recommend that Baho should get CCed mails too, if he wants. Hth, Ralf
On Sun, 2012-08-12 at 18:02 +0200, Tom Gundersen wrote:
The second case, where the total gain should be <0dB, I would have thought intuitively that doing this purely in software (especially on very faint signals) would be less ideal than doing it in hw (you'd be throwing away the resolution, wouldn't you?), but I'll admit that I don't have the experience to talk about that with any authority.
It's a common misconception that keeping the level lower than 0dB would lead to less "resolution". It depends to the sampling rate and bit depth and less to the level control.
On 12-08-2012 17:11, Ralf Mardorf wrote:
On Sun, 2012-08-12 at 18:02 +0200, Tom Gundersen wrote:
The second case, where the total gain should be <0dB, I would have thought intuitively that doing this purely in software (especially on very faint signals) would be less ideal than doing it in hw (you'd be throwing away the resolution, wouldn't you?), but I'll admit that I don't have the experience to talk about that with any authority.
It's a common misconception that keeping the level lower than 0dB would lead to less "resolution". It depends to the sampling rate and bit depth and less to the level control.
Sampling rate would not matter to level discussions since it limits only the maximum frequency that can be properly sampled or reproduced. For the same bit depth a lower playback output level will yield a lower signal-to-noise or signal-to noise + distortion ratio, thus leading to the same effect of having a DAC of less resolution playing at full scale, so in a way you can say that for lower output levels you have less resolution. -- Mauro Santos
On Sun, 2012-08-12 at 18:09 +0100, Mauro Santos wrote:
On 12-08-2012 17:11, Ralf Mardorf wrote:
On Sun, 2012-08-12 at 18:02 +0200, Tom Gundersen wrote:
The second case, where the total gain should be <0dB, I would have thought intuitively that doing this purely in software (especially on very faint signals) would be less ideal than doing it in hw (you'd be throwing away the resolution, wouldn't you?), but I'll admit that I don't have the experience to talk about that with any authority.
It's a common misconception that keeping the level lower than 0dB would lead to less "resolution". It depends to the sampling rate and bit depth and less to the level control.
Sampling rate would not matter to level discussions since it limits only the maximum frequency that can be properly sampled or reproduced.
Agree, but it is also "resolution".
For the same bit depth a lower playback output level will yield a lower signal-to-noise or signal-to noise + distortion ratio, thus leading to the same effect of having a DAC of less resolution playing at full scale, so in a way you can say that for lower output levels you have less resolution.
But the lower resolution doesn't become audible that easy, if the bit depth is high enough. It's better to keep the level within reason instead of 0dbFS. Even at 48 KHz 16 bit, headroom is better than maximum level. And if you use totally low bit sampling e.g. 2bit for the C64, you need to play with the level. Higher level doesn't mean better sound quality per se.
On 12-08-2012 18:38, Ralf Mardorf wrote:
On Sun, 2012-08-12 at 18:09 +0100, Mauro Santos wrote:
On 12-08-2012 17:11, Ralf Mardorf wrote:
On Sun, 2012-08-12 at 18:02 +0200, Tom Gundersen wrote:
The second case, where the total gain should be <0dB, I would have thought intuitively that doing this purely in software (especially on very faint signals) would be less ideal than doing it in hw (you'd be throwing away the resolution, wouldn't you?), but I'll admit that I don't have the experience to talk about that with any authority.
It's a common misconception that keeping the level lower than 0dB would lead to less "resolution". It depends to the sampling rate and bit depth and less to the level control.
Sampling rate would not matter to level discussions since it limits only the maximum frequency that can be properly sampled or reproduced.
Agree, but it is also "resolution".
Of course it is also resolution, but we were discussion resolution related to signal level, not temporal/frequency resolution.
For the same bit depth a lower playback output level will yield a lower signal-to-noise or signal-to noise + distortion ratio, thus leading to the same effect of having a DAC of less resolution playing at full scale, so in a way you can say that for lower output levels you have less resolution.
But the lower resolution doesn't become audible that easy, if the bit depth is high enough.
If you have proper electronics, for a higher resolution the noise floor will be much lower than the minimum signal your transducer can play so you can't possibly notice it. But use a low enough signal level followed by amplification in the digital domain (without allowing it to saturate) and you will tell the difference.
It's better to keep the level within reason instead of 0dbFS. Even at 48 KHz 16 bit, headroom is better than maximum level.
Of course you should have some headroom, if you are sampling an analog signal you can't know the maximum amplitude beforehand so you need some headroom, it is however always advisable to use the highest input level possible. If we are talking about digital systems, you know exactly what the maximum level is, if the DAC is good and all the following electronics have been properly engineered you can't blame anything but yourself if you get clipping after digitally "boosting" your signal.
And if you use totally low bit sampling e.g. 2bit for the C64, you need to play with the level. Higher level doesn't mean better sound quality per se.
Again, for any given bit depth if you use a higher level you will get a better signal-to-noise ratio. Sounding better is a whole other story, that is a subjective measure that is related to the human hearing system and is not easy to quantify,it is related to how faithfully you can replicate a signal and the C64 can't possibly be called a system designed to faithfully reproduce sound. -- Mauro Santos
On Sun, 2012-08-12 at 20:04 +0100, Mauro Santos wrote:
If we are talking about digital systems, you know exactly what the maximum level is
I programmed a 2bit MIDI sampler in Assembler and Basic for the C64, but even there the sampling was "stolen" from speechbasic and after that, my knowledge about digital innards stops :D. Is it really possible to know exactly, every time, at what level the sum of the audio streams are? IIRC float point does avoid some issues. However, do you think it's smart to adjust at least two following instances within the same audio chain at the same time? Regards, Ralf
On 12-08-2012 20:57, Ralf Mardorf wrote:
Is it really possible to know exactly, every time, at what level the sum of the audio streams are? IIRC float point does avoid some issues. However, do you think it's smart to adjust at least two following instances within the same audio chain at the same time?
If talking about adding two signals, whatever they are, if you know how the sum is made, you can know what the worst case sum will be and if that will cause any problems. By knowing the inputs and the process, the sum in this case, I don't see why it would be a problem to change several things at the same time, you just need to be careful not to get problems. -- Mauro Santos
On Sun, 2012-08-12 at 22:17 +0100, Mauro Santos wrote:
On 12-08-2012 20:57, Ralf Mardorf wrote:
Is it really possible to know exactly, every time, at what level the sum of the audio streams are? IIRC float point does avoid some issues. However, do you think it's smart to adjust at least two following instances within the same audio chain at the same time?
If talking about adding two signals, whatever they are, if you know how the sum is made, you can know what the worst case sum will be and if that will cause any problems.
Ok, I believe this without verifying it. So I still don't know, but I buy it as truth for this moment.
By knowing the inputs and the process, the sum in this case, I don't see why it would be a problem to change several things at the same time, you just need to be careful not to get problems.
Hardware steps vs software steps? I Don't believe that it's possible to automate it. Assumed the ALSA driver does come with everything PA needs, I still don't believe that it's smart to do it that way. "Careful" vs straight, but "careful" implies a delay. Analog forgives little mistakes, digital doesn't. Not everybody wishes to be the sun of a gun. I prefer to be careful, when "using/consuming" audio. Regards, Ralf
On 08/12/2012 10:00 AM, Tom Gundersen wrote: [putolin]
Clearly, PA is not meant for professional audio work. And it might be that for a professional all the PA logic is both unnecessary and maybe even detrimental (so you'd use jack or pure ALSA instead, that should not be a problem). However, that does not mean that PA is not a huge gain for the casual desktop user (assuming there are no bugs!). Thanks for the information. Tom
What is pulse audio suppose to do? I still don't know what problem it was trying to solve as just plain alsa works for me.
On Sun, 2012-08-12 at 12:43 -0400, Baho Utot wrote:
On 08/12/2012 10:00 AM, Tom Gundersen wrote:
[putolin]
Clearly, PA is not meant for professional audio work. And it might be that for a professional all the PA logic is both unnecessary and maybe even detrimental (so you'd use jack or pure ALSA instead, that should not be a problem). However, that does not mean that PA is not a huge gain for the casual desktop user (assuming there are no bugs!). Thanks for the information. Tom
What is pulse audio suppose to do?
It automatically should handle audio streams for your desktop. "Polypaudio" should grab everything :(.
If it is true that a noticeable glitch is produced, then obviously you have a point, however if the glitch is not noticeable then I don't see the problem you have with PA.
In the pro audio world the spinning of a cd has been noted to introduce errors as well as the windows volume control which is often bypassed by pro audio cards. This isn't necessarily something you can hear especially on a casual system. Of course bullshit is also rife and quite amusing sometimes. The same pro audio world sells £10,000 gold power cables as thick as your arm and then plugs them into a standard copper wall socket. -- _______________________________________________________________________ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) _______________________________________________________________________
On Mon, Aug 13, 2012 at 02:08:43AM +0100, Kevin Chadwick wrote:
Of course bullshit is also rife and quite amusing sometimes. The same pro audio world sells £10,000 gold power cables as thick as your arm and then plugs them into a standard copper wall socket.
Nobody in the pro audio world falls for that nonsense. What you refer to is the bizarre ecosystem of the 'audiophiles', generally people having too much money and no technical understanding at all. They'll buy whatever is expensive, up to equipment required to periodically flush out the old and tired electrons from their left-twisting-oxygen cables and replace them with young and fresh ones. Not that the pro audio world doesn't have its own share of nonsense, but it's different nonsense. Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)
Not that the pro audio world doesn't have its own share of nonsense, but it's different nonsense.
Yeah but that stuff is usually just irritating but the audiophile example is a little funny without explanation. -- _______________________________________________________________________ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) _______________________________________________________________________
On Mon, 2012-08-13 at 12:21 +0100, Kevin Chadwick wrote:
Not that the pro audio world doesn't have its own share of nonsense, but it's different nonsense.
Yeah but that stuff is usually just irritating but the audiophile example is a little funny without explanation.
One hand washes the other. Pro audio and video are hard businesses. Sometimes nonsense is just there, to save jobs. Faith can move mountains. IOW nonsense can be a motivation. Emotional beings shouldn't make their world to rational.
On 13 August 2012 16:04, Fons Adriaensen <fons@linuxaudio.org> wrote:
On Mon, Aug 13, 2012 at 02:08:43AM +0100, Kevin Chadwick wrote:
Of course bullshit is also rife and quite amusing sometimes. The same pro audio world sells Ł10,000 gold power cables as thick as your arm and then plugs them into a standard copper wall socket.
Nobody in the pro audio world falls for that nonsense.
I did fall _over_ a crapload of Monster cables one time in an FOH setup. Was the only time ever in my life I came across those stuff for live sound. Otherwise, we usually make our own cables. Anyway, this thread is pretty amusing itself. From polkit to audiophiles. How did that happen? (rhetoric) -- GPG/PGP ID: C0711BF1
On Mon, 2012-08-13 at 23:49 +0800, Rashif Ray Rahman wrote:
Otherwise, we usually make our own cables.
Private I sometimes buy ready to use cables, I just check if the soldering joints are ok. It's less expensive, since in Germany we've got an online retailer who sells equipment for less money. People from other European countries perhaps know the retailer too ;). For professional usage cables usually have to be self-made. Btw. I once asked if Neutrik plastic cable relief does crumble all over the world after a while at LAU or LAD. Yes, they do. I switched to Rean. Btw. very rational advertising: http://www.rean-connectors.com/website/themes/rean/images/rean_theme.jpg at http://www.rean-connectors.com/
On Mon, Aug 13, 2012 at 6:08 PM, Ralf Mardorf <ralf.mardorf@alice-dsl.net> wrote:
On Mon, 2012-08-13 at 23:49 +0800, Rashif Ray Rahman wrote:
Otherwise, we usually make our own cables.
Private I sometimes buy ready to use cables, I just check if the soldering joints are ok. It's less expensive, since in Germany we've got an online retailer who sells equipment for less money. People from other European countries perhaps know the retailer too ;).
For professional usage cables usually have to be self-made. Btw. I once asked if Neutrik plastic cable relief does crumble all over the world after a while at LAU or LAD. Yes, they do. I switched to Rean.
Btw. very rational advertising: http://www.rean-connectors.com/website/themes/rean/images/rean_theme.jpg at http://www.rean-connectors.com/
This still is Arch ML, so discussion about audio stuff should be taken to Arch-Audio or some place like that.
On Mon, 2012-08-13 at 18:20 +0200, Karol Blazewicz wrote:
On Mon, Aug 13, 2012 at 6:08 PM, Ralf Mardorf <ralf.mardorf@alice-dsl.net> wrote:
On Mon, 2012-08-13 at 23:49 +0800, Rashif Ray Rahman wrote:
Otherwise, we usually make our own cables.
Private I sometimes buy ready to use cables, I just check if the soldering joints are ok. It's less expensive, since in Germany we've got an online retailer who sells equipment for less money. People from other European countries perhaps know the retailer too ;).
For professional usage cables usually have to be self-made. Btw. I once asked if Neutrik plastic cable relief does crumble all over the world after a while at LAU or LAD. Yes, they do. I switched to Rean.
Btw. very rational advertising: http://www.rean-connectors.com/website/themes/rean/images/rean_theme.jpg at http://www.rean-connectors.com/
This still is Arch ML, so discussion about audio stuff should be taken to Arch-Audio or some place like that.
Ok. Apologize, digression happens, at least we stop to discuss about ... have forgotten the name of this coder. Easing of tension might be not that worse. Am I mistaken? It's marked as OT. However, you are right, but you anyway should be aware how communication works. There isn't rational behavior for emotional beings. I only know this expectations from Linux mailing lists. I hope we are human, emotional beings. Has software nothing to do with the context, usage? Regards, Ralf
On Mon, Aug 13, 2012 at 11:20 AM, Karol Blazewicz <karol.blazewicz@gmail.com> wrote:
On Mon, Aug 13, 2012 at 6:08 PM, Ralf Mardorf <ralf.mardorf@alice-dsl.net> wrote:
On Mon, 2012-08-13 at 23:49 +0800, Rashif Ray Rahman wrote:
Otherwise, we usually make our own cables.
Private I sometimes buy ready to use cables, I just check if the soldering joints are ok. It's less expensive, since in Germany we've got an online retailer who sells equipment for less money. People from other European countries perhaps know the retailer too ;).
For professional usage cables usually have to be self-made. Btw. I once asked if Neutrik plastic cable relief does crumble all over the world after a while at LAU or LAD. Yes, they do. I switched to Rean.
Btw. very rational advertising: http://www.rean-connectors.com/website/themes/rean/images/rean_theme.jpg at http://www.rean-connectors.com/
This still is Arch ML, so discussion about audio stuff should be taken to Arch-Audio or some place like that.
Right, just marking the subject as [OT] doesn't suddenly give you permission to post anything you like.
On Mon, Aug 13, 2012 at 06:08:04PM +0200, Ralf Mardorf wrote:
For professional usage cables usually have to be self-made. Btw. I once asked if Neutrik plastic cable relief does crumble all over the world after a while at LAU or LAD. Yes, they do. I switched to Rean.
Which is Neutrik made in China :-) Best XLRs are from Switchcraft. Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)
On Mon, 2012-08-13 at 16:35 +0000, Fons Adriaensen wrote:
On Mon, Aug 13, 2012 at 06:08:04PM +0200, Ralf Mardorf wrote:
For professional usage cables usually have to be self-made. Btw. I once asked if Neutrik plastic cable relief does crumble all over the world after a while at LAU or LAD. Yes, they do. I switched to Rean.
Which is Neutrik made in China :-)
Yes, but they seem to differ positively.
Best XLRs are from Switchcraft.
I'm not talking just about XLR, however I only heard good about Switchcraft and didn't experience anything bad myself. I always check what is available at thoma... and reiche... first, for less money. I still would buy Neutrik, when they are cheap at the time I do an order.
On Mon, 2012-08-13 at 02:08 +0100, Kevin Chadwick wrote:
The same pro audio world sells £10,000 gold power cables as thick as your arm and then plugs them into a standard copper wall socket.
No, that are rich consumers. I don't think that all of those consumers are stupid audiophiles, I guess some simply have the money and like the design. Cables used by professionals are not that expensive, but they also aren't stylish.
On Sun, 12 Aug 2012 13:07:32 +0000 Fons Adriaensen <fons@linuxaudio.org> wrote:
On Sun, Aug 12, 2012 at 02:47:59AM +0200, Tom Gundersen wrote:
Argument by authority, nice. Care to elaborate? (Sorry to anyone who is sick of PA, but for once I'm seeing the chance to learn something from one of these threads ;-)).
No authority needed here, it's just extremely clumsy to use a mixer that way, you'd need ten hands. For it means that whenever you want to adjust a single channnel you may have to adjust *all* others and the master at the same time.
If the problem is too complex to explain in layman terms, that's understandable. However, is the problem one that would be unacceptable in a professional setting (e.g. a recording studio, ...) as it would cause subtle issues. Or is it a problem that I should be able to observe on my crappy speakers at home? If so, what am I listening for? How would I go about reproducing it?
[1]
The first and sufficient argument is that is completely *unnecessary* to do such things.
Assume you have two or more apps producing sound, and one of them (A) has its volume set to max, so PA will set the master fader to max. Assume things are OK that way (which will probably be the case).
Things will still work well when (A) happens to contribute nothing (i.e. while it outputs silence). So things will still work well when (A) isn't there at all. *There is no need to change anything at all* when (A) goes away, even if all others have their volume set to lower values.
[2]
As to technical arguments, I can try. First thing to know is that you shouldn't confuse 'level' (a property of signal), and 'gain' (the ratio of two levels, or difference if you think in dB). Both are usually expressed in dB, but that doesn't make them the same thing. Compare it to time: a instant (epoch) and a duration are both expressed in the same units but they are different things. For example the sum of two epochs doesn't have any meaning, while the sum of two durations has. And if some activity has a duration of 40 minutes, that doesn't mean it has to finish at 00:40.
Similarly, if an apps has its gain set to -10 dB, that should not be taken to imply that it can't output more than -10 dB.
On 'real' mixers (digital or analog) you normally have considerable 'headroom'. Setting your master fader to -20 dB does not mean you can't output more than -20 dB. For digital ones that means that they use internally a wider format (more bits) than on the external interfaces. So you can actually trade off input gains and master gain to some extent.
Soundcard mixers are different. The PCM input to the mixer (i.e. the samples the SW provides) usually has the same format as the AD converter, e.g. 16 or 24 bits. That means that if the master is set to e.g. -20 dB, the card can't output any signal that is larger than -20 dB (w.r.t. its normal maximum level). Which is wrong. Assume you have two or more apps, all of them have their volume set to -20 dB. So PA will set the master output to -20 dB. Now even if all of these apps are limited to contributing -20 dB (but there is no reason why that should be), the sum of them can be higher, but your soundcard can't handle that.
It all amounts to this: unless the user is using the soundcard's 'master' as his global volume control (similar to a volume knob on an external amplifier) it should be left at 0 dB. No software layer should ever touch it.
So... on my intel AD**** I have PCM and Master knobs (in alsa). Are you saying that I should set Master to max (-0dB) and control volume through PCM only?
[3]
On many soundcards the master fader also controls the level of things that PA or any software layer doesn't know about, e.g. and external mic input. Which you'd use for karaoke, or to hear yourself in your headphones while skyping. That level must not depend on how other apps set their volume controls. Again the software should not touch the master gain.
[4]
You can't apply a soundcard mixer gain change at some exact point in a sample stream. So you can't change the master gain and change your internal scaling to compensate at exactly the same time. There will always be a glitch.
-- Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
On Sun, Aug 12, 2012 at 6:07 PM, Leonid Isaev <lisaev@umail.iu.edu> wrote:
So... on my intel AD**** I have PCM and Master knobs (in alsa). Are you saying that I should set Master to max (-0dB) and control volume through PCM only?
FWIW, on my intel soundcard I have Master, PCM and Front. When I change the system volume with PA it adjusts mainly Master, and keeps PCM and Front around 0dB (only adjusting them a bit to get higher resolution on the volume slider than what Master can provide). -t
On Sun, 2012-08-12 at 01:41 +0200, Jan Steffens wrote:
On Sun, Aug 12, 2012 at 1:23 AM, Fons Adriaensen <fons@linuxaudio.org> wrote:
If that is true it is completely wrong from the start. Because that setup can't be maintained when a second app starts playing which can happen at any time. Suppose that first (single) app has its volume set to some low value, and PA uses the soundcard PCM gain control to achieve that as you claim it does. Now suddenly there's a second app which wants a higher level. The only way to achieve that is to raise the hardware gain - you can't compensate for a low setting there by sending a louder signal, it would just clip. So PA now has to adjust the hardware gain and at the same time start scaling down the output from the first app. It's impossible to do that in any acceptable way.
Yet that's exactly what it does. And on my system (HDAudio) I have not noticed any changes in the volume of the first stream, even as the "Master" mixer control jumped levels.
Maybe ask the devs for details.
http://mailman.archlinux.org/pipermail/arch-general/2012-August/029596.html
On Sun, Aug 12, 2012 at 1:23 AM, Fons Adriaensen <fons@linuxaudio.org> wrote:
This is not correct. If the app has proper PA support (such as all KDE apps, and probably all gnome apps), then PA does the app specific mixing, not the app itself.
That doesn't stop the app from having its own internal volume control that PA doesn't know about.
That would not be "proper" PA support. An app can do all sorts of stupid stuff of course.
Moreover, if only one app is playing sound then PA does no mixing at all, but passes it all directly to ALSA (and sets ALSA's controls of course).
If that is true it is completely wrong from the start. Because that setup can't be maintained when a second app starts playing which can happen at any time. Suppose that first (single) app has its volume set to some low value, and PA uses the soundcard PCM gain control to achieve that as you claim it does. Now suddenly there's a second app which wants a higher level. The only way to achieve that is to raise the hardware gain - you can't compensate for a low setting there by sending a louder signal, it would just clip. So PA now has to adjust the hardware gain and at the same time start scaling down the output from the first app. It's impossible to do that in any acceptable way.
That's how it works. I have not noticed any problems. How would the problems manifest themselves? I'm not an audio expert by any stretch of the imagination, but I think even I would be able to notice skipping, clipping, noise, ... What should I be listening for?
Simple fact is that most soundcards, even if they have a 'mixer', can't mix PCM signals (i.e. signals from the software) - they can mix in a CD player, or an external mic input etc.). So for anything coming from the system there is just one path, which has two controls, the 'PCM' and the 'master'. The only way to correctly use them if there if there is software mixing is to set them once to their correct values (which may depend on what is connected externally), and them leave them alone and do the rest in software.
So that's apparently not how it is done in PA. Why must it be done in this way? How can I verify that there is a problem?
And then we haven't even touched the matter of different sample rates.
It is correct that PA does not (cannot) change the sample rate on the fly. You have to pick one and stick to it (so if you pick the "wrong" one it will resample).
'A lot of meta-information' LOL. It will provide some usually meaningless and inconsistent names of controls, their min and max values, and if you're extremely lucky maybe some indication mapping control values to dB, which may or may not be correct (and if it isn't that's not ALSA's fault, it just crappy and undocumented harware). All of that is visible in alsamixer.
Yes, this is exactly what PA uses. ALAS just displays it without using it.
Yes, absolutely. It may take the user some time to understand the quirks of his soundcard (such as that it's not capable of outputting full digital level without distortion, no matter how the controls are set, or even crappier shortcomings). But he will usually find a way to get things working. Which is impossible without hearing the result. Maybe PA has some magic powers to do that.
It seems to me that PA is much better than this than what I am. I used to struggle with getting my laptop to output the exact volume I wanted without clipping, but now PA does its magic and it just works. I won't claim to know everything about this topic, but I'm interested in hearing more about why you claim that what PA does is impossible. -t
On Sun, 2012-08-12 at 02:43 +0200, Tom Gundersen wrote:
On Sun, Aug 12, 2012 at 1:23 AM, Fons Adriaensen <fons@linuxaudio.org> wrote:
If that is true it is completely wrong from the start. Because that setup can't be maintained when a second app starts playing which can happen at any time. Suppose that first (single) app has its volume set to some low value, and PA uses the soundcard PCM gain control to achieve that as you claim it does. Now suddenly there's a second app which wants a higher level. The only way to achieve that is to raise the hardware gain - you can't compensate for a low setting there by sending a louder signal, it would just clip. So PA now has to adjust the hardware gain and at the same time start scaling down the output from the first app. It's impossible to do that in any acceptable way.
That's how it works. I have not noticed any problems. How would the problems manifest themselves? I'm not an audio expert by any stretch of the imagination, but I think even I would be able to notice skipping, clipping, noise, ... What should I be listening for?
It only can work without clipping, if first the volume is lowered with more headroom than needed, because you can't know how much headroom you exactly need and then the second volume will be raised until an equal level is reached and this step by step. But how does PA know at what step the level is equal, when the audio signal isn't a constant tone? Poettering expect a perfect control values to dB(FS) mapping?! You at least will hear skipping. Or else, Poettering add at the end of the chain a hardcore multi-band compression, which would be very audible and unwanted too.
Simple fact is that most soundcards, even if they have a 'mixer', can't mix PCM signals (i.e. signals from the software) - they can mix in a CD player, or an external mic input etc.). So for anything coming from the system there is just one path, which has two controls, the 'PCM' and the 'master'. The only way to correctly use them if there if there is software mixing is to set them once to their correct values (which may depend on what is connected externally), and them leave them alone and do the rest in software.
So that's apparently not how it is done in PA. Why must it be done in this way? How can I verify that there is a problem?
The analog output level has to fit to the input of your amplifier, to reduce noise and to avoid distortion.
'A lot of meta-information' LOL. It will provide some usually meaningless and inconsistent names of controls, their min and max values, and if you're extremely lucky maybe some indication mapping control values to dB, which may or may not be correct (and if it isn't that's not ALSA's fault, it just crappy and undocumented harware). All of that is visible in alsamixer.
Yes, this is exactly what PA uses. ALAS just displays it without using it.
So PA does use Voodoo?!
On Sun, 2012-08-12 at 03:06 +0200, Ralf Mardorf wrote:
On Sun, 2012-08-12 at 02:43 +0200, Tom Gundersen wrote:
On Sun, Aug 12, 2012 at 1:23 AM, Fons Adriaensen <fons@linuxaudio.org> wrote:
If that is true it is completely wrong from the start. Because that setup can't be maintained when a second app starts playing which can happen at any time. Suppose that first (single) app has its volume set to some low value, and PA uses the soundcard PCM gain control to achieve that as you claim it does. Now suddenly there's a second app which wants a higher level. The only way to achieve that is to raise the hardware gain - you can't compensate for a low setting there by sending a louder signal, it would just clip. So PA now has to adjust the hardware gain and at the same time start scaling down the output from the first app. It's impossible to do that in any acceptable way.
That's how it works. I have not noticed any problems. How would the problems manifest themselves? I'm not an audio expert by any stretch of the imagination, but I think even I would be able to notice skipping, clipping, noise, ... What should I be listening for?
It only can work without clipping, if first the volume is lowered with more headroom than needed, because you can't know how much headroom you exactly need and then the second volume will be raised until an equal level is reached and this step by step. But how does PA know at what step the level is equal, when the audio signal isn't a constant tone? Poettering expect a perfect control values to dB(FS) mapping?! You at least will hear skipping. Or else, Poettering add at the end of the chain a hardcore multi-band compression, which would be very audible and unwanted too.
This is the way how to lower one and to raise another volume for just one signal to keep the loudness, by getting audible steps. But there is a second signal, it's unknown, any automation would be very audible.
Simple fact is that most soundcards, even if they have a 'mixer', can't mix PCM signals (i.e. signals from the software) - they can mix in a CD player, or an external mic input etc.). So for anything coming from the system there is just one path, which has two controls, the 'PCM' and the 'master'. The only way to correctly use them if there if there is software mixing is to set them once to their correct values (which may depend on what is connected externally), and them leave them alone and do the rest in software.
So that's apparently not how it is done in PA. Why must it be done in this way? How can I verify that there is a problem?
The analog output level has to fit to the input of your amplifier, to reduce noise and to avoid distortion.
'A lot of meta-information' LOL. It will provide some usually meaningless and inconsistent names of controls, their min and max values, and if you're extremely lucky maybe some indication mapping control values to dB, which may or may not be correct (and if it isn't that's not ALSA's fault, it just crappy and undocumented harware). All of that is visible in alsamixer.
Yes, this is exactly what PA uses. ALAS just displays it without using it.
So PA does use Voodoo?!
On 08/11/2012 06:15 PM, Tom Gundersen wrote:
On Sun, Aug 12, 2012 at 12:03 AM, Fons Adriaensen <fons@linuxaudio.org> wrote:
So imagine the average desktop user who gets five or so of them:
- one provided by the application (player or something) - one provided by PA or similar, - probably two by the soundcard mixer, PA combines these three into one. So the non-audio-engineer user should have a lot bigger chance of not messing things up with PA compared to with pure ALSA (where you do have to fiddle with all the mixers and the application mixer on top). Sorry if this was what you were trying to point out.
-t
As a non-audio-engineer trying to adjust the sound level in vlc PA keep messing up my sound level (going to full 100%) any time I tried to adjust it. Just ask my wife for conformation as she didn't like the 100% volume every time I adjusted the sound level in vlc or xmms etc. So try to adjust the volume I did.....but wait I'll get it right this time....Turn the damn thing down!!!! She screamed. Ok just let me..... TURN THE DAMN THING OFF!!! Removed PA and only using ALSA equals working properly. As a bonus there is peace in the house ;)
On 11-08-2012 23:33, Baho Utot wrote:
On 08/11/2012 06:15 PM, Tom Gundersen wrote:
On Sun, Aug 12, 2012 at 12:03 AM, Fons Adriaensen <fons@linuxaudio.org> wrote:
So imagine the average desktop user who gets five or so of them:
- one provided by the application (player or something) - one provided by PA or similar, - probably two by the soundcard mixer, PA combines these three into one. So the non-audio-engineer user should have a lot bigger chance of not messing things up with PA compared to with pure ALSA (where you do have to fiddle with all the mixers and the application mixer on top). Sorry if this was what you were trying to point out.
-t
As a non-audio-engineer trying to adjust the sound level in vlc PA keep messing up my sound level (going to full 100%) any time I tried to adjust it. Just ask my wife for conformation as she didn't like the 100% volume every time I adjusted the sound level in vlc or xmms etc. So try to adjust the volume I did.....but wait I'll get it right this time....Turn the damn thing down!!!! She screamed. Ok just let me..... TURN THE DAMN THING OFF!!!
Removed PA and only using ALSA equals working properly. As a bonus there is peace in the house ;)
Did you try flat-volumes = no -- Mauro Santos
On 08/11/2012 07:37 PM, Mauro Santos wrote:
On 11-08-2012 23:33, Baho Utot wrote:
On 08/11/2012 06:15 PM, Tom Gundersen wrote:
On Sun, Aug 12, 2012 at 12:03 AM, Fons Adriaensen <fons@linuxaudio.org> wrote:
So imagine the average desktop user who gets five or so of them:
- one provided by the application (player or something) - one provided by PA or similar, - probably two by the soundcard mixer, PA combines these three into one. So the non-audio-engineer user should have a lot bigger chance of not messing things up with PA compared to with pure ALSA (where you do have to fiddle with all the mixers and the application mixer on top). Sorry if this was what you were trying to point out.
-t As a non-audio-engineer trying to adjust the sound level in vlc PA keep messing up my sound level (going to full 100%) any time I tried to adjust it. Just ask my wife for conformation as she didn't like the 100% volume every time I adjusted the sound level in vlc or xmms etc. So try to adjust the volume I did.....but wait I'll get it right this time....Turn the damn thing down!!!! She screamed. Ok just let me..... TURN THE DAMN THING OFF!!!
Removed PA and only using ALSA equals working properly. As a bonus there is peace in the house ;)
Did you try
flat-volumes = no
No just ripped out PA. That returned me back to what worked for me.
On 12-08-2012 00:41, Baho Utot wrote:
On 08/11/2012 07:37 PM, Mauro Santos wrote:
On 11-08-2012 23:33, Baho Utot wrote:
On 08/11/2012 06:15 PM, Tom Gundersen wrote:
On Sun, Aug 12, 2012 at 12:03 AM, Fons Adriaensen <fons@linuxaudio.org> wrote:
So imagine the average desktop user who gets five or so of them:
- one provided by the application (player or something) - one provided by PA or similar, - probably two by the soundcard mixer, PA combines these three into one. So the non-audio-engineer user should have a lot bigger chance of not messing things up with PA compared to with pure ALSA (where you do have to fiddle with all the mixers and the application mixer on top). Sorry if this was what you were trying to point out.
-t As a non-audio-engineer trying to adjust the sound level in vlc PA keep messing up my sound level (going to full 100%) any time I tried to adjust it. Just ask my wife for conformation as she didn't like the 100% volume every time I adjusted the sound level in vlc or xmms etc. So try to adjust the volume I did.....but wait I'll get it right this time....Turn the damn thing down!!!! She screamed. Ok just let me..... TURN THE DAMN THING OFF!!!
Removed PA and only using ALSA equals working properly. As a bonus there is peace in the house ;)
Did you try
flat-volumes = no
No just ripped out PA. That returned me back to what worked for me.
That might have solved that particular problem. However it is still odd that the default is to have flat-volumes = yes, which causes system wide jumps in volume every single time any app changes its volume. Not very user friendly for something that aims to be easy to use :p. I don't have any complains with the machine I use now though. -- Mauro Santos
On Sun, 2012-08-12 at 00:15 +0200, Tom Gundersen wrote:
On Sun, Aug 12, 2012 at 12:03 AM, Fons Adriaensen <fons@linuxaudio.org> wrote:
So imagine the average desktop user who gets five or so of them:
- one provided by the application (player or something) - one provided by PA or similar, - probably two by the soundcard mixer,
PA combines these three into one. So the non-audio-engineer user should have a lot bigger chance of not messing things up with PA compared to with pure ALSA (where you do have to fiddle with all the mixers and the application mixer on top). Sorry if this was what you were trying to point out.
Pff! http://www.freedesktop.org/wiki/Software/PulseAudio/Backends/ALSA/Decibel "Muahaha. Mauahahahahah!" - Lennart Poettering Regards, Ralf
On Fri, 2012-08-10 at 23:50 +0800, Oon-Ee Ng wrote:
Oh, and very few people actually use simple stereo audio chips, the majority of people use multi channel audio cards to listen to their YouTube.
Puleaudio doesn't work for many people simply using stereo with on-board devices. We are living in the mass media age, so "multi channel cards" are not that seldom, resp. stereo cards with better sound quality, that are based on microchips such as the Envy24.
On Aug 10, 2012 6:09 PM, "Ralf Mardorf" <ralf.mardorf@alice-dsl.net> wrote:
On Fri, 2012-08-10 at 23:50 +0800, Oon-Ee Ng wrote:
Oh, and very few people actually use simple stereo audio chips, the majority of people use multi channel audio cards to listen to their YouTube.
Puleaudio doesn't work for many people simply using stereo with on-board devices. We are living in the mass media age, so "multi channel cards" are not that seldom, resp. stereo cards with better sound quality, that are based on microchips such as the Envy24.
Please guys, not again... Take your concerns upstream, nothing will come off rehashing them here for the hundredths time. Tom
Am Fri, 10 Aug 2012 18:27:33 +0200 schrieb Tom Gundersen <teg@jklm.no>:
Please guys, not again...
Take your concerns upstream, nothing will come off rehashing them here for the hundredths time.
Those concerns have been reported upstream a long while ago. They are just ignored resp. upstream doesn't have any better to do than to blaming ALSA even if ALSA supports those audio cards perfectly out-of-the-box. Then PA upstream has written an obscure ALSA configuration which crippled those cards down to simple stereo cards and closed the bug report as fixed even if this is not even a dirty workaround. Now, after a lot of discussions on several mailing lists, they suddenly say that PA is only meant for desktop purposes, but not for professional audio. On the other hand they do everything to make it a pseudo standard. And systemd seems to be similar. I also don't like that you want to imprint this systemd stuff everybody even if one doesn't have systemd installed. See systemd-tools and systemd-cryptsetup. Well, I know that you filed the issue about reading the key rawly from a block device to upstream. But they did forgot it. What else did they forget? I have the impression that Lennart only thinks halfway through and doesn't have much knowledge about professional computer and UNIX usage. Maybe his ideas have some good aspects, but he simply can't implement it professionally and in a UNIX style. He seems to only think about desktop users but definitely not about (semi-)professional users. And run a `ls /usr/lib/systemd/system`. The harddisk is filled up with a bunch of systemd stuff which I don't need and don't want to have. But I am forced to have at least half of systemd on my harddisk, even if I don't want to have systemd. Just a few concerns which not only belong to upstream. And, no. The software does not or at least should not ripen at the users, at least not so much as it needs to with Poetterix. Heiko
On Fri, 2012-08-10 at 21:43 +0200, Heiko Baums wrote:
And run a `ls /usr/lib/systemd/system`. The harddisk is filled up with a bunch of systemd stuff which I don't need and don't want to have.
Hm? IIRC console-kit has a replacement when using systemd, so those and perhaps other files perhaps have nothing to do with systemd? spinymouse@precise:~$ ls -hl /mnt/archlinux/usr/lib/systemd/system/console* -rw-r--r-- 1 root root 432 May 27 06:29 /mnt/archlinux/usr/lib/systemd/system/console-kit-daemon.service -rw-r--r-- 1 root root 219 May 27 06:29 /mnt/archlinux/usr/lib/systemd/system/console-kit-log-system-restart.service -rw-r--r-- 1 root root 201 May 27 06:29 /mnt/archlinux/usr/lib/systemd/system/console-kit-log-system-start.service -rw-r--r-- 1 root root 218 May 27 06:29 /mnt/archlinux/usr/lib/systemd/system/console-kit-log-system-stop.service *?*
On Fri, 2012-08-10 at 22:04 +0200, Ralf Mardorf wrote:
On Fri, 2012-08-10 at 21:43 +0200, Heiko Baums wrote:
And run a `ls /usr/lib/systemd/system`. The harddisk is filled up with a bunch of systemd stuff which I don't need and don't want to have.
Hm? IIRC console-kit has a replacement when using systemd, so those and perhaps other files perhaps have nothing to do with systemd?
spinymouse@precise:~$ ls -hl /mnt/archlinux/usr/lib/systemd/system/console* -rw-r--r-- 1 root root 432 May 27 06:29 /mnt/archlinux/usr/lib/systemd/system/console-kit-daemon.service -rw-r--r-- 1 root root 219 May 27 06:29 /mnt/archlinux/usr/lib/systemd/system/console-kit-log-system-restart.service -rw-r--r-- 1 root root 201 May 27 06:29 /mnt/archlinux/usr/lib/systemd/system/console-kit-log-system-start.service -rw-r--r-- 1 root root 218 May 27 06:29 /mnt/archlinux/usr/lib/systemd/system/console-kit-log-system-stop.service
*?*
PS: Any explanations are welcome, seemingly those are systemd files. spinymouse@precise:~$ cat /mnt/archlinux/usr/lib/systemd/system/console-kit-log-system-start.service [Unit] Description=Console System Startup Logging DefaultDependencies=no After=sysinit.target Before=shutdown.target [Service] Type=oneshot ExecStart=/usr/sbin/ck-log-system-start RemainAfterExit=yes
Systemd and pulseaudio are completely different pieces of software with different purposes. Comparing them like that just because of the author is comparing apples to oranges. On Fri, Aug 10, 2012 at 3:43 PM, Heiko Baums <lists@baums-on-web.de> wrote:
Am Fri, 10 Aug 2012 18:27:33 +0200 schrieb Tom Gundersen <teg@jklm.no>:
Please guys, not again...
Take your concerns upstream, nothing will come off rehashing them here for the hundredths time.
Those concerns have been reported upstream a long while ago. They are just ignored resp. upstream doesn't have any better to do than to blaming ALSA even if ALSA supports those audio cards perfectly out-of-the-box.
Then PA upstream has written an obscure ALSA configuration which crippled those cards down to simple stereo cards and closed the bug report as fixed even if this is not even a dirty workaround.
Now, after a lot of discussions on several mailing lists, they suddenly say that PA is only meant for desktop purposes, but not for professional audio. On the other hand they do everything to make it a pseudo standard.
And systemd seems to be similar. I also don't like that you want to imprint this systemd stuff everybody even if one doesn't have systemd installed. See systemd-tools and systemd-cryptsetup. Well, I know that you filed the issue about reading the key rawly from a block device to upstream. But they did forgot it. What else did they forget? I have the impression that Lennart only thinks halfway through and doesn't have much knowledge about professional computer and UNIX usage. Maybe his ideas have some good aspects, but he simply can't implement it professionally and in a UNIX style. He seems to only think about desktop users but definitely not about (semi-)professional users.
And run a `ls /usr/lib/systemd/system`. The harddisk is filled up with a bunch of systemd stuff which I don't need and don't want to have. But I am forced to have at least half of systemd on my harddisk, even if I don't want to have systemd.
Just a few concerns which not only belong to upstream.
And, no. The software does not or at least should not ripen at the users, at least not so much as it needs to with Poetterix.
Heiko
Am Fri, 10 Aug 2012 16:33:39 -0400 schrieb Brandon Watkins <bwat47@gmail.com>:
Systemd and pulseaudio are completely different pieces of software with different purposes. Comparing them like that just because of the author is comparing apples to oranges.
Sorry, it is not. I see that PA is totally not complete and doesn't support at least half of the professional use cases. And I see that it's the same with systemd. So what's the difference? They are both developed by the same person who seemingly doesn't have much knowledge about professional computer usage and only cares about some desktop users. With PA it's currently not such a problem since I don't need to use a distro or a desktop environment which forces me to install PA. With systemd it's worse since the init system is a very serious and important piece of the system. And if this doesn't support every professional use case and isn't proved to be really reliable, it just shouldn't be made to a de facto standard. And if I can't trust PA how can I trust an even more important piece of software written by the same person? Btw., look at systemd-cryptsetup. Yes, meanwhile my use case is filed upstream and allegedly and hopefully fixed. But it shows that at least one use case was just forgotten or in other words it was not well enough thought out. The latter is the biggest problem. Like I said before, some of Lennart's ideas may, say, seem to be quite interesting, and maybe sysvinit is also not the perfect init system. But Lennart's software is just not implemented good enough. If somebody doesn't care about the professional users when writing on software, would he really care about the professional users when writing the other software? I really haven't seen so many and so long discussions and so many concerns and very negative opinions about a software than I have seen about Lennart's software. And I'm not only reading this mailing list. See e.g. pro-linux.de or heise.de (both in German). Every time when there's an article about PA or systemd a lot of people are railing against PA, systemd and Lennart. And it's definitely not only me. There must be a reason, and the reasons are always mentioned. There are bug reports upstream, but they are just ignored. Lennart mentions all those "rants" in at least one of his documentations. So he even knows about all those criticisms. What's he doing? He ignores them totally. In the same sentence he just laughs at those people, and call them so to say (not literally) stupid. Is this really a good and trustworthy attitude? I think, not. And all those comments here like "oh no, not this again", "Please guys, not again..." or "Take your concerns upstream, ...", is really not helpful. On the contrary this all is also an issue for downstream. See the ongoing infiltration of initscripts by systemd here in Arch Linux. Sorry to say that, but it's really not the best idea. Keep PA and systemd totally optional including every part of it, and everything is Ok. I'm sure nobody would mind. But as long as there are people working on making both software a de facto standard and forcing it on everybody, this discussion will never end. Not only here. Just take all those people who have a lot of concerns for some very good reasons serious. There wouldn't be so many, so long discussions every time PA, systemd or Lennart Poettering is mentioned if this all was such a very good, perfect and professional software. If this was the case then I'm sure that everybody couldn't wait to get it and a lot of people would ask when it will be available. Instead a lot of people on the web rail against them. So think about that, and think long and good. Maybe there are a few use cases for which PA is working and for which PA makes sense. But there are a lot of use cases for which PA does not work. The same for systemd. So think about the use cases for which they don't work. Btw., someone else here on this mailing list has mentioned a lot of software which, as he said, do the same as systemd does allegedly better than sysvinit, but on top of sysvinit and in a more UNIX like way. There came not even one word, one short discussion about those suggestions. It was not considered if those software could be the better alternative. Instead the systemd fanboys kept on hyping systemd. If you buy a book at Amazon e.g., what do you read? Only the best 5-star reviews or also the 1-star reviews? I tell you something. Not always but a lot of times the fewer 1-star reviews are the better and more realistic ones. Heiko
Am Fri, 10 Aug 2012 23:38:15 +0200 schrieb Heiko Baums <lists@baums-on-web.de>:
I really haven't seen so many and so long discussions and so many concerns and very negative opinions about a software than I have seen about Lennart's software. And I'm not only reading this mailing list. See e.g. pro-linux.de or heise.de (both in German). Every time when there's an article about PA or systemd a lot of people are railing against PA, systemd and Lennart. And it's definitely not only me.
That said, nearly every comment on heise.de against PA, systemd and Lennart Poettering gets a lot of green, and heise is very well known IT publisher and has a lot of readers. Also such comments on pro-linux.de get regularly a lot of approval and positive feedback. Heiko
On Fri, Aug 10, 2012 at 11:38 PM, Heiko Baums <lists@baums-on-web.de> wrote:
If you buy a book at Amazon e.g., what do you read? Only the best 5-star reviews or also the 1-star reviews? I tell you something. Not always but a lot of times the fewer 1-star reviews are the better and more realistic ones.
I prefer the reviews (good or bad) from someone who has actually read the book. -t
Am Sat, 11 Aug 2012 00:57:46 +0200 schrieb Tom Gundersen <teg@jklm.no>:
I prefer the reviews (good or bad) from someone who has actually read the book.
You can usually assume that everybody who writes a review has actually read the book. Heiko
On Fri, 10 Aug 2012 23:38:15 +0200 Heiko Baums <lists@baums-on-web.de> wrote:
Am Fri, 10 Aug 2012 16:33:39 -0400 schrieb Brandon Watkins <bwat47@gmail.com>:
Systemd and pulseaudio are completely different pieces of software with different purposes. Comparing them like that just because of the author is comparing apples to oranges.
Sorry, it is not. I see that PA is totally not complete and doesn't support at least half of the professional use cases. And I see that it's the same with systemd. So what's the difference?
They are both developed by the same person who seemingly doesn't have much knowledge about professional computer usage and only cares about some desktop users.
With PA it's currently not such a problem since I don't need to use a distro or a desktop environment which forces me to install PA.
With systemd it's worse since the init system is a very serious and important piece of the system. And if this doesn't support every professional use case and isn't proved to be really reliable, it just shouldn't be made to a de facto standard.
And if I can't trust PA how can I trust an even more important piece of software written by the same person?
Btw., look at systemd-cryptsetup. Yes, meanwhile my use case is filed upstream and allegedly and hopefully fixed. But it shows that at least one use case was just forgotten or in other words it was not well enough thought out. The latter is the biggest problem.
Like I said before, some of Lennart's ideas may, say, seem to be quite interesting, and maybe sysvinit is also not the perfect init system. But Lennart's software is just not implemented good enough.
And here I thought that there were some SuSE people from udev team behind systemd... Do we always have to get personal?
If somebody doesn't care about the professional users when writing on software, would he really care about the professional users when writing the other software?
AFAICT professional = constructive: if you find a problem there is no point in admiring yourself and calling everyone else morons, help fixing it instead. Otherwise, please show me a piece of software which is free of bugs.
I really haven't seen so many and so long discussions and so many concerns and very negative opinions about a software than I have seen about Lennart's software. And I'm not only reading this mailing list. See e.g. pro-linux.de or heise.de (both in German). Every time when there's an article about PA or systemd a lot of people are railing against PA, systemd and Lennart. And it's definitely not only me.
Seems to me that some people have way too much free time...
There must be a reason, and the reasons are always mentioned. There are bug reports upstream, but they are just ignored. Lennart mentions all those "rants" in at least one of his documentations. So he even knows about all those criticisms. What's he doing? He ignores them totally. In the same sentence he just laughs at those people, and call them so to say (not literally) stupid.
Is this really a good and trustworthy attitude? I think, not.
And all those comments here like "oh no, not this again", "Please guys, not again..." or "Take your concerns upstream, ...", is really not helpful. On the contrary this all is also an issue for downstream. See the ongoing infiltration of initscripts by systemd here in Arch Linux. Sorry to say that, but it's really not the best idea.
And do you think it's a good idea to spam my inbox? Ah, right, I should unsubscribe.
Keep PA and systemd totally optional including every part of it, and everything is Ok. I'm sure nobody would mind. But as long as there are people working on making both software a de facto standard and forcing it on everybody, this discussion will never end. Not only here.
Noone is forcing anything on anyone...
Just take all those people who have a lot of concerns for some very good reasons serious.
Examples welcome...
There wouldn't be so many, so long discussions every time PA, systemd or Lennart Poettering is mentioned if this all was such a very good, perfect and professional software. If this was the case then I'm sure that everybody couldn't wait to get it and a lot of people would ask when it will be available. Instead a lot of people on the web rail against them. So think about that, and think long and good.
Maybe there are a few use cases for which PA is working and for which PA makes sense. But there are a lot of use cases for which PA does not work. The same for systemd. So think about the use cases for which they don't work.
Btw., someone else here on this mailing list has mentioned a lot of software which, as he said, do the same as systemd does allegedly better than sysvinit, but on top of sysvinit and in a more UNIX like way. There came not even one word, one short discussion about those suggestions. It was not considered if those software could be the better alternative. Instead the systemd fanboys kept on hyping systemd.
That was Gentoo's OpenRC. Except the "Unix-like philosophy" (with the emphasis on philosophy) what is the fundamental difference between the two?
If you buy a book at Amazon e.g., what do you read? Only the best 5-star reviews or also the 1-star reviews? I tell you something. Not always but a lot of times the fewer 1-star reviews are the better and more realistic ones.
I don't read reviews because relevant people you should listen to are too busy to write them.
Heiko
-- Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
On Sat, 11 Aug 2012 00:59:25 +0200, Leonid Isaev <lisaev@umail.iu.edu> wrote:
Do we always have to get personal?
Seems to me that some people have way too much free time...
And do you think it's a good idea to spam my inbox? Ah, right, I should unsubscribe.
I don't read reviews because relevant people you should listen to are too busy to write them.
Yes, everybody who mentions cons about system relevant broken software has to much time. Perhaps important, relevant people would have more time too, if they wouldn't use borked, system relevant software ;). This kind of argumentation IMO is more near to spam, then to mention again and again, that pulseaudio is a serious issue and people fear that systemd will become a serious issue too. Some people don't have the time to test and brake their Linux, that doesn't mean that people with enough free time are losers, IMO somebody who doesn't have enough free time should learn to manage the live better. I just wonder why a discussion needs to become that personal. Heiko didn't become personal. Writing about somebody who does hardcore public relations is something completely different, than defamation of people who might have too much free time, just because they have another opinion or read the book reviews of people that aren't that smart, as the people you would listen too. Why not simply stopping that discussion, instead of feeding it with such a defamation? :) Ralf
On 10/08/12 23:38, Heiko Baums wrote:
Am Fri, 10 Aug 2012 16:33:39 -0400 schrieb Brandon Watkins <bwat47@gmail.com>:
Systemd and pulseaudio are completely different pieces of software with different purposes. Comparing them like that just because of the author is comparing apples to oranges.
Sorry, it is not. I see that PA is totally not complete and doesn't support at least half of the professional use cases. And I see that it's the same with systemd. So what's the difference?
They are both developed by the same person who seemingly doesn't have much knowledge about professional computer usage and only cares about some desktop users.
With PA it's currently not such a problem since I don't need to use a distro or a desktop environment which forces me to install PA.
With systemd it's worse since the init system is a very serious and important piece of the system. And if this doesn't support every professional use case and isn't proved to be really reliable, it just shouldn't be made to a de facto standard.
And if I can't trust PA how can I trust an even more important piece of software written by the same person?
Btw., look at systemd-cryptsetup. Yes, meanwhile my use case is filed upstream and allegedly and hopefully fixed. But it shows that at least one use case was just forgotten or in other words it was not well enough thought out. The latter is the biggest problem.
Like I said before, some of Lennart's ideas may, say, seem to be quite interesting, and maybe sysvinit is also not the perfect init system. But Lennart's software is just not implemented good enough.
If somebody doesn't care about the professional users when writing on software, would he really care about the professional users when writing the other software?
Sure soon RHEL will switch to systemd with RHEL 7, so the systemd market share will probably continue to grow. Also SUSE seems to switch to systemd. With these major distro's taking up systemd, it's almost impossible that it's not implemented good enough. p.s. it's a bit lame to just blame Poettering since for everything he just iirc the maintainer of systemd. Since there are much more people behind systemd ( Kay sievers, etc. )
On Sat, 2012-08-11 at 09:56 +0200, Jelle van der Waa wrote:
Sure soon RHEL will switch to systemd with RHEL 7, so the systemd market share will probably continue to grow. Also SUSE seems to switch to systemd. With these major distro's taking up systemd, it's almost impossible that it's not implemented good enough.
Hm? Suse was the first distro I used, for good reasons I'm using other distros for serious work today. However, from time to time I install Suse, currently it's the outdated Suse 11.2. For my needs Suse often is much to unstable. I know an important Linux audio coder who is using Linux for serious work. Perhaps he simply has got more knowledge to set up Suse, different hardware and different needs.
p.s. it's a bit lame to just blame Poettering since for everything he just iirc the maintainer of systemd. Since there are much more people behind systemd ( Kay sievers, etc. )
But who does aggressive public relations? Nobody, but Poettering. On Sat, 2012-08-11 at 08:15 +0200, Guus Snijders wrote: Op 11 aug. 2012 03:02 schreef "Tom Gundersen" <teg@jklm.no> het volgende:
To be clear: it has always been my plan to make initscripts and systemd as close to each other as possible and share as much code as possible. I strongly believe this is the right thing to do. If you disagree, then I think your time is better spent at coding a replacement rather than at whining.
Just for the record Tom: some of us are very happy with your work on continuening Initscripts. It sometimes looks as if 'everyone' feels they must switch to pure systemd, I for one prefer the predictability of init.
I agree that it's a good work, when he tries to give users the choice. I wonder why it's not wanted that people discuss major changes. On another list some people don't want that the default DE for a distro will become another DE. I like the switch to that other DE, but for me there's no need to rant against those who'll keep the DE that was used in the past. However, some people from that list rant against those people, they want them to stop discussing that on this USER LIST. IMO the best place for a discussion is a USER LIST. If there's a result, it can be reported to the relevant people. We often talk about "the most people". Is there anything bad with marginalized groups, people that might not be able to contribute to Linux, but perhaps those contribute to other useful things? I wonder about the definition of the word "community". Seemingly people don't read why people have issues and that people e.g. reported issues, since they always ask to report an issue to another place, to contribute, to pay somebody, not to forget at some point people are just stupid, have to much time etc.. "Community"? Regards, Ralf
On Sat, 2012-08-11 at 12:52 +0200, Ralf Mardorf wrote:
On Sat, 2012-08-11 at 09:56 +0200, Jelle van der Waa wrote:
Sure soon RHEL will switch to systemd with RHEL 7, so the systemd market share will probably continue to grow. Also SUSE seems to switch to systemd. With these major distro's taking up systemd, it's almost impossible that it's not implemented good enough.
Hm? Suse was the first distro I used, for good reasons I'm using other distros for serious work today. However, from time to time I install Suse, currently it's the outdated Suse 11.2. For my needs Suse often is much to unstable. I know an important Linux audio coder who is using Linux for serious work. Perhaps he simply has ^^^^^^Suse Linux got more knowledge to set up Suse, different hardware and different needs.
A typo, I suspect this could lead to "misunderstandings", so I feel the need to correct it.
Am Sat, 11 Aug 2012 09:56:49 +0200 schrieb Jelle van der Waa <jelle@vdwaa.nl>:
Sure soon RHEL will switch to systemd with RHEL 7, so the systemd market share will probably continue to grow. Also SUSE seems to switch to systemd. With these major distro's taking up systemd, it's almost impossible that it's not implemented good enough.
Then, why are there regularly so many, so long discussions on the web? And most of them are not started by me, and I don't even participate in a lot of them. And why are all those critical comments about PA, systemd, and Lennart Poettering marked green by so many people? Why is Lennart Poettering's software the only software about which there are so many discussions? Really because it's so damn good? I don't know what's going on behind the scenes of all those major distros. So I don't know how big Lennart's or someone else's influence is. But I think it's a mistake to switch to systemd. Well, offering it optionally, would be no problem. Speaking of which, I doubt that the RHEL and SUSE users care this much about the init system and the system internals as Arch Linux users do.
p.s. it's a bit lame to just blame Poettering since for everything he just iirc the maintainer of systemd. Since there are much more people behind systemd ( Kay sievers, etc. )
I know that Poettering is not the only one behind systemd and PA, but it was his idea and he still is the maintainer. So it's still his software. Heiko
On Sat, 11 Aug 2012 14:16:46 +0200 Heiko Baums <lists@baums-on-web.de> wrote:
Am Sat, 11 Aug 2012 09:56:49 +0200 schrieb Jelle van der Waa <jelle@vdwaa.nl>:
Sure soon RHEL will switch to systemd with RHEL 7, so the systemd market share will probably continue to grow. Also SUSE seems to switch to systemd. With these major distro's taking up systemd, it's almost impossible that it's not implemented good enough.
Then, why are there regularly so many, so long discussions on the web? And most of them are not started by me, and I don't even participate in a lot of them. And why are all those critical comments about PA, systemd, and Lennart Poettering marked green by so many people?
Why is Lennart Poettering's software the only software about which there are so many discussions? Really because it's so damn good?
I think you are forgetting that linux-based OS market usage is <1.0%. So by the same logic, why do so many people prefer NOT to use these OSs, because they are so good? Are those people all idiots? Sometimes numbers don't mean much...
I don't know what's going on behind the scenes of all those major distros. So I don't know how big Lennart's or someone else's influence is. But I think it's a mistake to switch to systemd. Well, offering it optionally, would be no problem.
Right, all evil in this world comes from Glass, Apples and... LP. BTW, last time I checked, opensuse had pretty vast public dev ML.
Speaking of which, I doubt that the RHEL and SUSE users care this much about the init system and the system internals as Arch Linux users do.
p.s. it's a bit lame to just blame Poettering since for everything he just iirc the maintainer of systemd. Since there are much more people behind systemd ( Kay sievers, etc. )
I know that Poettering is not the only one behind systemd and PA, but it was his idea and he still is the maintainer. So it's still his software.
Heiko
-- Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
I think you are forgetting that linux-based OS market usage is <1.0%. So by the same logic, why do so many people prefer NOT to use these OSs, because they are so good? Are those people all idiots? Sometimes numbers don't mean much...
I guess you mean Linux-based desktop OS market usage. Linux runs on many more computer chips than windows and even Microsoft uses linux web servers. -- _______________________________________________________________________ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) _______________________________________________________________________
On Fri, Aug 10, 2012 at 9:43 PM, Heiko Baums <lists@baums-on-web.de> wrote: [snip: lots of whining about pulse audio] This is not the right mailinglist for this issue. And this certainly is not the right thread for it.
And systemd seems to be similar. I also don't like that you want to imprint this systemd stuff everybody even if one doesn't have systemd installed.
You are free to reimplement all those tools and ship a competing package. The configuration formats are well-documented, so it should not be hard.
See systemd-tools and systemd-cryptsetup. Well, I know that you filed the issue about reading the key rawly from a block device to upstream. But they did forgot it.
What are you talking about? No one forgot anything. This is what happened: You pointed out a feature that initsrcipts used to have which systemd-cryptsetup lacked, (on the same day) I posted a patch to implement the feature you requested, and asked for feedback (which you didn't give), one week later I posted the patch upstream and (on the same day) Lennart replied: "Applied." The functionality should now be part of systemd 188, which is in testing. What more could you possibly ask for?
I have the impression that Lennart only thinks halfway through and doesn't have much knowledge about professional computer and UNIX usage. Maybe his ideas have some good aspects, but he simply can't implement it professionally and in a UNIX style. He seems to only think about desktop users but definitely not about (semi-)professional users.
I have the impression that you don't have a clue what you are talking about.
And run a `ls /usr/lib/systemd/system`. The harddisk is filled up with a bunch of systemd stuff which I don't need and don't want to have. But I am forced to have at least half of systemd on my harddisk, even if I don't want to have systemd.
Why don't you just delete the things you don't want? -t
On Sat, 11 Aug 2012 00:56:33 +0200, Tom Gundersen <teg@jklm.no> wrote:
On Fri, Aug 10, 2012 at 9:43 PM, Heiko Baums <lists@baums-on-web.de>
/usr/lib/systemd/system
Why don't you just delete the things you don't want?
When not using systemd, is it ok to delete /usr/lib/systemd completely? Is it ok to replace libsystemd (or what ever is installed by dependencies) with a dummy-package? I'm not booted to Arch yet, so I don't know what exactly is installed. IMO dummy-packages are the best choice, if possible. E.g. regarding to pulseaudio the package https://aur.archlinux.org/packages.php?ID=48718 isn't maintained anymore. I never used it, but directly build a pulseaudio dummy package, but IIRC libpulse still must be installed. Why should somebody maintain a package, when dummy packages does the same job? However, it's not that easy to know what is and what isn't needed. Regards, Ralf
On Sat, Aug 11, 2012 at 1:15 AM, Ralf Mardorf <ralf.mardorf@alice-dsl.net> wrote:
When not using systemd, is it ok to delete /usr/lib/systemd completely?
No, initscripts uses a lot of stuff in there.
Is it ok to replace libsystemd (or what ever is installed by dependencies) with a dummy-package? I'm not booted to Arch yet, so I don't know what exactly is installed.
No. Lots of stuff links against libsystemd. -t
On Sat, 11 Aug 2012 01:27:43 +0200, Tom Gundersen <teg@jklm.no> wrote:
On Sat, Aug 11, 2012 at 1:15 AM, Ralf Mardorf <ralf.mardorf@alice-dsl.net> wrote:
When not using systemd, is it ok to delete /usr/lib/systemd completely?
No, initscripts uses a lot of stuff in there.
Is it ok to replace libsystemd (or what ever is installed by dependencies) with a dummy-package? I'm not booted to Arch yet, so I don't know what exactly is installed.
No. Lots of stuff links against libsystemd.
Thank you :) FWIW I can live with those few bytes more, it's only important that everything still is stable and fortunately it is stable. Apologize for the noise about Poettering, but some people and I are simply scary that we soon or later run into serious issues at the most worse time. Regards, Ralf
On Sat, 11 Aug 2012 01:15:32 +0200 "Ralf Mardorf" <ralf.mardorf@alice-dsl.net> wrote:
On Sat, 11 Aug 2012 00:56:33 +0200, Tom Gundersen <teg@jklm.no> wrote:
On Fri, Aug 10, 2012 at 9:43 PM, Heiko Baums <lists@baums-on-web.de>
/usr/lib/systemd/system
Why don't you just delete the things you don't want?
When not using systemd, is it ok to delete /usr/lib/systemd completely? Is it ok to replace libsystemd (or what ever is installed by dependencies) with a dummy-package? I'm not booted to Arch yet, so I don't know what exactly is installed.
IMO dummy-packages are the best choice, if possible.
E.g. regarding to pulseaudio the package https://aur.archlinux.org/packages.php?ID=48718 isn't maintained anymore. I never used it, but directly build a pulseaudio dummy package, but IIRC libpulse still must be installed. Why should somebody maintain a package, when dummy packages does the same job?
However, it's not that easy to know what is and what isn't needed.
Look, you don't _have_ to use pacman to manage software. As I said elsewhere, dependencies on pulse, lirc, etc. are there for a reason. If you disagree with this reason, file a bugreport. But using dummy packages is just cheating.
Regards, Ralf
-- Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
On Sat, 11 Aug 2012 02:03:51 +0200, Leonid Isaev <lisaev@umail.iu.edu> wrote:
If you disagree file a bugreport.
Any hints where to file a bug report are welcome. Seemingly nobody is interested, as already explained by Heiko.
But using dummy packages is just cheating.
So I should do audio productions with a Linux, that is unable to use my audio card? How should I do this? Regards, Ralf
On Sat, 11 Aug 2012 02:14:25 +0200 "Ralf Mardorf" <ralf.mardorf@alice-dsl.net> wrote:
On Sat, 11 Aug 2012 02:03:51 +0200, Leonid Isaev <lisaev@umail.iu.edu> wrote:
If you disagree file a bugreport.
Any hints where to file a bug report are welcome. Seemingly nobody is interested, as already explained by Heiko.
You could talk to the respective package maintainers...
But using dummy packages is just cheating.
So I should do audio productions with a Linux, that is unable to use my audio card? How should I do this?
Audio production? All I said that you should learn how package management works on linux.
Regards, Ralf
-- Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
On Sat, 11 Aug 2012 02:20:12 +0200, Leonid Isaev <lisaev@umail.iu.edu> wrote:
On Sat, 11 Aug 2012 02:14:25 +0200 "Ralf Mardorf" <ralf.mardorf@alice-dsl.net> wrote:
On Sat, 11 Aug 2012 02:03:51 +0200, Leonid Isaev <lisaev@umail.iu.edu> wrote:
If you disagree file a bugreport.
Any hints where to file a bug report are welcome. Seemingly nobody is interested, as already explained by Heiko.
You could talk to the respective package maintainers...
Maintainers for what package/packages?
But using dummy packages is just cheating.
So I should do audio productions with a Linux, that is unable to use my audio card? How should I do this?
Audio production? All I said that you should learn how package management works on linux.
What exactly do I need to learn? Regards, Ralf
On 11 Aug 2012 08:14, "Ralf Mardorf" <ralf.mardorf@alice-dsl.net> wrote:
But using dummy packages is just cheating.
So I should do audio productions with a Linux, that is unable to use my audio card? How should I do this?
Regards, Ralf
By installing a distro that doesn't force you to use pulseaudio. Oh wait, that's Arch.
On Sat, 2012-08-11 at 13:05 +0800, Oon-Ee Ng wrote:
On 11 Aug 2012 08:14, "Ralf Mardorf" <ralf.mardorf@alice-dsl.net> wrote:
But using dummy packages is just cheating.
So I should do audio productions with a Linux, that is unable to use my audio card? How should I do this?
Regards, Ralf
By installing a distro that doesn't force you to use pulseaudio. Oh wait, that's Arch.
And whats bad with building a dummy package, if I wish to use packages with pulseaudio dependencies? On Sat, 2012-08-11 at 09:45 +0200, Jelle van der Waa wrote:
Have you ever tried to report your problems with PA and your soundcard to upstream?
Have you ever really read what people wrote and why we are against it? Regards, Ralf
On 11 Aug 2012 18:53, "Ralf Mardorf" <ralf.mardorf@alice-dsl.net> wrote:
On Sat, 2012-08-11 at 09:45 +0200, Jelle van der Waa wrote:
Have you ever tried to report your problems with PA and your soundcard to upstream?
Have you ever really read what people wrote and why we are against it?
Regards, Ralf
And you're dissatisfied that the Envy chipset isn't supported, even though the project's stated goal is desktop users (translation stereo only). You may disagree with that goal and their definition, but the traditional solution to that is to get coding. Complaining doesn't change anyone's minds, especially when you use hyperbole (most users etc)
On Sat, 2012-08-11 at 19:14 +0800, Oon-Ee Ng wrote:
On 11 Aug 2012 18:53, "Ralf Mardorf" <ralf.mardorf@alice-dsl.net> wrote:
On Sat, 2012-08-11 at 09:45 +0200, Jelle van der Waa wrote:
Have you ever tried to report your problems with PA and your soundcard to upstream?
Have you ever really read what people wrote and why we are against it?
Regards, Ralf
And you're dissatisfied that the Envy chipset isn't supported, even though the project's stated goal is desktop users (translation stereo only).
Personally I don't care for the Envy24 chip, since my audio card for sure has a much better hardware mixer. It's just that Envy24 cards are widespread, since those are cheap and they usually are better than onboard devices and many are stereo only. My Envy24 cards are for MIDI only. On non-audio user mailing lists there are often requests regarding to "no sound". In the end "most of the times" it's pulseaudio that breaks audio for desktop users. Btw. do consumer nowadays not usually need 5.1 instead of stereo?
You may disagree with that goal and their definition, but the traditional solution to that is to get coding.
Today still most coders are interested that they don't break something. The coder we are talking about claims that the ALSA drivers are borked and similar strange things, when users report issues. IMO it's the task of this coder to rewrite the drivers, when those won't work with his software, since the drivers do work without his software.
Complaining doesn't change anyone's minds, especially when you use hyperbole (most users etc)
So most computer users do not use other operating systems? There are several reasons for this, pulseaudio isn't the only reason, but it has got much weight. To shut up won't change the situation. Btw. I'm not complaining only, I fix all my Linux installs and I help other people to fix their installs. But when I say using a dummy package will solve issues, than it's also not ok. Why don't ship distros with dummy packages for pulseaudio? I never noticed that a dummy package did break something, but even if it should break something, at least there are more advantages for those who can't use pulseaudio, due to their hardware. Today users have the choice to use DEs that don't need pulseaudio, but if we would be quiet, perhaps one DE after the other would make pulseaudio a dependency. Noise is part of how communities work. Silence would cause stagnation. Words about "most people" of cause belong to my broken English, if you like we could continue in German. I already said, that marginalized groups are important. However, I'll read what ever you'll write + I'll reflect deeply about your words, but I guess I've nothing to add to this topic at the moment myself. Regards, Ralf
On 11/08/12 02:14, Ralf Mardorf wrote:
On Sat, 11 Aug 2012 02:03:51 +0200, Leonid Isaev <lisaev@umail.iu.edu> wrote:
If you disagree file a bugreport.
Any hints where to file a bug report are welcome. Seemingly nobody is interested, as already explained by Heiko.
But using dummy packages is just cheating.
So I should do audio productions with a Linux, that is unable to use my audio card? How should I do this?
Regards, Ralf Have you ever tried to report your problems with PA and your soundcard to upstream?
-- Jelle van der Waa
Am Sat, 11 Aug 2012 09:45:34 +0200 schrieb Jelle van der Waa <jelle@vdwaa.nl>:
Have you ever tried to report your problems with PA and your soundcard to upstream?
How many times does it have to be said, that there are bug reports filed to upstream which have been ignored by upstream resp. which have been closed as fixed by first blaming ALSA for the PA problems, even if ALSA supports those cards perfectly out-of-the-box since years, then writing an obscure ALSA configuration which cripples those cards to simple stereo cards and now, after many discussions like this one, they suddenly say that PA is only meant for desktop purposes and not for professional purposes? How often does this have to be mentioned? Heiko
On Sat, Aug 11, 2012 at 01:35:10PM +0200, Heiko Baums wrote:
How many times does it have to be said, that there are bug reports filed to upstream which have been ignored by upstream resp. which have been closed as fixed by first blaming ALSA for the PA problems, even if ALSA supports those cards perfectly out-of-the-box since years, then writing an obscure ALSA configuration which cripples those cards to simple stereo cards and now, after many discussions like this one, they suddenly say that PA is only meant for desktop purposes and not for professional purposes?
All correct, and we'd better be happy about that. The problem is *not* that PA doesn't support multichannel cards - it would still be completely useless for any serious audio work and we would still have to disable/bypass/remove it even if it would support PRO hardware. The problem is that it becomes more and more difficult to install a system without all sorts of (for me and others) useless components such as PA. The reason is lots of hard dependencies that should be optional extensions instead. When L.P. claims e.g. that Gnome wants 'usability' and 'accessibility', therefore it needs and audio stack and since the best one for desktop use is PA (no discussion) it pulls in PA, that does make sense. But when it becomes impossible (using binary packages) to install Gnome without PA (while accepting the consequences) that just amounts to *very bad design*. Because technically there is *no reason* why things should be that way. If Gnome doesn't find the PA components it needs for certain non-essential funcions, it should just go on without them. The same goes for consolekit, polkit and whatever other kids the family has grown meanwhile. They do not provide essential functionality, rather they interfere with the normal way to contoll access etc., so they must remain optional. Now udev has been merged with systemd, and one can wonder why. According to the authors, it is 'because they share some common code'. A rather weak argument, that would be true for almost any two subsystems you can imagine. Udev is perfectly usable and useful on its own, it should never be merged with something else that should remain optional. But maybe that's what behind it - in the long term systemd is supposed not be optional. So what will be merged in next ? The kits ? Dbus ? Filesystems ? Networking ? It will end up to be one giant 'system' blob, take it or leave it, as we know from other platforms, with no choice at all for the user. L.P.'s reply to concerns like this (if systematically interrupting a speaker during his presentation can be called 'replying') is 'what are you whining about, it's all free, it's all open, submit a patch'. As if something like systematic bad design and creation of dependencies could be mended with a patch. Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)
On Sat, Aug 11, 2012 at 2:48 PM, Fons Adriaensen <fons@linuxaudio.org> wrote:
The problem is that it becomes more and more difficult to install a system without all sorts of (for me and others) useless components such as PA. The reason is lots of hard dependencies that should be optional extensions instead. When L.P. claims e.g. that Gnome wants 'usability' and 'accessibility', therefore it needs and audio stack and since the best one for desktop use is PA (no discussion) it pulls in PA, that does make sense. But when it becomes impossible (using binary packages) to install Gnome without PA (while accepting the consequences) that just amounts to *very bad design*. Because technically there is *no reason* why things should be that way. If Gnome doesn't find the PA components it needs for certain non-essential funcions, it should just go on without them.
The same goes for consolekit, polkit and whatever other kids the family has grown meanwhile. They do not provide essential functionality, rather they interfere with the normal way to contoll access etc., so they must remain optional.
For better or worse, the reality is that there are hard dependencies on things you don't like. It seems that upstream is unwilling to change that. Rather than just complain about it (which will not change anything), why don't you try to find out what upstream would be willing to do to serve your usecase? I know for instance that pulseaudio should be able to disable itself if it finds jackd running (as PA acknowledges that it does not serve the same usecases as jack). Maybe that is not exactly what you need, but perhaps you could request some similar functionality. If you do it in a nice and constructive way based on technical arguments, I'm sure it would be merged.
Now udev has been merged with systemd, and one can wonder why. According to the authors, it is 'because they share some common code'. A rather weak argument, that would be true for almost any two subsystems you can imagine.
This is a misrepresentation. Udev and systemd were merged I think mainly because they "belong together", but also because they had cyclic build dependencies as they are very tightly integrated. It is not the case that systemd swallows anything it shares code with, in fact some stuff is being pushed into util-linux away from systemd.
Udev is perfectly usable and useful on its own, it should never be merged with something else that should remain optional. But maybe that's what behind it - in the long term systemd is supposed not be optional. So what will be merged in next ? The kits ? Dbus ? Filesystems ? Networking ? It will end up to be one giant 'system' blob, take it or leave it, as we know from other platforms, with no choice at all for the user.
I think there is no interest (upstream) in trying to make systemd optional forever, so this is a concern you are probably right about. However, the suggestions of what might be merged show that you are either joking or don't know these projects well. At some point parts of dbus will move into the kernel (so that is something to troll about I guess). -t
On Sat, 2012-08-11 at 15:30 +0200, Tom Gundersen wrote:
I know for instance that pulseaudio should be able to disable itself if it finds jackd running
No sarcasm, I seriously want to know about this. I only know that this is possible with jackdbus. Can you provide a link or do you mean jackdbus too? Regards, Ralf
On 08/11/2012 09:30 AM, Tom Gundersen wrote: [putolin]
I think there is no interest (upstream) in trying to make systemd optional forever, so this is a concern you are probably right about. However, the suggestions of what might be merged show that you are either joking or don't know these projects well. At some point parts of dbus will move into the kernel (so that is something to troll about I guess). -t
One thing that the folks/upstream that are merging all these things together is missing is that the future of "user" computer is moving to phones and ipad type devices. PC will still be around but the consumer has spoken and it looks like he/she is moving to these devices. I don't condemn them for doing so as they want something that works. Turn it on and get what they want done, PCs don't do this. How are/would these giant concoctions going to play here as they don't have the storage, memory, or cpu to handle this. The direction should be going in the tool kit style as in here's the kernel and you can bolt on all of these independent things. Something like android?
On Sat, 11 Aug 2012 09:59:54 -0400 Baho Utot <baho-utot@columbus.rr.com> wrote:
On 08/11/2012 09:30 AM, Tom Gundersen wrote:
[putolin]
I think there is no interest (upstream) in trying to make systemd optional forever, so this is a concern you are probably right about. However, the suggestions of what might be merged show that you are either joking or don't know these projects well. At some point parts of dbus will move into the kernel (so that is something to troll about I guess). -t
One thing that the folks/upstream that are merging all these things together is missing is that the future of "user" computer is moving to phones and ipad type devices. PC will still be around but the consumer has spoken and it looks like he/she is moving to these devices. I don't condemn them for doing so as they want something that works. Turn it on and get what they want done, PCs don't do this.
Smartphones, tablets and i* devices are toys. Have you ever tried to compile Android/openWebOS? Or openwrt for a router? Or even ArchlinuxARM? They is not nearly as flexible as PCs. Sure, if all you need from a computer is a means for posting crap on facebook, then consumers are right. Just because these mobile/embedded devices are hyped doesn't mean they own the future. Besides, systemd, PA, dbus are quite natural for embedded devices. For instance, Palm has been using PA in their devices since first versions, and quite successfully.
How are/would these giant concoctions going to play here as they don't have the storage, memory, or cpu to handle this. The direction should be going in the tool kit style as in here's the kernel and you can bolt on all of these independent things. Something like android?
Mobile phones like samsung galaxies have dual core Cortex A10 (?) and LG Tmobile GX (at least in the US) runs on quadcore Nvidia tegra. That's more processing power than my previous laptop. -- Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
On Sat, 2012-08-11 at 11:17 -0500, Leonid Isaev wrote:
tablets and i* devices are toys
The hardware capabilities aren't used very good, but they anyway aren't toys. For professional audio usage there at least are amazing remote controls available. Until now I didn't find the kind of graphic app I need, but it's already nice to be able to make computer graphics, while having the freedom not to sit in front of a computer. For artist they are very useful. Until now I won't recommend to buy a tablet PC, regarding to the policy of Apple and because common Android tablets, old hardware and old versions of Android, don't have the needed capabilities. "Most" (really "most") users just follow the hype, everybody wants a modern mobile and/or tablet PC and they like to use social networks, but there's also the possibility to use tablet PCs for serious work, at least for arts. You limit your way of seeing by yourself, that also explains your lack of insight, when other people try to explain the reason why forced dependencies are that bad. For some people computers are tools. Don't call tablet PCs tools, just because you limit your imagination and because you are not willing to listen to others. You might search the LAD and LAU archives for amazing examples about what already is possible with Android and iOS tablet PCs. There's much more possible, but we still tilt a little bit at windmills at the moment. Regards, Ralf
On Sat, 2012-08-11 at 19:14 +0200, Ralf Mardorf wrote:
On Sat, 2012-08-11 at 11:17 -0500, Leonid Isaev wrote:
tablets and i* devices are toys
The hardware capabilities aren't used very good, but they anyway aren't toys. For professional audio usage there at least are amazing remote controls available. Until now I didn't find the kind of graphic app I need, but it's already nice to be able to make computer graphics, while having the freedom not to sit in front of a computer.
For artist they are very useful. Until now I won't recommend to buy a tablet PC, regarding to the policy of Apple and because common Android tablets, old hardware and old versions of Android, don't have the needed capabilities.
"Most" (really "most") users just follow the hype, everybody wants a modern mobile and/or tablet PC and they like to use social networks, but there's also the possibility to use tablet PCs for serious work, at least for arts.
You limit your way of seeing by yourself, that also explains your lack of insight, when other people try to explain the reason why forced dependencies are that bad.
For some people computers are tools. Don't call tablet PCs tools, just ^^^^ toys, greetz from Freud :D
First I thought myself they are toys only, but they aren't.
because you limit your imagination and because you are not willing to listen to others.
You might search the LAD and LAU archives for amazing examples about what already is possible with Android and iOS tablet PCs. There's much more possible, but we still tilt a little bit at windmills at the moment.
Regards, Ralf
I think people are really exaggerating how "bloated" systemd is. I fail to see how systemd would have issues running on mobile devices, if anything its more optimized for embedded devices.
On 08/11/2012 01:41 PM, Brandon Watkins wrote:
I think people are really exaggerating how "bloated" systemd is. I fail to see how systemd would have issues running on mobile devices, if anything its more optimized for embedded devices.
You didn't understand my point
On Sat, Aug 11, 2012 at 3:59 PM, Baho Utot <baho-utot@columbus.rr.com> wrote:
One thing that the folks/upstream that are merging all these things together is missing is that the future of "user" computer is moving to phones and ipad type devices. PC will still be around but the consumer has spoken and it looks like he/she is moving to these devices. I don't condemn them for doing so as they want something that works. Turn it on and get what they want done, PCs don't do this. How are/would these giant concoctions going to play here as they don't have the storage, memory, or cpu to handle this. The direction should be going in the tool kit style as in here's the kernel and you can bolt on all of these independent things. Something like android?
I would be surprised if a systemd-based system requires more resources than a sysvinit-based one, but that is of course something one would have to measure for each particular use-case. There are lots of systemd-based embedded systems cropping up (the embedded world seems more excited about sysntemd than the desktop world). The aim of systemd is to work on anything from embedded, via desktop to servers. -t
On 08/11/2012 12:22 PM, Tom Gundersen wrote:
One thing that the folks/upstream that are merging all these things together is missing is that the future of "user" computer is moving to phones and ipad type devices. PC will still be around but the consumer has spoken and it looks like he/she is moving to these devices. I don't condemn them for doing so as they want something that works. Turn it on and get what they want done, PCs don't do this. How are/would these giant concoctions going to play here as they don't have the storage, memory, or cpu to handle this. The direction should be going in the tool kit style as in here's the kernel and you can bolt on all of these independent things. Something like android? I would be surprised if a systemd-based system requires more resources
On Sat, Aug 11, 2012 at 3:59 PM, Baho Utot <baho-utot@columbus.rr.com> wrote: than a sysvinit-based one, but that is of course something one would have to measure for each particular use-case.
There are lots of systemd-based embedded systems cropping up (the embedded world seems more excited about sysntemd than the desktop world). The aim of systemd is to work on anything from embedded, via desktop to servers.
-t
I am not looking at this from an systemd point of view. My point is the constant bloat with software today. Theses bloated packages will not fit/function on hand held devices. Is it not more sensible to build small apps that do one or two things well then bloated apps that try to do 25 things unwell?
On Sat, Aug 11, 2012 at 1:14 PM, Baho Utot <baho-utot@columbus.rr.com>wrote:
My point is the constant bloat with software today. Theses bloated packages will not fit/function on hand held devices.
You were quite specific with your point here, and I disagree.
On Sat, 2012-08-11 at 13:59 -0400, Brandon Watkins wrote:
On Sat, Aug 11, 2012 at 1:14 PM, Baho Utot <baho-utot@columbus.rr.com>wrote:
My point is the constant bloat with software today. Theses bloated packages will not fit/function on hand held devices.
You were quite specific with your point here, and I disagree.
We can ignore every context, but the context is On Sat, 2012-08-11 at 13:14 -0400, Baho Utot wrote:
Is it not more sensible to build small apps that do one or two things well then bloated apps that try to do 25 things unwell?
+1 And I again will add, why is there the need for unneeded dependencies? Regards, Ralf
On 11 August 2012 19:14, Baho Utot <baho-utot@columbus.rr.com> wrote:
On 08/11/2012 12:22 PM, Tom Gundersen wrote:
I would be surprised if a systemd-based system requires more resources than a sysvinit-based one, but that is of course something one would have to measure for each particular use-case.
There are lots of systemd-based embedded systems cropping up (the embedded world seems more excited about sysntemd than the desktop world). The aim of systemd is to work on anything from embedded, via desktop to servers.
-t
I am not looking at this from an systemd point of view. My point is the constant bloat with software today. Theses bloated packages will not fit/function on hand held devices. Is it not more sensible to build small apps that do one or two things well then bloated apps that try to do 25 things unwell?
Systemd is broken into multiple small utilities (see eg. systemd-tools that are used by initscripts already) that does one thing, so it's not one big scary binary that does everything. In fact I believe* systemd is more suited for embedded devices than the current initscripts. Systemd is a bunch of small binaries that should be fast to execute in contrary to interpreting piles of bash scripts. Lukas * note that I'm saying this even though I don't like systemd very much (it's just my personal opinion, so don't try to argue with that) and I don't use it on any of my systems (nor I'm planning to in the near future).
On 08/11/2012 02:11 PM, Lukas Jirkovsky wrote:
On 08/11/2012 12:22 PM, Tom Gundersen wrote:
I would be surprised if a systemd-based system requires more resources than a sysvinit-based one, but that is of course something one would have to measure for each particular use-case.
There are lots of systemd-based embedded systems cropping up (the embedded world seems more excited about sysntemd than the desktop world). The aim of systemd is to work on anything from embedded, via desktop to servers.
-t
I am not looking at this from an systemd point of view. My point is the constant bloat with software today. Theses bloated packages will not fit/function on hand held devices. Is it not more sensible to build small apps that do one or two things well then bloated apps that try to do 25 things unwell? Systemd is broken into multiple small utilities (see eg. systemd-tools
On 11 August 2012 19:14, Baho Utot <baho-utot@columbus.rr.com> wrote: that are used by initscripts already) that does one thing, so it's not one big scary binary that does everything.
systemd is one source distributed package arch split the package into the multiples you see here.
In fact I believe* systemd is more suited for embedded devices than the current initscripts. Systemd is a bunch of small binaries that should be fast to execute in contrary to interpreting piles of bash scripts.
It doesn't run on my android device nor would it be needed or required.
On 11 August 2012 23:05, Baho Utot <baho-utot@columbus.rr.com> wrote:
systemd is one source distributed package
arch split the package into the multiples you see here.
It is one source package, but it provides multiple small utilities. The coreutils are distributed as one source package that provides many small utilities, too.
It doesn't run on my android device nor would it be needed or required.
That doesn't mean it cannot be used as such. Lukas
I suspect upstream folks are living in an ivory tower. Nouveau, PA, systemd, GNOME3, GIMP etc. and regarding to GIMP somebody posted those links. It's worth to read it, since it's not about GIMP only, but about the communication between users and upstream. -------- Forwarded Message -------- To: Debian User You might "enjoy" this three-part thread... http://lists.fedoraproject.org/pipermail/test/2012-April/107586.html http://lists.fedoraproject.org/pipermail/test/2012-April/107603.html http://lists.fedoraproject.org/pipermail/test/2012-May/107697.html
On 12 Aug 2012 20:51, "Ralf Mardorf" <ralf.mardorf@alice-dsl.net> wrote:
I suspect upstream folks are living in an ivory tower.
Nouveau, PA, systemd, GNOME3, GIMP etc. and regarding to GIMP somebody posted those links. It's worth to read it, since it's not about GIMP only, but about the communication between users and upstream.
I suspect that some users have a huge sense of entitlement. Thoroughly undeserved. The users are not the most important component of an open source project, not even close. And any neutral party reading the gimp mailing list currently would identify the majority of the complaints to be unreasonable since they amount to "this change sucks, change it back or we'll stop using this software".
On Sun, 12 Aug 2012 14:49:29 +0200 Ralf Mardorf <ralf.mardorf@alice-dsl.net> wrote:
I suspect upstream folks are living in an ivory tower.
Nouveau, PA, systemd, GNOME3, GIMP etc. and regarding to GIMP somebody posted those links. It's worth to read it, since it's not about GIMP only, but about the communication between users and upstream.
FWIW, Nouveau has gotten really good for low latency audio lately, I have a machine with a 8600gts running kde with kwin compositing and the kernel latency peaks at about 0.3ms with nouveau, as opposed to nvidia that manages just above 1ms. Of course my hd3000 on sandy bridge manages well under 0.1ms.... :) I also don't quite understand the PA discussion. I am not thrilled to have libpulse pulled in as a dependency, but on the other hand I have never seen it cause a problem in arch. Of course I have no intention of installing, nor of starting pulseaudio itself on my system... I was however sad to see old dependable friends like ifconfig and route being deprecated last year. Sad to see rc.conf more or less being deprecated too. Seeing the new man page made me see the writing on the wall though, and I have reduced it to an array listing the daemons I wanna start. Think I'm gonna feel like a complete noob next time I wanna install arch somewhere. IMO even if not logical, having a big part of the system config in rc.conf was convenient and reminded me of systems i ran many years ago... Oh well, let's hope the future is so bright that we gotta wear shades :) --- Joakim
On Sun, 12 Aug 2012 23:43:08 +0200 Joakim Hernberg <jbh@alchemy.lu> wrote:
Sad to see rc.conf more or less being deprecated too. Seeing the new man page made me see the writing on the wall though, and I have reduced it to an array listing the daemons I wanna start.
Better retract this :) Don't know where I got that from, must have been from reading the mailing list. In any case I've taken the big step away from rc.conf by now. --- Joakim
On Sun, Aug 12, 2012 at 11:43:08PM +0200, Joakim Hernberg wrote:
I was however sad to see old dependable friends like ifconfig and route being deprecated last year.
I had the same initial response to that. But spending an evening reading the ip manpage and doing a lot of 'exercises' using it changed that, now I can type ip commands as fluently as I could do before using ifconfig and route. The most important 'mental adjustmemt' I needed to make was getting used to the idea that a single interface can have many IP adresses. It's probably irrelevant to most users, but still just a fact.
Sad to see rc.conf more or less being deprecated too.
Yes, it was very convenient to have almost all essential configuration available in a single file. And it's sad that this is being abandoned not because that brings any benefit to the user but because 'upstream has decided'.
Oh well, let's hope the future is so bright that we gotta wear shades :)
Che serà serà... Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)
On Mon, Aug 13, 2012 at 12:06 AM, Fons Adriaensen <fons@linuxaudio.org> wrote:
Sad to see rc.conf more or less being deprecated too.
Yes, it was very convenient to have almost all essential configuration available in a single file. And it's sad that this is being abandoned not because that brings any benefit to the user but because 'upstream has decided'.
I do not agree with this. The change does give more features, makes things more reliable in the long run and reduces the maintenance burden. If we did not agree with "upstream", we would not have to do this. -t
On Mon, Aug 13, 2012 at 12:12:56AM +0200, Tom Gundersen wrote:
On Mon, Aug 13, 2012 at 12:06 AM, Fons Adriaensen <fons@linuxaudio.org> wrote:
Sad to see rc.conf more or less being deprecated too.
Yes, it was very convenient to have almost all essential configuration available in a single file. And it's sad that this is being abandoned not because that brings any benefit to the user but because 'upstream has decided'.
I do not agree with this. The change does give more features, makes things more reliable in the long run and reduces the maintenance burden. If we did not agree with "upstream", we would not have to do this.
And I don't blame you for it ... Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)
On Sun, Aug 12, 2012 at 5:12 PM, Tom Gundersen <teg@jklm.no> wrote:
On Mon, Aug 13, 2012 at 12:06 AM, Fons Adriaensen <fons@linuxaudio.org> wrote:
Sad to see rc.conf more or less being deprecated too.
Yes, it was very convenient to have almost all essential configuration available in a single file. And it's sad that this is being abandoned not because that brings any benefit to the user but because 'upstream has decided'.
I do not agree with this. The change does give more features, makes things more reliable in the long run and reduces the maintenance burden. If we did not agree with "upstream", we would not have to do this.
-t
Tom: I agree with ya'll that it will be better in the long run for Arch in general. However I've had to back away from using systemd. There are simply too many changes going on for me to keep up with and currently I find it much easier to deal with the old style init scripts ( please don't take this a complaint as life and age have slowed some of the processes ). To All: That being said, I think it time for all to "quit yer bitchin" and decide "to fish or cut bait". Right now both ways are supported and that gives everyone time to decide which way they want to go. Less noise about it all would give the devs more time to concentrate on making everything work right instead of either ignoring these debates or tearing their hair out trying to impart some knowledge and understanding to everyone. These are the battles that have spawned many a new linux distro and there's always LFS. It's been said before and I'll reiterate it, If you don't like it work to fix it. Myra -- Life's fun when your sick and psychotic!
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/12/2012 02:43 PM, Joakim Hernberg wrote:
I also don't quite understand the PA discussion. I am not thrilled to have libpulse pulled in as a dependency, but on the other hand I have never seen it cause a problem in arch. Of course I have no intention of installing, nor of starting pulseaudio itself on my system...
- From what I've seen, libpulse doesn't cause problems (other than occupying space). I'm not thrilled about it either. But it seems possible to have it on the system without drawing in the rest of the pulseaudio toolchain that is clearly problematic. Great discussion, by the way. I don't fully understand it either, but given the problems I've had with pulseaudio, I appreciate what seems to be confirmation that I'm losing nothing by leaving it out. - -- David Benfell benfell@parts-unknown.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQKCyXAAoJELT202JKF+xpoogP/1OhYbccpiagZd7Ja3ohZGvs 9rExCkq2/ioUW25ta/aihc7NwEPT1C1dbvMJuNEiO7b8QDBznt6Zq+YoSebSOaQb p1573c3SZlNXGHT3nazL7lXX4vLq2CO7ZHrmLZdI7zFDL4A5J/lVa28wmf7RkmsZ J8UNit+QIfXrePAAmMeSVl33F9YQhB2kzcbJnrH3onSBP8Vblgj2b2hZFMXimuSk FKkk2PFdkg6mdag3xdl5G06cm/tLkfuC5g8wzJceI4TSTrJTRIqsERGz0RZTTA/A SF7uj/NUFjGecCHRVX9r0kFxVZataNuDO61VSV1R0vmaYGvTSII88xaWWj5gI3Go 8kLm0whIa26CauPp2X+/ozqzgkIklOUb+9gIxdEuYiMPmL6L67knFH/O2AtA7Gcp e0FoG8G+CFPLLizkBAdaYA1Lh9WRQ70p64iPBlw04mdIdV7zhtC5jpWOyI+G2Ato 1hyrvprwVvJsJRwZYsx4XW8yzyQdQ3+5pckG5seHKO1WIB7tgoEM0bPKyJH8H6ql 2U15m1U7GkXCyyhBG6IvOGcmkoVgx5kUT2XGLZRiIc6/mDbTJS76NEFCnDLn1zgG jb5eujWPd16TThdEma3qDOnjTFtd1cbJ30ECUSqiDYe32qYvaP32uVpsbrkvF9kL N/R9RqO4jI0ofPatnOQU =8+pa -----END PGP SIGNATURE-----
On Sun, 2012-08-12 at 15:22 -0700, David Benfell wrote:
Great discussion
It isn't. Engineering facts are unimportant. Just the benefit is important. Some people benefit from PA and for other people it's a PITA. The essence of it still is the question, why can't PA be optional? PA isn't needed. PA can be an advantage for some usages. PA can completely break some Linux.
On Mon, Aug 13, 2012 at 12:33 AM, Ralf Mardorf <ralf.mardorf@alice-dsl.net> wrote:
The essence of it still is the question, why can't PA be optional?
I don't do gnome stuff, so I don't know the answer to this (I think I do, but haven't taken the time to check). I'm sure the answer can be found if you were to do $ git clone git://git.gnome.org/gnome-settings-daemon $ git grep -i pulse HTH, Tom
On Mon, 2012-08-13 at 00:36 +0200, Tom Gundersen wrote:
On Mon, Aug 13, 2012 at 12:33 AM, Ralf Mardorf <ralf.mardorf@alice-dsl.net> wrote:
The essence of it still is the question, why can't PA be optional?
I don't do gnome stuff, so I don't know the answer to this (I think I do, but haven't taken the time to check). I'm sure the answer can be found if you were to do
$ git clone git://git.gnome.org/gnome-settings-daemon $ git grep -i pulse
HTH,
Tom
Fair play, I don't need GDM and for Arch Linux on my computer only GDM depends indirectly to pulaseaudio. I simply fear that PA and other software that could brake some usages, will spread, without any need. There will alway be a way (at least with help from the community) to get rid of such annoying software. But IMO the simplest way is to stop making odd dependencies. Regards, Ralf
On Mon, 13 Aug 2012 00:33:17 +0200 Ralf Mardorf <ralf.mardorf@alice-dsl.net> wrote:
The essence of it still is the question, why can't PA be optional?
PA isn't needed. PA can be an advantage for some usages. PA can completely break some Linux.
What specific problem do you have with programs being linked to libpulse, so far I haven't encountered any in Arch. OK, I also know from supporting software that some other distributions have a long standing tradition of trampling Jack under their feet and being more or less permanently useless for years already. One reason I'm very happy to be using Archlinux...! --- Joakim
On Mon, 2012-08-13 at 00:41 +0200, Joakim Hernberg wrote:
On Mon, 13 Aug 2012 00:33:17 +0200 Ralf Mardorf <ralf.mardorf@alice-dsl.net> wrote:
The essence of it still is the question, why can't PA be optional?
PA isn't needed. PA can be an advantage for some usages. PA can completely break some Linux.
What specific problem do you have with programs being linked to libpulse, so far I haven't encountered any in Arch.
A dependency to libpulse is ok, a dependency to pulseaudio is the showstopper. Until now even this isn't an issue, since AFAIK only GNOME for Arch insists on pulseaudio. But this might change. People for good reasons chose some distro. However, IMO it's important to see which way the wind is blowing. I much to often read one name (Poe...), when simply reading just for entertainment some Linux ezines. Paranoia ;), but for god reasons ;).
On Mon, 13 Aug 2012 01:05:25 +0200 Ralf Mardorf <ralf.mardorf@alice-dsl.net> wrote:
Until now even this isn't an issue, since AFAIK only GNOME for Arch insists on pulseaudio. But this might change. People for good reasons chose some distro.
I think if Gnome has a hard dependency on PA, there isn't anything Arch can do about it... Patching upstream sources isn't the Archway... Otherwise it ought to be an optdepend, but making it optional it it's needed by a package would probably be a bad idea... Seems to me that either you need to stop using Gnome, or write the needed patches to make PA optional. I guess a 3:rd option would be to fix what is broken in PA...:) Let's hope Arch stays the way it was, where more or less everything is optional and you can design your own system exactly as you want it! --- Joakim
On Mon, 2012-08-13 at 01:17 +0200, Joakim Hernberg wrote:
On Mon, 13 Aug 2012 01:05:25 +0200 Ralf Mardorf <ralf.mardorf@alice-dsl.net> wrote:
Until now even this isn't an issue, since AFAIK only GNOME for Arch insists on pulseaudio. But this might change. People for good reasons chose some distro.
I think if Gnome has a hard dependency on PA, there isn't anything Arch can do about it... Patching upstream sources isn't the Archway... Otherwise it ought to be an optdepend, but making it optional it it's needed by a package would probably be a bad idea...
Seems to me that either you need to stop using Gnome, or write the needed patches to make PA optional. I guess a 3:rd option would be to fix what is broken in PA...:)
Let's hope Arch stays the way it was, where more or less everything is optional and you can design your own system exactly as you want it!
When GNOME2 switched to 3 I stopped using GNOME. Hats off! Somebody maintained https://aur.archlinux.org/packages.php?ID=48718 for a long time! Btw. I suspect that I benefit of systemd side effects. Could it be that now, each time a new kernel or kernel-rt is installed, the vbox modules are build, regarding to a side effect of systemd? Or has this nothing to do with systemd? I wish to be allowed to be a dummy using Linux. If I would like to be an expert, I could chose any other obscure OS. Linux shouldn't become non-transparent, even not for noobs. At the moment pulseaudio seems no issue for any distro, as long as we avoid to use GNOME or GDM. For systemd it might be different, perhaps there aren't issues, but without systemd there aren't issues for me. So, if I read systemd is from Mr. X, as pulseaudio is too, I'm horrified. Getting rid of PA is easy, once you know what to do, but it also was easy to get PA (like a disease) without a warning, just by upgrading GNOME for one and the other distro. It's no fun, when that happens at the most bad possible moment. I don't want my Linux PC become as faulty as my iThingy.
On Sun, 2012-08-12 at 15:22 -0700, David Benfell wrote:
On 08/12/2012 02:43 PM, Joakim Hernberg wrote:
I also don't quite understand the PA discussion. I am not thrilled to have libpulse pulled in as a dependency, but on the other hand I have never seen it cause a problem in arch. Of course I have no intention of installing, nor of starting pulseaudio itself on my system...
From what I've seen, libpulse doesn't cause problems (other than occupying space). I'm not thrilled about it either. But it seems possible to have it on the system without drawing in the rest of the pulseaudio toolchain that is clearly problematic.
Great discussion, by the way. I don't fully understand it either, but given the problems I've had with pulseaudio, I appreciate what seems to be confirmation that I'm losing nothing by leaving it out.
libpulse is ok :), I don't care about some bytes more or less. A desktop picture nowadays needs more RAM/ROM than a complete workstation needs 2 decades ago. The issue was/is/will be, that PA is a dependency, even if it's not needed. Regards, Ralf
On Mon, 2012-08-13 at 00:44 +0200, Ralf Mardorf wrote:
On Sun, 2012-08-12 at 15:22 -0700, David Benfell wrote:
On 08/12/2012 02:43 PM, Joakim Hernberg wrote:
I also don't quite understand the PA discussion. I am not thrilled to have libpulse pulled in as a dependency, but on the other hand I have never seen it cause a problem in arch. Of course I have no intention of installing, nor of starting pulseaudio itself on my system...
From what I've seen, libpulse doesn't cause problems (other than occupying space). I'm not thrilled about it either. But it seems possible to have it on the system without drawing in the rest of the pulseaudio toolchain that is clearly problematic.
Great discussion, by the way. I don't fully understand it either, but given the problems I've had with pulseaudio, I appreciate what seems to be confirmation that I'm losing nothing by leaving it out.
libpulse is ok :), I don't care about some bytes more or less. A desktop picture nowadays needs more RAM/ROM than a complete workstation needs 2 decades ago.
The issue was/is/will be, that PA is a dependency, even if it's not needed. Ooops, but it can brake some usages. Apologize.
On Mon, 13 Aug 2012 04:14:07 +0530, Ralf Mardorf <ralf.mardorf@alice-dsl.net> wrote:
On Sun, 2012-08-12 at 15:22 -0700, David Benfell wrote:
On 08/12/2012 02:43 PM, Joakim Hernberg wrote:
I also don't quite understand the PA discussion. I am not thrilled to have libpulse pulled in as a dependency, but on the other hand I have never seen it cause a problem in arch. Of course I have no intention of installing, nor of starting pulseaudio itself on my system...
From what I've seen, libpulse doesn't cause problems (other than occupying space). I'm not thrilled about it either. But it seems possible to have it on the system without drawing in the rest of the pulseaudio toolchain that is clearly problematic.
Great discussion, by the way. I don't fully understand it either, but given the problems I've had with pulseaudio, I appreciate what seems to be confirmation that I'm losing nothing by leaving it out.
libpulse is ok :), I don't care about some bytes more or less. A desktop picture nowadays needs more RAM/ROM than a complete workstation needs 2 decades ago.
The issue was/is/will be, that PA is a dependency, even if it's not needed.
Regards, Ralf
OT: this is the first discussion of PA, systemd, etc., in my limited experience that didn't lead to ad hominem attacks, stays on topic, and actually provides useful information. great! -- phani.
I would be surprised if a systemd-based system requires more resources than a sysvinit-based one, but that is of course something one would have to measure for each particular use-case.
How about an init script that creates proc and sys, two devices via mknod and runs one server or a shell such as in any embedded basic example. My favourite init is still OpenBSDs single /etc/rc script that utilises the minimum number of easily followed, edited (though discouraged) and understood inclusions to make administration practical.
There are lots of systemd-based embedded systems cropping up (the embedded world seems more excited about sysntemd than the desktop world). The aim of systemd is to work on anything from embedded, via desktop to servers.
You are actually talking about a fraction of embedded, which is the mobile phone world. In truly embedded cheap instant on devices, udev/mdev (dynamic dev) even can be seen as something that slows down the boot and makes it less reliable than using mknod in a short init script. To reiterate an example some people hope linux will run on a cheap toaster. -- _______________________________________________________________________ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) _______________________________________________________________________
On Sat, 11 Aug 2012 15:30:09 +0200 Tom Gundersen <teg@jklm.no> wrote:
This is a misrepresentation. Udev and systemd were merged I think mainly because they "belong together", but also because they had cyclic build dependencies as they are very tightly integrated. It is not the case that systemd swallows anything it shares code with, in fact some stuff is being pushed into util-linux away from systemd.
I keep seeing this "quote" on the net, is it not accurate? "Sievers explained that it will still be possible to install udev independently of systemd. He added that this option will be supported in the long term because separate builds are required to ensure that initrds (initial ramdisks), which don't include systemd, work correctly. Distributions that don't use systemd can continue to build udev as before, but will have to use the systemd sources." --- Joakim
On Sat, Aug 11, 2012 at 5:51 PM, Joakim Hernberg <jbh@alchemy.lu> wrote:
"Sievers explained that it will still be possible to install udev independently of systemd. He added that this option will be supported in the long term because separate builds are required to ensure that initrds (initial ramdisks), which don't include systemd, work correctly. Distributions that don't use systemd can continue to build udev as before, but will have to use the systemd sources."
I assume this is taken from [0]. What is and will be supported is to install udev without systemd. Building udev without also building systemd is not supported though (that was the point of the merge). So if people want only udev they'd need to build all of systemd, and pick out the bits they want (have a look at our systemd-tools package for an example of how this can be done[1]). -t [0]: <http://thread.gmane.org/gmane.linux.hotplug.devel/17392> [1]: <https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/systemd#n142>
On Saturday 11 Aug 2012 17:51:44 Joakim Hernberg wrote:
"Sievers explained that it will still be possible to install udev independently of systemd. He added that this option will be supported in the long term because separate builds are required to ensure that initrds (initial ramdisks), which don't include systemd, work correctly. Distributions that don't use systemd can continue to build udev as before, but will have to use the systemd sources."
Exact quote from http://lwn.net/Articles/490413/ "In fact, we will be supporting this for a long time since it is a necessity to make initrds (which lack systemd) work properly." See the word "lack" and "necessity". They do not talk about it as design features as so many people want. For them, this lack of systemd is a bug not a feature. So according to their design patterns, they would have liked systemd in initrd. -- Cheers and Regards Jayesh Badwaik stop html mail | always bottom-post www.asciiribbon.org | www.netmeister.org/news/learn2quote.html
On 08/11/2012 11:51 AM, Joakim Hernberg wrote:
On Sat, 11 Aug 2012 15:30:09 +0200 Tom Gundersen <teg@jklm.no> wrote:
This is a misrepresentation. Udev and systemd were merged I think mainly because they "belong together", but also because they had cyclic build dependencies as they are very tightly integrated. It is not the case that systemd swallows anything it shares code with, in fact some stuff is being pushed into util-linux away from systemd. I keep seeing this "quote" on the net, is it not accurate?
"Sievers explained that it will still be possible to install udev independently of systemd. He added that this option will be supported in the long term because separate builds are required to ensure that initrds (initial ramdisks), which don't include systemd, work correctly. Distributions that don't use systemd can continue to build udev as before, but will have to use the systemd sources."
---
Joakim
That is not entirely true. Have a look at LFS. Bruce Dubbs has broken udev out of the systemd-187. Which you can see from here: http://www.linuxfromscratch.org/lfs/view/development/chapter06/udev.html systemd-188 has been somewhat ugly.
On Sat, Aug 11, 2012 at 03:30:09PM +0200, Tom Gundersen wrote:
For better or worse, the reality is that there are hard dependencies on things you don't like. It seems that upstream is unwilling to change that.
Then you should really ask yourself why they take that position. AFAICS, there is no solid technical argument for it.
Now udev has been merged with systemd, and one can wonder why. According to the authors, it is 'because they share some common code'. A rather weak argument, that would be true for almost any two subsystems you can imagine.
This is a misrepresentation. Udev and systemd were merged I think mainly because they "belong together", but also because they had cyclic build dependencies as they are very tightly integrated.
It's no misrepresantation, but an almost literal quote from one of the authors. Yes, systemd and udev are supposed to work closely together, that makes perfect sense. The solution preferred by grown-up programmers in such cases is to define stable interfaces on both sides allowing them to do that, not to merge them. Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)
Then you should really ask yourself why they take that position. AFAICS, there is no solid technical argument for it.
I believe they just don't think about anything other than the main and so do the least possible rather than taking the extra steps (or have too much to think about or on the todo list already). Take firefox it has a compilation option of no dbus but if dbus fails it refuses to even start (dbus being a possible route to escape chroot). I had sorted that by just closing off the dbus after start-up but since upgrading now get a general "DBUS error" message. It was said the linux user space package dependency issue was getting better but I think it's relapsed and perhaps far worse or more lazy in some cases.
Now udev has been merged with systemd, and one can wonder why. According to the authors, it is 'because they share some common code'. A rather weak argument, that would be true for almost any two subsystems you can imagine.
This is a misrepresentation. Udev and systemd were merged I think mainly because they "belong together", but also because they had cyclic build dependencies as they are very tightly integrated.
It's no misrepresantation, but an almost literal quote from one of the authors.
Yes, systemd and udev are supposed to work closely together, that makes perfect sense. The solution preferred by grown-up programmers in such cases is to define stable interfaces on both sides allowing them to do that, not to merge them.
I've been wondering lately whether there is a good reason why even udev violates the "one thing and do it well" principle set forth by the co worker of the designer of C and Unix as it not only dynamically creates devices like mdev does but also hotplugging like hotplugd on OpenBSD. Hopefully there is a config option or you would need an alternative if you want static dev files and hotplugging. -- _______________________________________________________________________ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) _______________________________________________________________________
On Aug 13, 2012 3:17 AM, "Kevin Chadwick" <ma1l1ists@yahoo.co.uk> wrote:
I've been wondering lately whether there is a good reason why even udev violates the "one thing and do it well" principle set forth by the co worker of the designer of C and Unix as it not only dynamically creates devices like mdev does but also hotplugging like hotplugd on OpenBSD. Hopefully there is a config option or you would need an alternative if you want static dev files and hotplugging.
This is completely wrong. Udev does not create any device nudes. Tom
On Mon, Aug 13, 2012 at 2:12 PM, Tom Gundersen <teg@jklm.no> wrote:
On Aug 13, 2012 3:17 AM, "Kevin Chadwick" <ma1l1ists@yahoo.co.uk> wrote:
I've been wondering lately whether there is a good reason why even udev violates the "one thing and do it well" principle set forth by the co worker of the designer of C and Unix as it not only dynamically creates devices like mdev does but also hotplugging like hotplugd on OpenBSD. Hopefully there is a config option or you would need an alternative if you want static dev files and hotplugging.
This is completely wrong. Udev does not create any device nudes.
Tom
I'd hope not, there's under-age users of Linux to consider.
On Mon, Aug 13, 2012 at 8:53 AM, Oon-Ee Ng <ngoonee.talk@gmail.com> wrote:
On Mon, Aug 13, 2012 at 2:12 PM, Tom Gundersen <teg@jklm.no> wrote:
On Aug 13, 2012 3:17 AM, "Kevin Chadwick" <ma1l1ists@yahoo.co.uk> wrote:
I've been wondering lately whether there is a good reason why even udev violates the "one thing and do it well" principle set forth by the co worker of the designer of C and Unix as it not only dynamically creates devices like mdev does but also hotplugging like hotplugd on OpenBSD. Hopefully there is a config option or you would need an alternative if you want static dev files and hotplugging.
This is completely wrong. Udev does not create any device nudes.
Tom
I'd hope not, there's under-age users of Linux to consider.
Lol. Damn phone. -t
On 08/13/2012 07:56 AM, Tom Gundersen wrote:
On Mon, Aug 13, 2012 at 8:53 AM, Oon-Ee Ng <ngoonee.talk@gmail.com> wrote:
On Mon, Aug 13, 2012 at 2:12 PM, Tom Gundersen <teg@jklm.no> wrote:
On Aug 13, 2012 3:17 AM, "Kevin Chadwick" <ma1l1ists@yahoo.co.uk> wrote:
I've been wondering lately whether there is a good reason why even udev violates the "one thing and do it well" principle set forth by the co worker of the designer of C and Unix as it not only dynamically creates devices like mdev does but also hotplugging like hotplugd on OpenBSD. Hopefully there is a config option or you would need an alternative if you want static dev files and hotplugging. This is completely wrong. Udev does not create any device nudes.
Tom I'd hope not, there's under-age users of Linux to consider. Lol. Damn phone.
-t
Yea right that's what you said the last time ;)
On Mon, 2012-08-13 at 08:59 -0400, Baho Utot wrote:
On 08/13/2012 07:56 AM, Tom Gundersen wrote:
On Mon, Aug 13, 2012 at 8:53 AM, Oon-Ee Ng <ngoonee.talk@gmail.com> wrote:
On Mon, Aug 13, 2012 at 2:12 PM, Tom Gundersen <teg@jklm.no> wrote:
On Aug 13, 2012 3:17 AM, "Kevin Chadwick" <ma1l1ists@yahoo.co.uk> wrote:
I've been wondering lately whether there is a good reason why even udev violates the "one thing and do it well" principle set forth by the co worker of the designer of C and Unix as it not only dynamically creates devices like mdev does but also hotplugging like hotplugd on OpenBSD. Hopefully there is a config option or you would need an alternative if you want static dev files and hotplugging. This is completely wrong. Udev does not create any device nudes.
Tom I'd hope not, there's under-age users of Linux to consider. Lol. Damn phone.
-t
Yea right that's what you said the last time ;)
I often unplug my phone, this can be very relaxing ;) and I don't use a mobile or TAD anymore.
I've been wondering lately whether there is a good reason why even udev violates the "one thing and do it well" principle set forth by the co worker of the designer of C and Unix as it not only dynamically creates devices like mdev does but also hotplugging like hotplugd on OpenBSD. Hopefully there is a config option or you would need an alternative if you want static dev files and hotplugging.
This is completely wrong. Udev does not create any device nudes.
Seems this has changed and my source was out of date (2010 or 2011) or based on an older embedded kernel. More to find out but looks like I can easily pick and choose and test from mknod devtmpfs or udev/mdev and any delays are more manageable, brill. http://lwn.net/Articles/331818/ http://article.gmane.org/gmane.linux.kernel/830722 Thanks -- _______________________________________________________________________ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) _______________________________________________________________________
On 08/13/2012 02:12 AM, Tom Gundersen wrote:
On Aug 13, 2012 3:17 AM, "Kevin Chadwick" <ma1l1ists@yahoo.co.uk> wrote:
I've been wondering lately whether there is a good reason why even udev violates the "one thing and do it well" principle set forth by the co worker of the designer of C and Unix as it not only dynamically creates devices like mdev does but also hotplugging like hotplugd on OpenBSD. Hopefully there is a config option or you would need an alternative if you want static dev files and hotplugging. This is completely wrong. Udev does not create any device nudes.
Tom
http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev/udev.html
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/11/2012 05:48 AM, Fons Adriaensen wrote:
The problem is that it becomes more and more difficult to install a system without all sorts of (for me and others) useless components such as PA. The reason is lots of hard dependencies that should be optional extensions instead.
I'm asking this out of ignorance rather than rhetorically: How much of this is the distribution and how much of this is gnome? I know, for instance, if I install an Ubuntu or Mint system, they have these meta-packages that have all these dependencies to pull in, in this example, a complete gnome. Is that really the fault of upstream? - -- David Benfell benfell@parts-unknown.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQJuyjAAoJELT202JKF+xpMNkP/jVkSUC66UpsAdxcNHBdDJex Wyhyjv2SAw46UMZovxLdPf64UTa2wEt9yZ0pw58PqZ3LLCfLy4b+gJ/Dr5+KPq6/ F2vsBrSBvi443DIWAockbXglfuJ6LCNxjFjgTSL+y5gsOR5OyoDaq1wLXFzRngN/ pkCRyur77A1QrEuo/vw7rZtxz4xuGIbtRMfnCupxUZpvWtK/Lss1jWSYZpQxHYQ/ 7Gtx0sHerZuv8uHkVybvd6/q7hKbBGFPBHG5KFvllXrhhzQ2LMrQFiErRDjYZhxz eVOeASpp+cB5ydVhU0RousFD6rkaaK6fCsEYoeT9biGPBTUUC+mLbSCf+3v7+Lil jE4+pQI3Eb7skLvrDZOGvOJQDzqftikku4POGYdZopkn1FnFRicEyHkzjgDT5O8D OOOc6hIBGbIHZ5iKf3ofxc/xgGabGFrWHpaH/4A9KFQh+DS6Y2yTQA2gtpfTGIlO 2InMymcmdyO9Y7FmTTW1u+gIL+wd3LbQtdKaHVApFBx+zT5oBfbip7Sv074ApH9D 35ij2KeBXKPToknI9qFtYVeQnunnvt+Lva/VzLZoivkwgTBABA3pbdR6CzTp3Xf0 2+Tc193QnW0ZUrZkQHVTW4PdqxXztEV66WhYnD0yPHlkzujPx2a4Pc3Sh7i6Qdhc Hl9rw1NHHyzOBGCF/lNV =2yEA -----END PGP SIGNATURE-----
On Sun, Aug 12, 2012 at 1:37 AM, David Benfell <benfell@parts-unknown.org> wrote:
How much of this is the distribution and how much of this is gnome?
Mostly upstream (depends of course a bit on which package you have in mind). If an app links against libpulse it means that it would crash if libpulse is not installed, so we add a dependency on libpulse. A dependency that does not cause the app to misbehave if it is not installed (such as plugins, etc) should (in general) be an optdepend. -t
On Sun, 2012-08-12 at 02:28 +0200, Tom Gundersen wrote:
On Sun, Aug 12, 2012 at 1:37 AM, David Benfell <benfell@parts-unknown.org> wrote:
How much of this is the distribution and how much of this is gnome?
Mostly upstream (depends of course a bit on which package you have in mind). If an app links against libpulse it means that it would crash if libpulse is not installed, so we add a dependency on libpulse.
A dependency that does not cause the app to misbehave if it is not installed (such as plugins, etc) should (in general) be an optdepend.
https://aur.archlinux.org/packages.php?ID=48718 Nothing bad happens, if pulseaudio (not libpulse), is a dummy package. So why is pulseaudio a dependency and not optional?
On Sun, 2012-08-12 at 02:34 +0200, Ralf Mardorf wrote:
On Sun, 2012-08-12 at 02:28 +0200, Tom Gundersen wrote:
On Sun, Aug 12, 2012 at 1:37 AM, David Benfell <benfell@parts-unknown.org> wrote:
How much of this is the distribution and how much of this is gnome?
Mostly upstream (depends of course a bit on which package you have in mind). If an app links against libpulse it means that it would crash if libpulse is not installed, so we add a dependency on libpulse.
A dependency that does not cause the app to misbehave if it is not installed (such as plugins, etc) should (in general) be an optdepend.
https://aur.archlinux.org/packages.php?ID=48718 Nothing bad happens, if pulseaudio (not libpulse), is a dummy package. So why is pulseaudio a dependency and not optional?
To make it clear, I'm speaking for a "regular" gnome-settings-daemon.
On 08/10/2012 08:03 PM, Leonid Isaev wrote: [putolin]
Look, you don't _have_ to use pacman to manage software. As I said elsewhere, dependencies on pulse, lirc, etc. are there for a reason. If you disagree with this reason, file a bugreport. But using dummy packages is just cheating.
Then how does one install arch? pacman is very convenient Isn't pacman the only package manager for arch? I did not understand that arch had many options for package managers.
Am Sat, 11 Aug 2012 00:56:33 +0200 schrieb Tom Gundersen <teg@jklm.no>:
This is not the right mailinglist for this issue. And this certainly is not the right thread for it.
This is the right mailing list for this issue, because downstream is also affected by this. And it is also downstream's decision whether to ship systemd or not. And you do it by forcing all that systemd stuff like systemd-tools and all those service files on every user if he wants to have systemd on his system or not. So this IS the right mailing list.
You are free to reimplement all those tools and ship a competing package. The configuration formats are well-documented, so it should not be hard.
Why would I? There are tools which are working. Systemd is still not working. For cryptsetup there was and currently still is a working code in initscripts. So principally no need to use some systemd-tools for this. And this code covered a lot more use cases than systemd-cryptsetup originally. And I know this code, because I have written at least most part of this code. The syntax could indeed a bit more clearer, but that could have been done without systemd-cryptsetup. What about all the already existing tools, someone else recently mentioned here on the list? Still no word about them. Still no discussion it they are sufficient or probably better than systemd.
What are you talking about? No one forgot anything. This is what happened: You pointed out a feature that initsrcipts used to have which systemd-cryptsetup lacked, (on the same day) I posted a patch to implement the feature you requested, and asked for feedback (which you didn't give), one week later I posted the patch upstream and (on the same day) Lennart replied: "Applied." The functionality should now be part of systemd 188, which is in testing. What more could you possibly ask for?
Just simple. I ask for first thinking about use cases and about reliability before writing such a tool and before trying to make it a de facto standard. I ask for thinking about professional users and their usage. And I ask for firstly learning about professional computer usage and about UNIX and the UNIX principle. And first of all I mean Lennart Poettering in this case. That's only one point. I, btw., also mentioned that you filed a bug report about this particular issue to upstream and that it is hopefully fixed. But nevertheless it shows that systemd was not complete, and that the systemd developer didn't think enough before releasing it, exactly like PulseAudio.
I have the impression that you don't have a clue what you are talking about.
And all those people who criticise PA, systemd and Lennart Poettering, too, have also no clue about what they are talking? All those people who mark those comments in several other forums totally green and who send comments in which they agree have also no clue? They are all stupid? And only you have the necessary knowledge? And only you are the wisdom in person? Is this what you want to say? I have the impression that you are one of those systemd fanboys, and just don't want to hear that systemd and PA have a lot of serious issues. And like I said in another thread, we're not talking about some fancy stuff like installing a GTK theme or the like. We're talking about serious and important, system relevant stuff. Btw., still no word about the reasons, why there are regularly so many and so long discussions about PA, systemd and Lennart Poettering, and not only here on this mailing list, but everywhere on the web. Still no word why those many, long discussions only appear about PA, systemd and Lennart Poettering and not about any other piece of software. You really should start thinking about this. And you should start soon. You really should take off your rose-colored glasses.
Why don't you just delete the things you don't want?
Why are those things, which I don't need and want, installed? Why am I forced to have this systemd stuff installed? And what, if I delete them manually? Shall I always delete them again and again after every system update? Sorry, that's not the way to go. Like I said before, if you would support systemd, sytemd-tools and everything else related to systemd totally optional, and keep initscripts pure initscripts without any systemd stuff like it was before, I would say nothing. But since you really force the users to install this systemd stuff, you will have to live with such comments, and not only from me, as you should know. Heiko
On Sat, Aug 11, 2012 at 2:01 AM, Heiko Baums <lists@baums-on-web.de> wrote:
I have the impression that you are one of those systemd fanboys, and just don't want to hear that systemd and PA have a lot of serious issues.
Issues, serious or otherwise, belong in the bug-tracker. We have surprisingly few systemd/pulseaudio bugs open, considering all the noise they create on the ML.
Why don't you just delete the things you don't want?
Why are those things, which I don't need and want, installed? Why am I forced to have this systemd stuff installed? And what, if I delete them manually? Shall I always delete them again and again after every system update? Sorry, that's not the way to go.
Sorry, I didn't realise you were being serious. Of course you shouldn't delete them. If you don't use systemd they have no effect, and take hardly no space.
Like I said before, if you would support systemd, sytemd-tools and everything else related to systemd totally optional, and keep initscripts pure initscripts without any systemd stuff like it was before, I would say nothing. But since you really force the users to install this systemd stuff, you will have to live with such comments, and not only from me, as you should know.
I don't force anyone to do anything. If you see flaws in anything I do, then provide review, patches or bug reports. If you don't like the direction I'm taking initscripts in, then fork it and provide your competing version. To be clear: it has always been my plan to make initscripts and systemd as close to each other as possible and share as much code as possible. I strongly believe this is the right thing to do. If you disagree, then I think your time is better spent at coding a replacement rather than at whining. -t
Op 11 aug. 2012 03:02 schreef "Tom Gundersen" <teg@jklm.no> het volgende:
On Sat, Aug 11, 2012 at 2:01 AM, Heiko Baums <lists@baums-on-web.de>
wrote: [...]
Like I said before, if you would support systemd, sytemd-tools and everything else related to systemd totally optional, and keep initscripts pure initscripts without any systemd stuff like it was before, I would say nothing. But since you really force the users to install this systemd stuff, you will have to live with such comments, and not only from me, as you should know.
It's always funny in this subject how people seem to forget that udev no longer exists on its own. Despite the careful annoucements from Arch.
I don't force anyone to do anything. If you see flaws in anything I do, then provide review, patches or bug reports. If you don't like the direction I'm taking initscripts in, then fork it and provide your competing version.
To be clear: it has always been my plan to make initscripts and systemd as close to each other as possible and share as much code as possible. I strongly believe this is the right thing to do. If you disagree, then I think your time is better spent at coding a replacement rather than at whining.
Just for the record Tom: some of us are very happy with your work on continuening Initscripts. It sometimes looks as if 'everyone' feels they must switch to pure systemd, I for one prefer the predictability of init. Keeper up the good work! Mvg, Guus
Am Sat, 11 Aug 2012 03:02:03 +0200 schrieb Tom Gundersen <teg@jklm.no>:
Issues, serious or otherwise, belong in the bug-tracker. We have surprisingly few systemd/pulseaudio bugs open, considering all the noise they create on the ML.
Is it really that hard to respect other people's opinions and wishes? Is it really that hard?
Sorry, I didn't realise you were being serious. Of course you shouldn't delete them. If you don't use systemd they have no effect, and take hardly no space.
But they take space on my harddisk. And even TB harddisks can get full some day. And not everybody is able to afford a new one at once. And I just don't want this systemd stuff on my harddisk. But, hey, it's really hard to respect other people's opinions and wishes. I understand. If other people don't want to have anything to do with a certain software then this software has to be forced onto them because the maintainer is a fanboy of this software and can't respect other people's opinions due to his rose-colored glasses.
I don't force anyone to do anything. If you see flaws in anything I do, then provide review, patches or bug reports. If you don't like the direction I'm taking initscripts in, then fork it and provide your competing version.
You do force every Arch Linux user to install that systemd stuff. Why else do I have systemd-tools installed on my harddisk? Why else do I have all this systemd stuff in /usr/lib/systemd/system? Why else do I have even this directory /usr/lib/systemd on my harddisk? I tell you, because you force it on me. I never have installed this on my own.
To be clear: it has always been my plan to make initscripts and systemd as close to each other as possible and share as much code as possible. I strongly believe this is the right thing to do. If you disagree, then I think your time is better spent at coding a replacement rather than at whining.
I don't know what you didn't get. I have already coded the cryptsetup part of initscripts which still works, which works better than this systemd-cryptsetup thing, and which you want to replace by some untrustworthy, and at least incomplete systemd stuff. And, yes, I totally disagree that your plan to make initscripts and systemd as close to each other as possible are good. And I'm not the only one as you should know meanwhile. This, too, is forcing systemd on everbody. Initscripts worked before and would still do this. If you are a systemd fanboy then provide and support systemd optional, but leave initscripts alone and revert it to what it was, before you made all those systemd changes. But, yes, I forgot again, other people's opinions and wishes are dull and all those people don't know anything and have no clue what they are talking about. All those people on the whole wide web. And you are the wisdom in person. Are you really sure that you know what you are talking about? Are you really sure that you know what you are doing with initscripts? And, btw., I would also be interested in some opinions of the other devs and TUs about your activities in forcing this systemd stuff on everybody. You are the only dev who is permanently talking about this and hyping systemd, and meanwhile I know that you are a systemd fanboy. What about the other devs? Have your plans with all their pros and cons and the users' opinions and wishes been discussed before with the other devs? Or are you doing this all on your own? Meanwhile I have the opinion that it's the latter one. And still no word about the other tools which work on top of sysvinit which have recently be mentioned by someone else here on this mailing list. Only this systemd fanboy jabbering. Heiko
2012/8/11 Heiko Baums <lists@baums-on-web.de>:
Am Sat, 11 Aug 2012 03:02:03 +0200 schrieb Tom Gundersen <teg@jklm.no>:
Issues, serious or otherwise, belong in the bug-tracker. We have surprisingly few systemd/pulseaudio bugs open, considering all the noise they create on the ML.
Also surprising: a few people mentioned alternatives to systemd / sysvinit. AFAIK none of them started a project to implement their idea in Arch... ;)
Is it really that hard to respect other people's opinions and wishes? Is it really that hard?
Sorry, I didn't realise you were being serious. Of course you shouldn't delete them. If you don't use systemd they have no effect, and take hardly no space.
But they take space on my harddisk. And even TB harddisks can get full some day. And not everybody is able to afford a new one at once.
And I just don't want this systemd stuff on my harddisk.
Well, it should be possible to create a system (even Arch!) completely free of systemd tools. You'd have to rebuild some of the initscripts and, oh yeah, fire up mknod to create all necessary devices. As i'm sure you know, Udev is now a part of systemd. Just my two cents. mvg, Guus
2012/8/11 Guus Snijders <gsnijders@gmail.com>:
2012/8/11 Heiko Baums <lists@baums-on-web.de>:
[...]
And I just don't want this systemd stuff on my harddisk.
Well, it should be possible to create a system (even Arch!) completely free of systemd tools. You'd have to rebuild some of the initscripts and, oh yeah, fire up mknod to create all necessary devices. As i'm sure you know, Udev is now a part of systemd.
Ok, a quick reply on myself. I just read in an other thread that this last statement isn't entirely true. It seems like it's still possible to use udev stand-alone. Apologies for my ignorance. mvg, Guus
*grabs popcorn* On Sat, Aug 11, 2012 at 2:03 PM, Heiko Baums <lists@baums-on-web.de> wrote:
But they take space on my harddisk. And even TB harddisks can get full some day. And not everybody is able to afford a new one at once.
[kwpolska@kwpolska-lin ~]% du -sh /usr/lib/systemd 3.6M /usr/lib/systemd Seriously? Are 3.6M so much? So you don’t have any packages for shells other than the one you’re using? So you don’t have more than one terminal emulator? Of course you do! Then why do you care about systemd files? You can always run a rm -rf /usr/lib/systemd, you know.
And I just don't want this systemd stuff on my harddisk.
And I just don’t want this GNOME 3 stuff on my harddisk. But I don’t go whining on the MLs, I rather go pacman -R gnome. Or whatever you have. (although GNOME 3 sucks and EVERYONE will agree with that.)
But, hey, it's really hard to respect other people's opinions and wishes. I understand. If other people don't want to have anything to do with a certain software then this software has to be forced onto them because the maintainer is a fanboy of this software and can't respect other people's opinions due to his rose-colored glasses.
Told ya: pacman -R systemd; rm -rf /usr/lib/systemd. Your wishes are granted.
You do force every Arch Linux user to install that systemd stuff. Why else do I have systemd-tools installed on my harddisk? Why else do I have all this systemd stuff in /usr/lib/systemd/system? Why else do I have even this directory /usr/lib/systemd on my harddisk? I tell you, because you force it on me. I never have installed this on my own.
rm -rf /usr/lib/systemd Also, believe it or not, systemd-tools was not forced on you. systemd-tools = udev + some fancy systemd manpages and files. THAT’S IT! It could be also named udev-plus-fancy-stuff. Or i-like-turtles. Or rainbow-dash-is-best-pony. Although the last one could spawn such OT as this thread by people who aren’t (or even hate) bronies.
Initscripts worked before and would still do this. If you are a systemd fanboy then provide and support systemd optional, but leave initscripts alone and revert it to what it was, before you made all those systemd changes.
…and initscripts still work and will work for a while…
But, yes, I forgot again, other people's opinions and wishes are dull and all those people don't know anything and have no clue what they are talking about. All those people on the whole wide web. And you are the wisdom in person.
I told you how to grant your wish at least twice before, so I won’t repeat that. Your opinion? NOBODY CARES! You can still use initscripts! Nobody cares that you don’t like systemd, pulseaudio or Poettering! And if we’re talking about pulseaudio: sure, pulseaudio is a bit more “forced” on you by certain packages. But you can still live without it, I think. If you are doing “pro audio work” and you can afford a $bazillion audio card, then why can’t you afford a $200* OS? Windows will be much better! And if you really want to work like a pro, get a Mac. And if you want to stay on this fancy Linux thing used by ~nobody, and exactly 0 (read: zero) people in the pro area, especially in the pro gamer area (there are -1000 pro gamers on Linux now), and there is no way to escape PulseAudio right now, PATCHES WELCOME! Remember: systemd and pulseaudio are open-source projects. If you want to see something improved, Obligatory disclaimer: I am using three Arch systems: physical/x86_64/systemd/pulse/KDE, VM/x86_64/systemd/pulse/Xfce and VM/i686/initscripts/no-audio-at-all/Xfce. The first VM is used mainly for development under Windows (I’ve yet to see people developing linux-specific tools or even AUR helpers [pkgbuilder] under Windows), while the second one is used for a blog post that was written but isn’t since over a week. Anyways, I was criticizing both pulseaudio and systemd in their earlier stages. But now, my system (mostly) works properly. The only problematic piece of software is VLC, which has some white noise when it starts playing audio. Everyone else is fine. * = €200 from Microsoft, although it should be around €160. I love this fucking currency, especially when it’s forced on me (Steam, anyone?). Please, oh, please, kill it already. It is bloody useless. -- 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:
Am Sat, 11 Aug 2012 00:56:33 +0200 schrieb Tom Gundersen <teg@jklm.no>:
You pointed out a feature that initsrcipts used to have which systemd-cryptsetup lacked, (on the same day) I posted a patch to implement the feature you requested, and asked for feedback (which you didn't give)
Just to mention, you've also written that this patch you've written should not be used or tested in stable, productive environments. I only have one PC which needs to run stably and reliably. I can't run into danger that my data gets accidentally corrupted. And I don't trust systemd this much, but I trust my initscripts code. And I hadn't had time to set up a VM. Heiko
On Aug 11, 2012 3:11 AM, "Heiko Baums" <lists@ <lists@baums-on-web.de>baums<lists@baums-on-web.de> -on- <lists@baums-on-web.de>web.de <lists@baums-on-web.de>> wrote:
Just to mention, you've also written that this patch you've written should not be used or tested in stable, productive environments. I only have one PC which needs to run stably and reliably. I can't run into danger that my data gets accidentally corrupted. And I don't trust systemd this much, but I trust my initscripts code. And I hadn't had time to set up a VM.
So you had a problem but when Tom wrote a patch you were unwilling to help test it? The patch that was wrote to specifically address your problem? I understand you might be low on free time but you are not a costumer. Someone else fixed then problem you encountered and your response was to whine. Is this how open source is supposed to work? Lastly, are the systemd parts initscripts currently use bothering you? How so? Because they are in a folded called 'systemd'? They seem to work alright. -- Thanasis Georgiou
Am Sat, 11 Aug 2012 03:47:09 +0300 schrieb Thanasis Georgiou <sakisds.s@gmail.com>:
So you had a problem but when Tom wrote a patch you were unwilling to help test it?
What part of "I had no time to set up a VM." and "I have only one stable system which needs to be stable and reliable." didn't you get? Heiko
On Aug 11, 2012 2:38 PM, "Heiko Baums" <lists@baums-on-web.de> wrote:
Am Sat, 11 Aug 2012 03:47:09 +0300 schrieb Thanasis Georgiou <sakisds.s@gmail.com>:
So you had a problem but when Tom wrote a patch you were unwilling to help test it?
What part of "I had no time to set up a VM." and "I have only one stable system which needs to be stable and reliable." didn't you get?
Did you even read my whole email?
And I hadn't had time to set up a VM.
not to worry, the whole world of free software developers (including Arch) are here and have all the time to serve your wishes. -- дамјан
Am Sat, 11 Aug 2012 22:21:01 +0200 schrieb Damjan <gdamjan@gmail.com>:
not to worry, the whole world of free software developers (including Arch) are here and have all the time to serve your wishes.
Have you thought about that comment before sending it? Heiko
On Fri, 2012-08-10 at 14:11 +0200, Ralf Mardorf wrote:
Long-term report: The NM applet within the Xfce panel still is ok. [snip]
But I had to downgrade polkit, since I couldn't mount devices by Thunar 1.4.0 anymore. After downgrading to the regular polkit Thunar is ok again. Regards, Ralf
On 8 August 2012 10:52, Jayesh Badwaik <jayesh.badwaik90@gmail.com> wrote:
On Wednesday 08 Aug 2012 09:38:40 Lukas Jirkovsky wrote:
Works fine here with the "nearly Poettering-free" system. I'm using KDE networkmanager applet. I tested a system-wide wifi connection and it worked fine.
Are you able to use KDE without all the Poettering stuff?
-- Cheers and Regards Jayesh Badwaik stop html mail | always bottom-post www.asciiribbon.org | www.netmeister.org/news/learn2quote.html
Sure, my setup is same as Ralf's in this regard (ie. no systemd nor PA), hence the quote.
participants (31)
-
"Jérôme M. Berger"
-
Alex Belanger
-
Baho Utot
-
Brandon Watkins
-
Damjan
-
David Benfell
-
Fons Adriaensen
-
Guus Snijders
-
Heiko Baums
-
Ionut Biru
-
Jan Steffens
-
Jayesh Badwaik
-
Jelle van der Waa
-
Joakim Hernberg
-
Karol Blazewicz
-
Kevin Chadwick
-
Kwpolska
-
Leonid Isaev
-
Lukas Jirkovsky
-
Martin Zecher
-
Mauro Santos
-
Myra Nelson
-
Oon-Ee Ng
-
phani
-
Ralf Mardorf
-
Rashif Ray Rahman
-
Ray Kohler
-
Sander Jansen
-
Thanasis Georgiou
-
Tom Gundersen
-
Tom Rand