8:56 p.m.
I have a lot of seemingly pulse audio related issues on my F9 desktop.
Since I really like the idea behind Pulseaudio, I would like to see
these get sorted out, and would like to know how I can help in terms
of providing useful information.
Here is my situation
* Sounblaster Live 5.1 PCI -- has full 6 channel audio before, I had
for a short while after enabling it as per the pulseaudio wiki, but no
more
* Tvtime -- no audio (doing `padsp sox -r 48000 -w -c 2 -t ossdsp
/dev/dsp -t ossdsp /dev/dsp` works, but causes noticeable lag)
* Amarok (xine) -- audio, susceptible to crashes, esp when I scroll to
fast in Firefox
* Kopete -- used to work, mysteriously stopped working
* Konversation -- never worked
* Mythfront -- no sound yet (haven't followed
http://svn.mythtv.org/trac/ticket/3598#comment:16 yet)
* V4L tv capture card -- no sound now, used to rely on capturing AUX
on sound card before
* PulseAudio -- seems to average 30% CPU usage when playing music,
doesn't like me using Firefox too much (seems like a resource issue)
Things I use, albeit infrequently, but just work:
* flash-plugin
* Kplayer
What information should I gather, how, and where should I present it?
I'm guessing at this point you have more than enough bug reports, but
maybe not enough data.
Smolt profile for machine in question :
http://www.smolts.org/client/show/pub_e429f170-cbfd-4434-a49f-16ef2aadcb54
--
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )
6:14 a.m.
On 11/09/2008, Arthur Pemberton <pemboa(a)gmail.com> wrote:
* Sounblaster Live 5.1 PCI -- has full 6 channel audio before, I had
for a short while after enabling it as per the pulseaudio wiki, but no
more
If it's one of the SBs with multiple hardware channels, unless you are
likely to want >32 separate apps pumping out sound at once, disable PA
and just access the card through ALSA directly. It's worked ok for me
:o)
10:14 a.m.
On Thu, Sep 11, 2008 at 6:14 AM, Bill Crawford
<billcrawford1970(a)gmail.com> wrote:
On 11/09/2008, Arthur Pemberton <pemboa(a)gmail.com> wrote:
> * Sounblaster Live 5.1 PCI -- has full 6 channel audio before, I had
> for a short while after enabling it as per the pulseaudio wiki, but no
> more
If it's one of the SBs with multiple hardware channels, unless you are
likely to want >32 separate apps pumping out sound at once, disable PA
and just access the card through ALSA directly. It's worked ok for me
:o)
I'm pretty sure disabling PulseAudio will work since it worked before
PulseAudio. But disabling it defeats the purpose.
--
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )
11:40 a.m.
On 11/09/2008, Arthur Pemberton <pemboa(a)gmail.com> wrote:
On Thu, Sep 11, 2008 at 6:14 AM, Bill Crawford
<billcrawford1970(a)gmail.com> wrote:
> On 11/09/2008, Arthur Pemberton <pemboa(a)gmail.com> wrote:
>
>> * Sounblaster Live 5.1 PCI -- has full 6 channel audio before, I had
>> for a short while after enabling it as per the pulseaudio wiki, but no
>> more
>
> If it's one of the SBs with multiple hardware channels, unless you are
> likely to want >32 separate apps pumping out sound at once, disable PA
> and just access the card through ALSA directly. It's worked ok for me
> :o)
I'm pretty sure disabling PulseAudio will work since it worked before
PulseAudio. But disabling it defeats the purpose.
If you have multi-channel hardware that mixes itself, then using
PulseAudio sort of defeats the purpose of that hardware ;o)
I'll accept the argument about allowing mixing with different volume
levels from different sources, but in theory that can be done via ALSA
if the hardware allows it.
11:48 a.m.
On Thu, 2008-09-11 at 17:40 +0100, Bill Crawford wrote:
If you have multi-channel hardware that mixes itself, then using
PulseAudio sort of defeats the purpose of that hardware ;o)
You're absolutely right... if all you're using PulseAudio for is basic
mixing. But as soon as you need/want something like per-app volume
control, network transport, audio stream redirection, or audio device
hotplugging then you want PulseAudio.
--
Ignacio Vazquez-Abrams <ivazqueznet(a)gmail.com>
PLEASE don't CC me; I'm already subscribed
5:01 p.m.
On Thu, Sep 11, 2008 at 12:48:57PM -0400, Ignacio Vazquez-Abrams wrote:
On Thu, 2008-09-11 at 17:40 +0100, Bill Crawford wrote:
> If you have multi-channel hardware that mixes itself, then using
> PulseAudio sort of defeats the purpose of that hardware ;o)
You're absolutely right... if all you're using PulseAudio for is basic
mixing. But as soon as you need/want something like per-app volume
control, network transport, audio stream redirection, or audio device
hotplugging then you want PulseAudio.
How many **ordinary** Fedora users really need these **advanced**
features?
For example I have never had any serious SW problem with sound on
Linux. And I use it for more than 10 years...
Karel
--
Karel Zak <kzak(a)redhat.com>
5:30 p.m.
Karel Zak wrote:
On Thu, Sep 11, 2008 at 12:48:57PM -0400, Ignacio Vazquez-Abrams
wrote:
> On Thu, 2008-09-11 at 17:40 +0100, Bill Crawford wrote:
>> If you have multi-channel hardware that mixes itself, then using
>> PulseAudio sort of defeats the purpose of that hardware ;o)
> You're absolutely right... if all you're using PulseAudio for is basic
> mixing. But as soon as you need/want something like per-app volume
> control, network transport, audio stream redirection, or audio device
> hotplugging then you want PulseAudio.
How many **ordinary** Fedora users really need these **advanced**
features?
For example I have never had any serious SW problem with sound on
Linux. And I use it for more than 10 years...
Quite a few need network transport when you talk about thinclient. It's
made worse by the fact that in many of those situations you have a whole
bunch of extremely ordinary Fedora users to a small number of
entry-level-knowledge admins.
-Toshio
11:28 p.m.
On Fri, 2008-09-12 at 00:01 +0200, Karel Zak wrote:
On Thu, Sep 11, 2008 at 12:48:57PM -0400, Ignacio Vazquez-Abrams
wrote:
> On Thu, 2008-09-11 at 17:40 +0100, Bill Crawford wrote:
> > If you have multi-channel hardware that mixes itself, then using
> > PulseAudio sort of defeats the purpose of that hardware ;o)
>
> You're absolutely right... if all you're using PulseAudio for is basic
> mixing. But as soon as you need/want something like per-app volume
> control, network transport, audio stream redirection, or audio device
> hotplugging then you want PulseAudio.
How many **ordinary** Fedora users really need these **advanced**
features?
For example I have never had any serious SW problem with sound on
Linux. And I use it for more than 10 years...
I have USB speakers at home. I do not have them at work. I used to
have to change the alsa default device in system-config-soundcard and
then quit all open apps just to get the sound to come out of the
hotplugged USB speakers. Flash used to only play to the default alsa
soundcard. That completely totally sucks. Mac OS X and Windows
seamlessly redirect the output to the USB speakers when they are plugged
in, and when I unplug them the sound switches back to onboard instantly.
USB headphones and webcams with integrated microphones (FW iSight for
example) are also used quite often. Those get hotplugged and thus they
should just work.
I could never, ever, ever get plain ALSA to handle any sort of
hotplugging automagically. It just works with Pulse. I shouldn't have
to hand-edit random config files in both /etc and ~, reload kernel
modules so they can get different ALSA device number module parameters,
and restart apps just to get sound to go where I want it.
Dan
2:48 p.m.
On Thu, Sep 11, 2008 at 12:40 PM, Bill Crawford
<billcrawford1970(a)gmail.com> wrote:
If you have multi-channel hardware that mixes itself, then using
PulseAudio sort of defeats the purpose of that hardware ;o)
Such hardware is as far as I understand it, really no longer sold and
has not been for some time, because it just makes more sense to do in
software.
11:33 p.m.
On Fri, 2008-09-12 at 15:48 -0400, Colin Walters wrote:
On Thu, Sep 11, 2008 at 12:40 PM, Bill Crawford
<billcrawford1970(a)gmail.com> wrote:
>
> If you have multi-channel hardware that mixes itself, then using
> PulseAudio sort of defeats the purpose of that hardware ;o)
Such hardware is as far as I understand it, really no longer sold and
has not been for some time, because it just makes more sense to do in
software.
"The thing is, hardware mixing is a thing of the past, modern soundcards
don't do it anymore. Precisely for doing things like mixing in software
SIMD CPU extensions like SSE have been invented. Modern sound cards
these days are kind of "dumbed" down, high-quality DACs. They don't do
mixing anymore, many modern chips don't even do volume control anymore."
http://0pointer.de/blog/projects/jeffrey-stedfast.html
Dan
1:19 a.m.
On Mon, 2008-09-15 at 00:33 -0400, Dan Williams wrote:
"The thing is, hardware mixing is a thing of the past, modern
soundcards
don't do it anymore. Precisely for doing things like mixing in software
SIMD CPU extensions like SSE have been invented. Modern sound cards
these days are kind of "dumbed" down, high-quality DACs. They don't do
mixing anymore, many modern chips don't even do volume control anymore."
What, they still make sound cards? Onboard sound is still noisy as hell.
You can have my Aureal Vortex2 when you pry it from my cold dead hands,
or whenever they stop making PCI motherboards. (Have they already? I
haven't even looked. The last system I bought a few years back is an AGP
system since PCIe was much more expensive for no real gain at the
time...)
1:38 a.m.
On Mon, 2008-09-15 at 01:19 -0500, Callum Lerwick wrote:
On Mon, 2008-09-15 at 00:33 -0400, Dan Williams wrote:
> "The thing is, hardware mixing is a thing of the past, modern soundcards
> don't do it anymore. Precisely for doing things like mixing in software
> SIMD CPU extensions like SSE have been invented. Modern sound cards
> these days are kind of "dumbed" down, high-quality DACs. They don't
do
> mixing anymore, many modern chips don't even do volume control anymore."
What, they still make sound cards? Onboard sound is still noisy as hell.
You can have my Aureal Vortex2 when you pry it from my cold dead hands,
or whenever they stop making PCI motherboards. (Have they already? I
Not quite yet, but most vendors ship either half-and-half or just one or
two PCI slots, the rest are PCIe. Absolutely nobody ships AGP any more.
Dan
haven't even looked. The last system I bought a few years back is
an AGP
system since PCIe was much more expensive for no real gain at the
time...)
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
7:03 a.m.
On Wed, Sep 10, 2008 at 08:56:12PM -0500, Arthur Pemberton wrote:
I have a lot of seemingly pulse audio related issues on my F9
desktop.
Since I really like the idea behind Pulseaudio, I would like to see
these get sorted out, and would like to know how I can help in terms
of providing useful information.
Here is my situation
* Sounblaster Live 5.1 PCI -- has full 6 channel audio before, I had
for a short while after enabling it as per the pulseaudio wiki, but no
more
Check out these two bugs. You might be hitting this where it is
trying to use the built-in card instead of your addon PCI card by
default, perhaps only for some applications:
https://bugzilla.redhat.com/show_bug.cgi?id=441506
https://bugzilla.redhat.com/show_bug.cgi?id=448477
Run "pavucontrol" to set the default output device and monitor
applications as they play. You can right click an application stream
to change which device it is using to play through on-the-fly.
What information should I gather, how, and where should I present
it?
I'm guessing at this point you have more than enough bug reports, but
maybe not enough data.
10:37 a.m.
On Thu, Sep 11, 2008 at 7:03 AM, Chuck Anderson <cra(a)wpi.edu> wrote:
On Wed, Sep 10, 2008 at 08:56:12PM -0500, Arthur Pemberton wrote:
> I have a lot of seemingly pulse audio related issues on my F9 desktop.
> Since I really like the idea behind Pulseaudio, I would like to see
> these get sorted out, and would like to know how I can help in terms
> of providing useful information.
>
> Here is my situation
>
> * Sounblaster Live 5.1 PCI -- has full 6 channel audio before, I had
> for a short while after enabling it as per the pulseaudio wiki, but no
> more
Check out these two bugs. You might be hitting this where it is
trying to use the built-in card instead of your addon PCI card by
default, perhaps only for some applications:
https://bugzilla.redhat.com/show_bug.cgi?id=441506
https://bugzilla.redhat.com/show_bug.cgi?id=448477
I'll follow up on those reports and attempt to add useful information.
I have since previous OS (FC7) disabled the onboard sound card at the
BIOS level.
--
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )
10:29 a.m.
On Wed, 2008-09-10 at 20:56 -0500, Arthur Pemberton wrote:
I have a lot of seemingly pulse audio related issues on my F9
desktop.
Since I really like the idea behind Pulseaudio, I would like to see
these get sorted out, and would like to know how I can help in terms
of providing useful information.
Here is my situation
* Sounblaster Live 5.1 PCI -- has full 6 channel audio before, I had
for a short while after enabling it as per the pulseaudio wiki, but no
more
* Tvtime -- no audio (doing `padsp sox -r 48000 -w -c 2 -t ossdsp
/dev/dsp -t ossdsp /dev/dsp` works, but causes noticeable lag)
* Amarok (xine) -- audio, susceptible to crashes, esp when I scroll to
fast in Firefox
* Kopete -- used to work, mysteriously stopped working
* Konversation -- never worked
* Mythfront -- no sound yet (haven't followed
http://svn.mythtv.org/trac/ticket/3598#comment:16 yet)
* V4L tv capture card -- no sound now, used to rely on capturing AUX
on sound card before
* PulseAudio -- seems to average 30% CPU usage when playing music,
doesn't like me using Firefox too much (seems like a resource issue)
Things I use, albeit infrequently, but just work:
* flash-plugin
Make sure you have libflashsupport installed. I makes flash happier
with pulseaudio.
Dan
10:36 a.m.
On Thu, Sep 11, 2008 at 10:29 AM, Dan Williams <dcbw(a)redhat.com> wrote:
On Wed, 2008-09-10 at 20:56 -0500, Arthur Pemberton wrote:
> Things I use, albeit infrequently, but just work:
> * flash-plugin
Make sure you have libflashsupport installed. I makes flash happier
with pulseaudio.
As I tried to say, flash works, even though it it is a low priority for me.
And I don't want the thread to seem like I am asking for end-user
support on the devel list.
--
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )
7:57 a.m.
Arthur Pemberton <pemboa <at> gmail.com> writes:
I have a lot of seemingly pulse audio related issues on my F9 desktop.
Since I really like the idea behind Pulseaudio, I would like to see
these get sorted out, and would like to know how I can help in terms
of providing useful information.
FWIW, there is a FUSE patch, called CUSE (character device emulation in
userspace). The author also created a proof of concept userspace OSS emulation
which should work with pulseaudio, but it requires ALSA OSS emulation to be
disabled in kernel at compile time.
The implementation doesn't have mmap oss support at this time.
http://userweb.kernel.org/~tj/ossp/
kernel mailing list discussion:
http://thread.gmane.org/gmane.comp.file-systems.fuse.devel/6818/focus=6820
2:43 p.m.
Arthur Pemberton writes:
I have a lot of seemingly pulse audio related issues on my F9
desktop.
Since I really like the idea behind Pulseaudio, I would like to see
these get sorted out, and would like to know how I can help in terms
of providing useful information.
Well, let me step up to say that I feel the same way. Pulse Audio holds
great promise for accessibility, but it ain't working out in practice
yet. And, some of us are scratching our heads as to how we get from here
to there.
The problems we have right now are sufficiently sever to be
showstoppers. At the SpeakupModified.Org we recommend disabling
pulseaudio. As things stand in F-9, one gets no audio until after a user
logs in on the GUI. So, how are those who need screen reader support
supposed to use the a11y features of GDM? As it stands, there seems no
way to get console audio without that GUI login. Also a nonstarter in
the screen reader user community.
It seems a useful initial step toward resolution is to run pulseaudio
as a system daemon, via an init script, /sbin/service, /sbin/chkconfig.
The trade-offs vs the per user model that F-9 employs are probably more
than acceptable to most a11y users.
So, let me simply ask ... Has anyone a working init script for
pulseaudio as a system daemon? Anything close that we could continue to
refine as an alternative configuration option for Fedora?
Janina
Janina Sajka, Phone: +1.202.595.7777; sip:janina@a11y.org
Partner, Capital Accessibility LLC http://CapitalAccessibility.Com
Marketing the Owasys 22C talking screenless cell phone in the U.S. and Canada
Learn more at http://ScreenlessPhone.Com
Chair, Open Accessibility janina(a)a11y.org
Linux Foundation http://a11y.org
2:46 p.m.
On Fri, Sep 12, 2008 at 3:43 PM, Janina Sajka <janina(a)rednote.net> wrote:
The problems we have right now are sufficiently sever to be
showstoppers. At the SpeakupModified.Org we recommend disabling
pulseaudio. As things stand in F-9, one gets no audio until after a user
logs in on the GUI. So, how are those who need screen reader support
supposed to use the a11y features of GDM? As it stands, there seems no
way to get console audio without that GUI login. Also a nonstarter in
the screen reader user community.
If you want to run terminal applications, can't you just log in to a
full screen gnome-terminal?
It seems a useful initial step toward resolution is to run
pulseaudio
as a system daemon, via an init script, /sbin/service, /sbin/chkconfig.
The trade-offs vs the per user model that F-9 employs are probably more
than acceptable to most a11y users.
So, let me simply ask ... Has anyone a working init script for
pulseaudio as a system daemon? Anything close that we could continue to
refine as an alternative configuration option for Fedora?
We're going to be removing the legacy non-X system consoles by default
in the long run.
3:28 p.m.
On Fri, Sep 12, 2008 at 03:46:11PM -0400, Colin Walters wrote:
On Fri, Sep 12, 2008 at 3:43 PM, Janina Sajka
<janina(a)rednote.net> wrote:
>
> The problems we have right now are sufficiently sever to be
> showstoppers. At the SpeakupModified.Org we recommend disabling
> pulseaudio. As things stand in F-9, one gets no audio until after a user
> logs in on the GUI. So, how are those who need screen reader support
> supposed to use the a11y features of GDM? As it stands, there seems no
> way to get console audio without that GUI login. Also a nonstarter in
> the screen reader user community.
If you want to run terminal applications, can't you just log in to a
full screen gnome-terminal?
He wants to use audio before login to X Window. Somehow I don't understand
how do you want to fix this problem by gnome-terminal...
> It seems a useful initial step toward resolution is to run
pulseaudio
> as a system daemon, via an init script, /sbin/service, /sbin/chkconfig.
> The trade-offs vs the per user model that F-9 employs are probably more
> than acceptable to most a11y users.
>
> So, let me simply ask ... Has anyone a working init script for
> pulseaudio as a system daemon? Anything close that we could continue to
> refine as an alternative configuration option for Fedora?
We're going to be removing the legacy non-X system consoles by default
in the long run.
Yeah, we need more RAM for our hungry GUI applications :-)
Karel
--
Karel Zak <kzak(a)redhat.com>
3:30 p.m.
On Fri, Sep 12, 2008 at 10:28:13PM +0200, Karel Zak wrote:
On Fri, Sep 12, 2008 at 03:46:11PM -0400, Colin Walters wrote:
> If you want to run terminal applications, can't you just log in to a
> full screen gnome-terminal?
He wants to use audio before login to X Window. Somehow I don't understand
how do you want to fix this problem by gnome-terminal...
Audio works on the GDM login screen. Orca starts and reads the login
window to me...
3:42 p.m.
On Fri, Sep 12, 2008 at 4:30 PM, Chuck Anderson <cra(a)wpi.edu> wrote:
On Fri, Sep 12, 2008 at 10:28:13PM +0200, Karel Zak wrote:
> On Fri, Sep 12, 2008 at 03:46:11PM -0400, Colin Walters wrote:
> > If you want to run terminal applications, can't you just log in to a
> > full screen gnome-terminal?
>
> He wants to use audio before login to X Window. Somehow I don't understand
> how do you want to fix this problem by gnome-terminal...
Audio works on the GDM login screen. Orca starts and reads the login
window to me...
Exactly; the GDM team did a lot of work over the last two cycles to
make GDM fully accessible.
8:57 p.m.
Chuck Anderson writes:
Audio works on the GDM login screen. Orca starts and reads the login
window to me...
What Fedora? And, what GDM? This worked, hmm, perhaps 60-70% for me back
in Fedora 8. But GDM has gone through a massive rewrite since then. None
of the users I'm in touch with have gotten this to work on F-9 or later.
So, please share the magic if you know something we don't.
Janina
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
--
Janina Sajka, Phone: +1.202.595.7777; sip:janina@a11y.org
Partner, Capital Accessibility LLC http://CapitalAccessibility.Com
Marketing the Owasys 22C talking screenless cell phone in the U.S. and Canada
Learn more at http://ScreenlessPhone.Com
Chair, Open Accessibility janina(a)a11y.org
Linux Foundation http://a11y.org
9:11 p.m.
On Fri, Sep 12, 2008 at 9:57 PM, Janina Sajka <janina(a)rednote.net> wrote:
Chuck Anderson writes:
>
> Audio works on the GDM login screen. Orca starts and reads the login
> window to me...
What Fedora? And, what GDM? This worked, hmm, perhaps 60-70% for me back
in Fedora 8. But GDM has gone through a massive rewrite since then. None
of the users I'm in touch with have gotten this to work on F-9 or later.
I just tried this too with GDM, and got speech too. I right clicked
in the lower left of the screen, checked the "Read text" option, and
moused over and heard sound. Have you filed a bug about this issue?
9:20 p.m.
On Fri, Sep 12, 2008 at 10:11 PM, Colin Walters <walters(a)verbum.org> wrote:
On Fri, Sep 12, 2008 at 9:57 PM, Janina Sajka
<janina(a)rednote.net> wrote:
> Chuck Anderson writes:
>>
>> Audio works on the GDM login screen. Orca starts and reads the login
>> window to me...
>
>
> What Fedora? And, what GDM? This worked, hmm, perhaps 60-70% for me back
> in Fedora 8. But GDM has gone through a massive rewrite since then. None
> of the users I'm in touch with have gotten this to work on F-9 or later.
I just tried this too with GDM, and got speech too. I right clicked
in the lower left of the screen, checked the "Read text" option, and
moused over and heard sound. Have you filed a bug about this issue?
Incidentally you should be able to enable this by default so sightless
people don't have the bootstrapping problem of enabling TTS. There is
some documentation on the new GDM configuration here:
http://live.gnome.org/GDM/2.22/Configuration
Unfortunately GConf is overly complex to use (a bug we would like to
fix), but this page describes how to use GConf to set GDM's
system-wide settings:
https://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/desktop-guid...
So for example:
sudo gconftool-2 --direct --config-source
xml:readwrite:/etc/gconf/gconf.xml.defaults --type=boolean -s
/apps/gdm/simple-greeter/accessibility/screen_reader_enabled true
8:51 a.m.
Colin Walters writes:
On Fri, Sep 12, 2008 at 10:11 PM, Colin Walters
<walters(a)verbum.org> wrote:
> On Fri, Sep 12, 2008 at 9:57 PM, Janina Sajka <janina(a)rednote.net> wrote:
>> Chuck Anderson writes:
>>>
>>> Audio works on the GDM login screen. Orca starts and reads the login
>>> window to me...
>>
>>
>> What Fedora? And, what GDM? This worked, hmm, perhaps 60-70% for me back
>> in Fedora 8. But GDM has gone through a massive rewrite since then. None
>> of the users I'm in touch with have gotten this to work on F-9 or later.
>
> I just tried this too with GDM, and got speech too. I right clicked
> in the lower left of the screen, checked the "Read text" option, and
> moused over and heard sound. Have you filed a bug about this issue?
Incidentally you should be able to enable this by default so sightless
people don't have the bootstrapping problem of enabling TTS. There is
some documentation on the new GDM configuration here:
http://live.gnome.org/GDM/2.22/Configuration
I'm sure personal machines will be set up with this as a default, once
all the bugs are cleared. One known issue, last it was working in F-8,
is that you could get speech via GDM, or speech on the Desktop after
login--but not both. Rather a bug.
Also, the intent is that Ctrl-s needs to be available so that any GNOME
desktop, whether your sister's, your neighbor's, the university's, or
the local coffee stand's, can work via a reliable "gesture."
Janina
Unfortunately GConf is overly complex to use (a bug we would like to
fix), but this page describes how to use GConf to set GDM's
system-wide settings:
https://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/desktop-guid...
So for example:
sudo gconftool-2 --direct --config-source
xml:readwrite:/etc/gconf/gconf.xml.defaults --type=boolean -s
/apps/gdm/simple-greeter/accessibility/screen_reader_enabled true
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
--
Janina Sajka, Phone: +1.202.595.7777; sip:janina@a11y.org
Partner, Capital Accessibility LLC http://CapitalAccessibility.Com
Marketing the Owasys 22C talking screenless cell phone in the U.S. and Canada
Learn more at http://ScreenlessPhone.Com
Chair, Open Accessibility janina(a)a11y.org
Linux Foundation http://a11y.org
8:47 a.m.
Colin Walters writes:
On Fri, Sep 12, 2008 at 9:57 PM, Janina Sajka
<janina(a)rednote.net> wrote:
> Chuck Anderson writes:
>>
>> Audio works on the GDM login screen. Orca starts and reads the login
>> window to me...
>
>
> What Fedora? And, what GDM? This worked, hmm, perhaps 60-70% for me back
> in Fedora 8. But GDM has gone through a massive rewrite since then. None
> of the users I'm in touch with have gotten this to work on F-9 or later.
I just tried this too with GDM, and got speech too. I right clicked
in the lower left of the screen, checked the "Read text" option, and
moused over and heard sound. Have you filed a bug about this issue?
Well, the blind user will need to use the built in Ctrl-s rather than
the mouse, but this is helpful to know at least to help narrow down the
problem.
Are you gdm 2.22.x?
Janina
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
--
Janina Sajka, Phone: +1.202.595.7777; sip:janina@a11y.org
Partner, Capital Accessibility LLC http://CapitalAccessibility.Com
Marketing the Owasys 22C talking screenless cell phone in the U.S. and Canada
Learn more at http://ScreenlessPhone.Com
Chair, Open Accessibility janina(a)a11y.org
Linux Foundation http://a11y.org
1:06 p.m.
On 13/09/2008, Colin Walters <walters(a)verbum.org> wrote:
I just tried this too with GDM, and got speech too. I right clicked
in the lower left of the screen, checked the "Read text" option, and
moused over and heard sound. Have you filed a bug about this issue?
Good grief. You're actually telling people who NEED A SCREEN READER to
right click and read the text (which might be too small)??
1:17 p.m.
On Wed, Sep 17, 2008 at 2:06 PM, Bill Crawford
<billcrawford1970(a)gmail.com> wrote:
On 13/09/2008, Colin Walters <walters(a)verbum.org> wrote:
> I just tried this too with GDM, and got speech too. I right clicked
> in the lower left of the screen, checked the "Read text" option, and
> moused over and heard sound. Have you filed a bug about this issue?
Good grief. You're actually telling people who NEED A SCREEN READER to
right click and read the text (which might be too small)??
No. I followed up with a post about how this can be enabled by
default, and there is a keybinding as well.
5:15 p.m.
Colin Walters writes:
On Wed, Sep 17, 2008 at 2:06 PM, Bill Crawford
<billcrawford1970(a)gmail.com> wrote:
> On 13/09/2008, Colin Walters <walters(a)verbum.org> wrote:
>
>> I just tried this too with GDM, and got speech too. I right clicked
>> in the lower left of the screen, checked the "Read text" option, and
>> moused over and heard sound. Have you filed a bug about this issue?
>
> Good grief. You're actually telling people who NEED A SCREEN READER to
> right click and read the text (which might be too small)??
No. I followed up with a post about how this can be enabled by
default, and there is a keybinding as well.
Except that the key combo doesn't work. And, it seems Matthias now
agrees there's a bug re the availability of pulse audio:
https://bugzilla.redhat.com/show_bug.cgi?id=462537
Janina
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
--
Janina Sajka, Phone: +1.202.595.7777; sip:janina@a11y.org
Partner, Capital Accessibility LLC http://CapitalAccessibility.Com
Marketing the Owasys 22C talking screenless cell phone in the U.S. and Canada
Learn more at http://ScreenlessPhone.Com
Chair, Open Accessibility janina(a)a11y.org
Linux Foundation http://a11y.org
6:18 p.m.
On Fri, 12.09.08 22:28, Karel Zak (kzak(a)redhat.com) wrote:
> > The problems we have right now are sufficiently sever to
be
> > showstoppers. At the SpeakupModified.Org we recommend disabling
> > pulseaudio. As things stand in F-9, one gets no audio until after a user
> > logs in on the GUI. So, how are those who need screen reader support
> > supposed to use the a11y features of GDM? As it stands, there seems no
> > way to get console audio without that GUI login. Also a nonstarter in
> > the screen reader user community.
>
> If you want to run terminal applications, can't you just log in to a
> full screen gnome-terminal?
He wants to use audio before login to X Window. Somehow I don't understand
how do you want to fix this problem by gnome-terminal...
By shortening the boot time, so that we start X early and have nothing
"before" X. As soon as GDM is up PA is up too.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
3:29 p.m.
On Fri, Sep 12, 2008 at 1:46 PM, Colin Walters <walters(a)verbum.org> wrote:
If you want to run terminal applications, can't you just log in
to a
full screen gnome-terminal?
I got the impression that Janina was talking about those who need
audio to be able to login in the first place.
We're going to be removing the legacy non-X system consoles by
default
in the long run.
Those have been useful to me in a lot of circumstances that I don't
see going away anytime soon. Here are a few just off the top of my
head.
1. It's late. I'm tired. I log out, then remember some small system
administration task I meant to do. Rather than wait for all the GUI
stuff to reload as I log back in, it is much faster to switch to a
text console, login there, do my task, then log back out.
2. I'm playing some game that runs at a low resolution and it crashes.
I don't know why, but my mouse is almost always nonfunctional
afterwards. When my desktop is at 320x200 and I can't use the mouse,
regaining control is difficult. I often switch to a text console so I
can clean up some running programs in a nice way before I
Ctrl-Alt-Backspace to get my X back. (I have this happen quite often
with one particular game that my 9 year old likes. I'd run it in GDB
so I can get a backtrace and file a proper bug report, except when it
crashes I can't SEE the backtrace because my screen is at 320x200 and
my mouse is dead. Argh!)
3. I launch some X program that consumes 100% CPU and is clearly out
of control. In those cases, the mouse becomes sluggish. It can take
a very long time to either launch a gnome-terminal or get the mouse
over a gnome-terminal so I can click on it, have the click actually
move the focus to that window, type the command to kill the process,
have the typed text actually show up on the gnome-terminal, press the
Enter key, then wait the shell to process the command. It is MUCH
faster to switch to a text console, login, kill the process, logout,
and switch back to X.
Once you can guarantee that X programs won't consume 100% CPU or crash
while in a different screen resolution from my desktop, and can
guarantee that logging into an X session is below the human time
perception threshold, then I'll be ready to give up text consoles.
Until then, I want them.
--
Jerry James
http://loganjerry.googlepages.com/
4:06 p.m.
On Fri, Sep 12, 2008 at 4:29 PM, Jerry James <loganjerry(a)gmail.com> wrote:
On Fri, Sep 12, 2008 at 1:46 PM, Colin Walters
<walters(a)verbum.org> wrote:
> If you want to run terminal applications, can't you just log in to a
> full screen gnome-terminal?
I got the impression that Janina was talking about those who need
audio to be able to login in the first place.
Probably both. In any case, our answer is GDM and gnome-terminal.
Those have been useful to me in a lot of circumstances that I
don't
see going away anytime soon. Here are a few just off the top of my
head.
1. It's late. I'm tired. I log out, then remember some small system
administration task I meant to do. Rather than wait for all the GUI
stuff to reload as I log back in, it is much faster to switch to a
text console, login there, do my task, then log back out.
"Login is slow" - something we know about and makes sense to fix,
rather than having an entirely different way to log in. Another
answer is that if you hold down a magic key sequence (say
Ctrl-Shift-t) then you get just gnome-terminal.
2. I'm playing some game that runs at a low resolution and it
crashes.
I don't know why, but my mouse is almost always nonfunctional
afterwards. When my desktop is at 320x200 and I can't use the mouse,
regaining control is difficult. I often switch to a text console so I
can clean up some running programs in a nice way before I
Ctrl-Alt-Backspace to get my X back.
First, fix the app. Second, invest some in making the system robust
against applications that crash. Third, land
http://fedoraproject.org/wiki/Features/CrashHandling so you don't need
to use GDB manually.
3. I launch some X program that consumes 100% CPU and is clearly out
of control. In those cases, the mouse becomes sluggish. It can take
a very long time to either launch a gnome-terminal or get the mouse
over a gnome-terminal so I can click on it, have the click actually
move the focus to that window, type the command to kill the process,
have the typed text actually show up on the gnome-terminal, press the
Enter key, then wait the shell to process the command. It is MUCH
faster to switch to a text console, login, kill the process, logout,
and switch back to X.
I don't see that problem here with an app just burning a core. Now if
you're in swap, obviously that's a whole other issue.
5:11 p.m.
Colin Walters wrote:
> Those have been useful to me in a lot of circumstances that I don't
> see going away anytime soon. Here are a few just off the top of my
> head.
>
"Login is slow" - something we know about and makes sense to fix,
rather than having an entirely different way to log in.
How about 'starting X doesn't work'? Or can you guarantee that won't
ever happen again? And what about servers that don't need any X
programs? Or where essentially all access is through ssh, remote X
sessions, and freenx/NX?
--
Les Mikesell
lesmikesell(a)gmail.com
5:16 p.m.
On Fri, Sep 12, 2008 at 5:59 PM, Matthew Woehlke
<mw_triad(a)users.sourceforge.net> wrote:
Colin Walters wrote:
>
> We're going to be removing the legacy non-X system consoles by default
> in the long run.
Um... what happens then when X is broken?
What happens when the linux kernel is broken? What happens when
/bin/sh is broken? What happens when NetworkManager is broken? You
fix the bug.
Also, one thing I would like to see Fedora install by default is a
compressed recovery image, rather than just multiple kernels.
5:19 p.m.
On Fri, Sep 12, 2008 at 5:16 PM, Colin Walters <walters(a)verbum.org> wrote:
On Fri, Sep 12, 2008 at 5:59 PM, Matthew Woehlke
<mw_triad(a)users.sourceforge.net> wrote:
> Colin Walters wrote:
>>
>> We're going to be removing the legacy non-X system consoles by default
>> in the long run.
>
> Um... what happens then when X is broken?
What happens when the linux kernel is broken? What happens when
/bin/sh is broken? What happens when NetworkManager is broken? You
fix the bug.
I think you misunderstand? X being broken isn't always a bug. It can
simply be a configuration issue. How is one suppose to fix a config
issue with X in this scenario?
--
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )
5:24 p.m.
Colin Walters wrote:
On Fri, Sep 12, 2008 at 5:59 PM, Matthew Woehlke
<mw_triad(a)users.sourceforge.net> wrote:
> Colin Walters wrote:
>> We're going to be removing the legacy non-X system consoles by default
>> in the long run.
> Um... what happens then when X is broken?
What happens when the linux kernel is broken? What happens when
/bin/sh is broken? What happens when NetworkManager is broken? You
fix the bug.
Errr, when the kernel or shell are broken you don't run at all until you
fix them. When X isn't running, you run faster and more efficiently.
--
Les Mikesell
lesmikesell(a)gmail.com
5:36 p.m.
Colin Walters wrote:
On Fri, Sep 12, 2008 at 5:59 PM, Matthew Woehlke
<mw_triad(a)users.sourceforge.net> wrote:
> Colin Walters wrote:
>> We're going to be removing the legacy non-X system consoles by default
>> in the long run.
> Um... what happens then when X is broken?
What happens when the linux kernel is broken?
...then you boot from a disk with a bootable kernel.
What happens when /bin/sh is broken?
Hmm... then you probably need a rescue disk to replace /bin/sh.
What happens when NetworkManager is broken?
You fix it :-). You've degenerated from errors that result in an
unusable system (meaning: cannot boot to a command prompt from which, at
the least, basic repair tools are available) to errors that are
potentially mere annoyances.
Let's go back to my question:
> What happens when X is broken?
Then you boot in non-X mode.
Oh, wait. You want to remove non-X mode. You want me to have to go find
a rescue disk, just because 'yum update nvidia' wasn't such a good idea?
No, thanks; I'd rather have X fail to start and dump me at a normal
console from which I can fix the problem *without rebooting*, much less
needing to dig up a rescue disk :P.
Currently non-functioning X is like non-functioning network; annoying,
but not crippling (kernel still works, shell still works, still possible
to run commands, do debugging, etc., without rebooting or a rescue
disk). You're proposing to make it a system-crippling problem. I will
suggest that making a known-fragile component *required* for a
functional system, including any chance of repair (short of a rescue
disk), is the worst idea I've heard in a while. (But I /have/ heard it
before. It's called "Windows". YTH do we want to copy /that/?)
...not to mention that X is bloated and completely unneeded overhead on
servers. Even Microsoft realizes this; I hear 2008 has a non-GUI mode
for exactly this reason.
Also, one thing I would like to see Fedora install by default is a
compressed recovery image, rather than just multiple kernels.
That would help, but would still require rebooting all the time until X
is working (anyone say "PITA"?). Currently, "bad kernel" is the only
situation that needs a reboot to test if it works. (Well, non-working
/bin/sh depends on why it is non-working; if it's a bad binary, you can
try to run it as a subshell, so no reboot needed. If it's an interaction
with other bits of the system, it might fall into the 'needs reboot to
test' category. But non-working X currently is comfortably NOT in the
'needs reboot' category.)
--
Matthew
What? This signature /again/?
5:52 p.m.
On Fri, Sep 12, 2008 at 6:36 PM, Matthew Woehlke
<mw_triad(a)users.sourceforge.net> wrote:
No,
thanks; I'd rather have X fail to start and dump me at a normal console from
which I can fix the problem *without rebooting*, much less needing to dig up
a rescue disk :P.
I believe we already do that today, and am not advocating removing
that functionality if possible. Anyways, I've said what I need to, so
hopefully people won't be surprised later.
5:59 p.m.
On Fri, Sep 12, 2008 at 5:52 PM, Colin Walters <walters(a)verbum.org> wrote:
On Fri, Sep 12, 2008 at 6:36 PM, Matthew Woehlke
<mw_triad(a)users.sourceforge.net> wrote:
> No,
> thanks; I'd rather have X fail to start and dump me at a normal console from
> which I can fix the problem *without rebooting*, much less needing to dig up
> a rescue disk :P.
I believe we already do that today, and am not advocating removing
that functionality if possible. Anyways, I've said what I need to, so
hopefully people won't be surprised later.
I'm confused. Is Fedora really going to remove non X consoles?
--
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )
6:02 p.m.
On Fri, Sep 12, 2008 at 6:59 PM, Arthur Pemberton <pemboa(a)gmail.com> wrote:
On Fri, Sep 12, 2008 at 5:52 PM, Colin Walters
<walters(a)verbum.org> wrote:
> On Fri, Sep 12, 2008 at 6:36 PM, Matthew Woehlke
> <mw_triad(a)users.sourceforge.net> wrote:
>
>> No,
>> thanks; I'd rather have X fail to start and dump me at a normal console from
>> which I can fix the problem *without rebooting*, much less needing to dig up
>> a rescue disk :P.
>
> I believe we already do that today, and am not advocating removing
> that functionality if possible. Anyways, I've said what I need to, so
> hopefully people won't be surprised later.
I'm confused. Is Fedora really going to remove non X consoles?
I'm talking about the direction and technology of the desktop product;
what server images, embedded etc. do is an entirely different matter.
6:05 p.m.
On Fri, Sep 12, 2008 at 6:02 PM, Colin Walters <walters(a)verbum.org> wrote:
On Fri, Sep 12, 2008 at 6:59 PM, Arthur Pemberton
<pemboa(a)gmail.com> wrote:
> On Fri, Sep 12, 2008 at 5:52 PM, Colin Walters <walters(a)verbum.org> wrote:
>> On Fri, Sep 12, 2008 at 6:36 PM, Matthew Woehlke
>> <mw_triad(a)users.sourceforge.net> wrote:
>>
>>> No,
>>> thanks; I'd rather have X fail to start and dump me at a normal console
from
>>> which I can fix the problem *without rebooting*, much less needing to dig up
>>> a rescue disk :P.
>>
>> I believe we already do that today, and am not advocating removing
>> that functionality if possible. Anyways, I've said what I need to, so
>> hopefully people won't be surprised later.
>
>
> I'm confused. Is Fedora really going to remove non X consoles?
I'm talking about the direction and technology of the desktop product;
what server images, embedded etc. do is an entirely different matter.
What is the proper procedure for adding input to this decision?
--
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )
7:34 p.m.
On Fri, Sep 12, 2008 at 07:02:16PM -0400, Colin Walters wrote:
On Fri, Sep 12, 2008 at 6:59 PM, Arthur Pemberton
<pemboa(a)gmail.com> wrote:
> On Fri, Sep 12, 2008 at 5:52 PM, Colin Walters <walters(a)verbum.org> wrote:
>> On Fri, Sep 12, 2008 at 6:36 PM, Matthew Woehlke
>> <mw_triad(a)users.sourceforge.net> wrote:
>>
>>> No,
>>> thanks; I'd rather have X fail to start and dump me at a normal console
from
>>> which I can fix the problem *without rebooting*, much less needing to dig
up
>>> a rescue disk :P.
>>
>> I believe we already do that today, and am not advocating removing
>> that functionality if possible. Anyways, I've said what I need to, so
>> hopefully people won't be surprised later.
>
>
> I'm confused. Is Fedora really going to remove non X consoles?
I'm talking about the direction and technology of the desktop product;
What is reason for this "direction"? I still don't see any technical
reason. What is wrong with mingetty(8)?
BTW, "We're going to remove..." -- who is "We"?
Karel
--
Karel Zak <kzak(a)redhat.com>
8:27 p.m.
On Fri, 2008-09-12 at 19:02 -0400, Colin Walters wrote:
I'm talking about the direction and technology of the desktop
product;
what server images, embedded etc. do is an entirely different matter.
Desktop Product? We don't make a desktop product. We make a linux
distribution.
What "Desktop Product" are you talking about?
-sv
8:39 p.m.
On Fri, Sep 12, 2008 at 9:27 PM, Seth Vidal <skvidal(a)fedoraproject.org> wrote:
On Fri, 2008-09-12 at 19:02 -0400, Colin Walters wrote:
> I'm talking about the direction and technology of the desktop product;
> what server images, embedded etc. do is an entirely different matter.
Desktop Product? We don't make a desktop product.
The live CD image, combined with the default comps tree from
"gnome-desktop" is what I consider the desktop product.
We make a linux
distribution.
I am certainly not here to make a "linux distribution", which I
consider a derogatory term. It implies that all we do is take the
linux kernel and a bunch of tarballs we found on the internet, compile
them, and throw the binaries over the wall. The goal is rather to
make a compelling and useful free desktop operating system. To do
that, you need to make choices about how the operating system works,
and how pieces fit together. If people want an OS that tries to
support every possible configuration of every tarball that can be
found on the Internet, and is consequently near-paralyzed by choice
and is only able to make releases every 5 years, debian.org is -->
that way.
9:05 p.m.
Colin Walters writes:
On Fri, Sep 12, 2008 at 9:27 PM, Seth Vidal
<skvidal(a)fedoraproject.org> wrote:
> On Fri, 2008-09-12 at 19:02 -0400, Colin Walters wrote:
>
>> I'm talking about the direction and technology of the desktop product;
>> what server images, embedded etc. do is an entirely different matter.
>
>
> Desktop Product? We don't make a desktop product.
The live CD image, combined with the default comps tree from
"gnome-desktop" is what I consider the desktop product.
> We make a linux
> distribution.
I am certainly not here to make a "linux distribution", which I
consider a derogatory term.
And this is your reason for denying others the choice they would make?
Well, that rather speaks for itself, imho.
In any case, thanks for hijacking the thread away from pulseaudio. I
guess the system daemon is still purely theoretical--described on
pulseaudio.org without specifics.
Janina
--
Janina Sajka, Phone: +1.202.595.7777; sip:janina@a11y.org
Partner, Capital Accessibility LLC http://CapitalAccessibility.Com
Marketing the Owasys 22C talking screenless cell phone in the U.S. and Canada
Learn more at http://ScreenlessPhone.Com
Chair, Open Accessibility janina(a)a11y.org
Linux Foundation http://a11y.org
5:56 a.m.
On Saturday, 13 September 2008 at 03:39, Colin Walters wrote:
On Fri, Sep 12, 2008 at 9:27 PM, Seth Vidal
<skvidal(a)fedoraproject.org> wrote:
> On Fri, 2008-09-12 at 19:02 -0400, Colin Walters wrote:
>
>> I'm talking about the direction and technology of the desktop product;
>> what server images, embedded etc. do is an entirely different matter.
>
>
> Desktop Product? We don't make a desktop product.
The live CD image, combined with the default comps tree from
"gnome-desktop" is what I consider the desktop product.
So let me get this straight. You only want to disable text mode consoles
in the live CD spin? Why didn't you say so in the beginning? Even so,
it is still a bad idea.
> We make a linux distribution.
I am certainly not here to make a "linux distribution", which I
consider a derogatory term.
What? Are you serious? I certainly am here to do that and I'm proud
of it. And I know many others who feel the same.
It implies that all we do is take the
linux kernel and a bunch of tarballs we found on the internet, compile
them, and throw the binaries over the wall.
It implies no such thing. I don't know where you get your ideas, but
please keep them away from Fedora.
The goal is rather to
make a compelling and useful free desktop operating system.
"Useful" is the key word here. Why you insist on calling it "desktop"
OS, I don't know. Maybe you're not talking about Fedora.
To do
that, you need to make choices about how the operating system works,
and how pieces fit together. If people want an OS that tries to
support every possible configuration of every tarball that can be
found on the Internet,
That's a non-sequitur and you know it. Giving users a distribution that
will allow them to run whatever software they want (regardless of whether
it is included in Fedora or not) is one of the goals of Fedora, but
this has nothing to do with text mode consoles being there or not.
and is consequently near-paralyzed by choice
and is only able to make releases every 5 years, debian.org is -->
that way.
Apparently you don't listen to what users have to say. If you want to
support only a single configuration and deny users the choice,
apple.com is ---> that way. Or maybe microsoft.com. Definitely NOT
fedoraproject.org.
Regards,
R.
--
Fedora http://fedoraproject.org/wiki/User:Rathann
Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
5:41 a.m.
On Saturday, 13 September 2008 at 01:02, Colin Walters wrote:
On Fri, Sep 12, 2008 at 6:59 PM, Arthur Pemberton
<pemboa(a)gmail.com> wrote:
> On Fri, Sep 12, 2008 at 5:52 PM, Colin Walters <walters(a)verbum.org> wrote:
>> On Fri, Sep 12, 2008 at 6:36 PM, Matthew Woehlke
>> <mw_triad(a)users.sourceforge.net> wrote:
>>
>>> No,
>>> thanks; I'd rather have X fail to start and dump me at a normal console
from
>>> which I can fix the problem *without rebooting*, much less needing to dig
up
>>> a rescue disk :P.
>>
>> I believe we already do that today, and am not advocating removing
>> that functionality if possible. Anyways, I've said what I need to, so
>> hopefully people won't be surprised later.
>
>
> I'm confused. Is Fedora really going to remove non X consoles?
I'm talking about the direction and technology of the desktop product;
what server images, embedded etc. do is an entirely different matter.
Except there are no "server images" in Fedora. And I want text mode
consoles on my desktop! Why do you want to remove them? You have been
asked several times already and provide no answers so far.
Regards,
R.
--
Fedora http://fedoraproject.org/wiki/User:Rathann
Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
5:35 a.m.
Le Sam 13 septembre 2008 00:59, Arthur Pemberton a écrit :
On Fri, Sep 12, 2008 at 5:52 PM, Colin Walters <walters(a)verbum.org>
wrote:
> On Fri, Sep 12, 2008 at 6:36 PM, Matthew Woehlke
> <mw_triad(a)users.sourceforge.net> wrote:
>
>> No,
>> thanks; I'd rather have X fail to start and dump me at a normal
>> console from
>> which I can fix the problem *without rebooting*, much less needing
>> to dig up
>> a rescue disk :P.
>
> I believe we already do that today, and am not advocating removing
> that functionality if possible. Anyways, I've said what I need to,
> so
> hopefully people won't be surprised later.
I'm confused. Is Fedora really going to remove non X consoles?
Mid-term that wouln't be such a bad idea. Of course the replacements
need to prove their robustness.
--
Nicolas Mailhot
5:57 a.m.
On Monday, 15 September 2008 at 12:35, Nicolas Mailhot wrote:
Le Sam 13 septembre 2008 00:59, Arthur Pemberton a écrit :
>
> On Fri, Sep 12, 2008 at 5:52 PM, Colin Walters <walters(a)verbum.org>
> wrote:
>> On Fri, Sep 12, 2008 at 6:36 PM, Matthew Woehlke
>> <mw_triad(a)users.sourceforge.net> wrote:
>>
>>> No,
>>> thanks; I'd rather have X fail to start and dump me at a normal
>>> console from
>>> which I can fix the problem *without rebooting*, much less needing
>>> to dig up
>>> a rescue disk :P.
>>
>> I believe we already do that today, and am not advocating removing
>> that functionality if possible. Anyways, I've said what I need to,
>> so
>> hopefully people won't be surprised later.
>
>
> I'm confused. Is Fedora really going to remove non X consoles?
Mid-term that wouln't be such a bad idea.
One would have to say why it is a good idea in the first place.
Of course the replacements need to prove their robustness.
What replacements do you have in mind?
Regards,
R.
--
Fedora http://fedoraproject.org/wiki/User:Rathann
Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
6:39 a.m.
Le Lun 15 septembre 2008 12:57, Dominik 'Rathann' Mierzejewski a écrit :
On Monday, 15 September 2008 at 12:35, Nicolas Mailhot wrote:
> Le Sam 13 septembre 2008 00:59, Arthur Pemberton a écrit :
> > I'm confused. Is Fedora really going to remove non X consoles?
>
> Mid-term that wouln't be such a bad idea.
One would have to say why it is a good idea in the first place.
Simply put, non-X-console input is a mess (X input is a mess too but
at least there are people trying to fix it), non-X-console font
support has fossilized, and support for modern high resolution screens
is severely lacking.
The console has not evolved for a long time, while text requirements
have gone up. At this point a dumbed down text-only X session is
probably the only credible console future (or something that is not X
at all but uses many libraries we associate with apps now).
Non-X-console state is so bad nowadays I don't bother reporting bugs
on it. Even if they are fixed they always reappear the next Fedora
cycle. There is simply not enough console users and console
developpers to do anything but life support anymore.
And that's ok. Do remember that X was defined at a time hardware was
vastly less powerful and core X is not wasteful at all. Compared to
how the rest of the system has bloated, X is definitely lean and mean.
--
Nicolas Mailhot
7:04 a.m.
On Monday, 15 September 2008 at 13:39, Nicolas Mailhot wrote:
Le Lun 15 septembre 2008 12:57, Dominik 'Rathann' Mierzejewski a écrit :
>
> On Monday, 15 September 2008 at 12:35, Nicolas Mailhot wrote:
>> Le Sam 13 septembre 2008 00:59, Arthur Pemberton a écrit :
>> > I'm confused. Is Fedora really going to remove non X consoles?
>>
>> Mid-term that wouln't be such a bad idea.
>
> One would have to say why it is a good idea in the first place.
Simply put, non-X-console input is a mess (X input is a mess too but
at least there are people trying to fix it), non-X-console font
support has fossilized, and support for modern high resolution screens
is severely lacking.
That doesn't make it useless, nor is grounds for removal. Admittedly
it is not something people use on a daily bases (even if I do know
a few who do), but it still has its applications.
The console has not evolved for a long time, while text requirements
have gone up. At this point a dumbed down text-only X session is
probably the only credible console future (or something that is not X
at all but uses many libraries we associate with apps now).
Irrelevant. I'm not saying the text mode console has to have the
same usability as a full-screen terminal emulator running on X.
Non-X-console state is so bad nowadays I don't bother reporting
bugs
on it. Even if they are fixed they always reappear the next Fedora
cycle. There is simply not enough console users and console
developpers to do anything but life support anymore.
I don't know of any bugs that prevent me or my colleagues from using
the text mode console. That's not to say they don't exist, but I've
never heard of any problems with the console either personally or from
my colleagues.
And that's ok. Do remember that X was defined at a time hardware
was
vastly less powerful and core X is not wasteful at all. Compared to
how the rest of the system has bloated, X is definitely lean and mean.
That doesn't mean you have to disable the text mode console.
Regards,
R.
--
Fedora http://fedoraproject.org/wiki/User:Rathann
Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
7:26 a.m.
Le Lun 15 septembre 2008 14:04, Dominik 'Rathann' Mierzejewski a écrit :
On Monday, 15 September 2008 at 13:39, Nicolas Mailhot wrote:
>
> The console has not evolved for a long time, while text
requirements
> have gone up. At this point a dumbed down text-only X session is
> probably the only credible console future (or something that is not
> X
> at all but uses many libraries we associate with apps now).
Irrelevant. I'm not saying the text mode console has to have the
same usability as a full-screen terminal emulator running on X.
That may be irrelevant for you but that's not irrelevant for me both
as a console user and as someone who is an upstream maintainer for my
language of some of the bits the console use.
The separation between the X text stack and the console text stack is
not worth the maintenance burden. As evidenced by the fact the
maintenance part of the console text stack (even as
iso-functionnality) is not done properly anymore.
> Non-X-console state is so bad nowadays I don't bother
reporting bugs
> on it. Even if they are fixed they always reappear the next Fedora
> cycle. There is simply not enough console users and console
> developpers to do anything but life support anymore.
I don't know of any bugs that prevent me or my colleagues from using
the text mode console.
Lucky you.
That's not to say they don't exist, but I've
never heard of any problems with the console either personally or from
my colleagues.
So it works for you.
OSS works for some people too.
> And that's ok. Do remember that X was defined at a time
hardware was
> vastly less powerful and core X is not wasteful at all. Compared to
> how the rest of the system has bloated, X is definitely lean and
> mean.
That doesn't mean you have to disable the text mode console.
Do you volunteer for maintening all the stuff text mode console relies
on (fonts, layout definitions, etc)?
--
Nicolas Mailhot
9:07 a.m.
On Monday, 15 September 2008 at 14:26, Nicolas Mailhot wrote:
Le Lun 15 septembre 2008 14:04, Dominik 'Rathann' Mierzejewski a écrit :
>
> On Monday, 15 September 2008 at 13:39, Nicolas Mailhot wrote:
>>
>> The console has not evolved for a long time, while text requirements
>> have gone up. At this point a dumbed down text-only X session is
>> probably the only credible console future (or something that is not
>> X
>> at all but uses many libraries we associate with apps now).
>
> Irrelevant. I'm not saying the text mode console has to have the
> same usability as a full-screen terminal emulator running on X.
That may be irrelevant for you but that's not irrelevant for me both
as a console user and as someone who is an upstream maintainer for my
language of some of the bits the console use.
Read the second sentence again.
The separation between the X text stack and the console text stack
is
not worth the maintenance burden. As evidenced by the fact the
maintenance part of the console text stack (even as
iso-functionnality) is not done properly anymore.
Please point to the evidenced fact.
>> Non-X-console state is so bad nowadays I don't bother
reporting bugs
>> on it. Even if they are fixed they always reappear the next Fedora
>> cycle. There is simply not enough console users and console
>> developpers to do anything but life support anymore.
>
> I don't know of any bugs that prevent me or my colleagues from using
> the text mode console.
Lucky you.
> That's not to say they don't exist, but I've
> never heard of any problems with the console either personally or from
> my colleagues.
So it works for you.
OSS works for some people too.
Do you mean Open Source Software or Open Sound System? In case of OSS,
it's realy a shame, because it was (and still is) a great piece of software
with nice API and doesn't require any external libraries like ALSA.
But you can't compare console/X to OSS/ALSA. The latter provide functionality
on the same level, the former are completely different.
>> And that's ok. Do remember that X was defined at a time
hardware was
>> vastly less powerful and core X is not wasteful at all. Compared to
>> how the rest of the system has bloated, X is definitely lean and
>> mean.
>
> That doesn't mean you have to disable the text mode console.
Do you volunteer for maintening all the stuff text mode console relies
on (fonts, layout definitions, etc)?
Please point me to what needs maintaining and I'll see if I can get
one of my colleagues to handle that.
Regards,
R.
--
Fedora http://fedoraproject.org/wiki/User:Rathann
Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
9:33 a.m.
Le Lun 15 septembre 2008 16:07, Dominik 'Rathann' Mierzejewski a écrit :
On Monday, 15 September 2008 at 14:26, Nicolas Mailhot wrote:
>
>
> Le Lun 15 septembre 2008 14:04, Dominik 'Rathann' Mierzejewski a
> écrit :
> > That doesn't mean you have to disable the text mode
console.
>
> Do you volunteer for maintening all the stuff text mode console
> relies
> on (fonts, layout definitions, etc)?
Please point me to what needs maintaining and I'll see if I can get
one of my colleagues to handle that.
The whole console layout database needs to be re-synched with the xorg
one (People have stopped submitting patches to kbd every time they fix
an xkeyboard-config bug. After several years of such the disconnect is
getting huge).
The whole console font set needs to be dumped and the console taught
to use generic truetype/opentype fonts (likewise, bugs are fixed in
modern fonts but not legacy console fonts, plus legacy fonts are
limited to 256 glyphs so each time someone gets to add a glyph for a
language he breaks another one. A year ago I've asked volunteers to
look at console fonts. So far no one answered).
For some reason switching to the console displays an @ nowadays login
does not work as a result right now.
Can't login, broken display and buggy keyboard layouts. I don't see
how the situation could be worse (but I'm sure next month rawhide will
show me).
--
Nicolas Mailhot
9:53 a.m.
Nicolas Mailhot wrote:
> Please point me to what needs maintaining and I'll see if I
can get
> one of my colleagues to handle that.
>
The whole console layout database needs to be re-synched with the xorg
one (People have stopped submitting patches to kbd every time they fix
an xkeyboard-config bug.
We mix two different concepts here -- "console" and "serial tty".
Linux
console is more richly -- color support, different size, mouse support,
screen history etc. -- but IMHO it is just an enhancement for the
"simply serial-like tty".
If people actually want "just a tty" (plus some additional convenience
unlike in "dumb" tty), then the re-sync of databases with X etc. seems
not needed.
The whole console font set needs to be dumped and the console taught
to use generic truetype/opentype fonts
For me, just one font for more than 10 years... As if it is a dumb tty.
Noone will work on console "as under X" -- it has another target.
Can't login, broken display and buggy keyboard layouts. I
don't see
how the situation could be worse
Well, just do not use console! But do not deprecate it for me (it works
for me now properly).
~buc
http://www.fedoraproject.org/wiki/DmitryButskoy
10:01 a.m.
Le Lun 15 septembre 2008 16:53, Dmitry Butskoy a écrit :
Nicolas Mailhot wrote:
>> Please point me to what needs maintaining and I'll see if I can get
>> one of my colleagues to handle that.
[...] seems not needed.
[...] But do not deprecate it for me
Well if no one wants to stand for the console or feels concerned with
its problems I'll certainly push for it to be marked as unmaintained
junkware.
--
Nicolas Mailhot
10:09 a.m.
On Monday, 15 September 2008 at 17:01, Nicolas Mailhot wrote:
Le Lun 15 septembre 2008 16:53, Dmitry Butskoy a écrit :
>
> Nicolas Mailhot wrote:
>>> Please point me to what needs maintaining and I'll see if I can get
>>> one of my colleagues to handle that.
> [...] seems not needed.
> [...] But do not deprecate it for me
Well if no one wants to stand for the console or feels concerned with
its problems I'll certainly push for it to be marked as unmaintained
junkware.
I said I'd ask my colleague. Were you expecting an answer within 5 minutes?
And I thought my voice in this thread was clearly concerned enough, so
I don't really understand why you're saying nobody feels concerned. Are
you trying to ignore the voice of the community, too?
Regards,
R.
--
Fedora http://fedoraproject.org/wiki/User:Rathann
Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
10:19 a.m.
Le Lun 15 septembre 2008 17:09, Dominik 'Rathann' Mierzejewski a écrit :
On Monday, 15 September 2008 at 17:01, Nicolas Mailhot wrote:
>
>
> Le Lun 15 septembre 2008 16:53, Dmitry Butskoy a écrit :
> >
> > Nicolas Mailhot wrote:
> >>> Please point me to what needs maintaining and I'll see if I can
> get
> >>> one of my colleagues to handle that.
>
> > [...] seems not needed.
>
> > [...] But do not deprecate it for me
>
> Well if no one wants to stand for the console or feels concerned
> with
> its problems I'll certainly push for it to be marked as unmaintained
> junkware.
I said I'd ask my colleague. Were you expecting an answer within 5
minutes?
Sorry, I read your message as a no. I guess I'm just too disgusted at
the situation and should drop the subject. I don't think I've anything
else to add.
--
Nicolas Mailhot
6:39 p.m.
On Mon, 15.09.08 16:07, Dominik 'Rathann' Mierzejewski (dominik(a)greysector.net)
wrote:
Do you mean Open Source Software or Open Sound System? In case of
OSS,
it's realy a shame, because it was (and still is) a great piece of software
with nice API and doesn't require any external libraries like ALSA.
But you can't compare console/X to OSS/ALSA. The latter provide functionality
I must correct you: the OSS API sucks. And ALSA is certainly a far
greater piece of software than OSS ever was, and among the reasons is
precisely the fact that it is a proper library instead of some fucked up kernel
interface based on ioctls().
Everyone hates ioctl()s. The kernel people do. The userspace people
too. An API for application usage that is based around ioctl()s is
thus mandatorily a big failure.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
3:54 a.m.
On Tuesday, 23 September 2008 at 01:39, Lennart Poettering wrote:
On Mon, 15.09.08 16:07, Dominik 'Rathann' Mierzejewski
(dominik(a)greysector.net) wrote:
> Do you mean Open Source Software or Open Sound System? In case of OSS,
> it's realy a shame, because it was (and still is) a great piece of software
> with nice API and doesn't require any external libraries like ALSA.
> But you can't compare console/X to OSS/ALSA. The latter provide functionality
I must correct you: the OSS API sucks. And ALSA is certainly a far
greater piece of software than OSS ever was, and among the reasons is
precisely the fact that it is a proper library instead of some fucked up kernel
interface based on ioctls().
Everyone hates ioctl()s. The kernel people do. The userspace people
too. An API for application usage that is based around ioctl()s is
thus mandatorily a big failure.
The people whose opinion I value disagree. I have no strong opinion
of my own, because I never wrote code to interface with either ALSA
or OSS.
Regards,
R.
--
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
7:21 a.m.
On Tue, 23.09.08 10:54, Dominik 'Rathann' Mierzejewski (dominik(a)greysector.net)
wrote:
> > Do you mean Open Source Software or Open Sound System? In
case of OSS,
> > it's realy a shame, because it was (and still is) a great piece of
software
> > with nice API and doesn't require any external libraries like ALSA.
> > But you can't compare console/X to OSS/ALSA. The latter provide
functionality
>
> I must correct you: the OSS API sucks. And ALSA is certainly a far
> greater piece of software than OSS ever was, and among the reasons is
> precisely the fact that it is a proper library instead of some fucked up kernel
> interface based on ioctls().
>
> Everyone hates ioctl()s. The kernel people do. The userspace people
> too. An API for application usage that is based around ioctl()s is
> thus mandatorily a big failure.
The people whose opinion I value disagree. I have no strong opinion
of my own, because I never wrote code to interface with either ALSA
or OSS.
Oh my. So you know someone who thinks that ioctl()s are ingenious API
design? You probably should choose your friends more carefully, then. ;-)
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
7:26 a.m.
On Tue, Sep 23, 2008 at 02:21:26PM +0200, Lennart Poettering wrote:
Oh my. So you know someone who thinks that ioctl()s are ingenious
API
design? You probably should choose your friends more carefully, then. ;-)
ALSA's kernel interface is 100% ioctl. It doesn't even use read() or
write().
OG.
7:37 a.m.
On Tue, 23.09.08 14:26, Olivier Galibert (galibert(a)pobox.com) wrote:
On Tue, Sep 23, 2008 at 02:21:26PM +0200, Lennart Poettering wrote:
> Oh my. So you know someone who thinks that ioctl()s are ingenious API
> design? You probably should choose your friends more carefully, then. ;-)
ALSA's kernel interface is 100% ioctl. It doesn't even use read() or
write().
I know. But ALSA hides that in a library, so you never have to deal
with these ugly details. Ain't that great?
OTOH OSS' programmers interface *is* the ioctls themselves. And that's
one reason why its API sucks.
Also, OSS is practically not virtualizable. (LD_PRELOAD and CUSE are
hacks, that only work for the smallest part) The timing model is
broken. The entire design is hardware-specific, and focusses on hw we
had 20 years ago.
OSS as an API is terrible.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
8:26 a.m.
On Tue, Sep 23, 2008 at 02:37:48PM +0200, Lennart Poettering wrote:
OTOH OSS' programmers interface *is* the ioctls themselves. And
that's
one reason why its API sucks.
Thats a 'nobody wrote the library' case
Also, OSS is practically not virtualizable. (LD_PRELOAD and CUSE are
hacks, that only work for the smallest part) The timing model is
broken. The entire design is hardware-specific, and focusses on hw we
The timing model is crap, but the rest of the design is neither hardware
specific no focussed on twenty year old hardware - in fact todays hardware
looks more and more like the hardware of twenty years ago but with more
channels.
9:01 a.m.
On Tue, 23.09.08 09:26, Alan Cox (alan(a)redhat.com) wrote:
On Tue, Sep 23, 2008 at 02:37:48PM +0200, Lennart Poettering wrote:
> OTOH OSS' programmers interface *is* the ioctls themselves. And that's
> one reason why its API sucks.
Thats a 'nobody wrote the library' case
No it's not. The people behind OSS (i.e. Hannu) advertise the kernel
API is the audio API to use for normal programs. Because they do this
they moved mixing and sample type conversion into the kernel in OSS4.
> Also, OSS is practically not virtualizable. (LD_PRELOAD and CUSE
are
> hacks, that only work for the smallest part) The timing model is
> broken. The entire design is hardware-specific, and focusses on hw we
The timing model is crap, but the rest of the design is neither hardware
specific no focussed on twenty year old hardware - in fact todays hardware
looks more and more like the hardware of twenty years ago but with more
channels.
Oh, of course it is hardware specific. Stuff like fragments and stuff
are very hardware specific. Software sound servers don't want to
expose fragment-based buffering metrics. Instead a modern sound system
wants to expose latency values and process time values. Then, the fact
that OSS assumes that the DAC reads directly from the hw playback
buffer makes the whole thing questionable already on USB
hardware. That you even get access to the hardware buffer makes it
very hardware-specific. Using OSS for more than 2ch sensibly is
practically not possible. Modern sound systems want to disable sound
card interrupts as far as possible and schedule audio via system
timers, OSS always wants fragment interrupts. Modern sound systems
want huge buffers and the ability to rewind software pointers. OSS
cannot do this (at most partially if you use mmap() which opens a lot
of additional problems and is shaky ground). No decibel information
for mixers. Then, the way fragments work in OSS you couldn't even
express something like "buffer size 200ms, fillup when only 10ms
left". And this list goes on and on.
In short: how modern software wants to drive a sound card has changed
quite a bit. And OSS3 is from the early 90's. So it's focussed on
hardware, and it is focussed on hw and sw from 20y ago. An SB16 is
quite different from a modern HDA sound card.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
9:23 a.m.
On Tue, Sep 23, 2008 at 04:01:10PM +0200, Lennart Poettering wrote:
> Thats a 'nobody wrote the library' case
No it's not. The people behind OSS (i.e. Hannu) advertise the kernel
API is the audio API to use for normal programs. Because they do this
they moved mixing and sample type conversion into the kernel in OSS4.
Please don't confuse Hannu's later stuff with what the kernel community
accepted.
In short: how modern software wants to drive a sound card has
changed
quite a bit. And OSS3 is from the early 90's. So it's focussed on
hardware, and it is focussed on hw and sw from 20y ago. An SB16 is
quite different from a modern HDA sound card.
Not vastly, its a DMA pipe with a DAC on the end
Alan
9:42 a.m.
On Tue, 23.09.08 10:23, Alan Cox (alan(a)redhat.com) wrote:
> In short: how modern software wants to drive a sound card has
changed
> quite a bit. And OSS3 is from the early 90's. So it's focussed on
> hardware, and it is focussed on hw and sw from 20y ago. An SB16 is
> quite different from a modern HDA sound card.
Not vastly, its a DMA pipe with a DAC on the end
There's not necessarily a DAC at "the end" anymore. Could be SPDIF
too.
And if you say that a modern sound card behaves very similarly to early
90's sound card because it ues DMA, then you could say that sound card
is very similar to a harddisk, too. Which is definitely true in a way.
The really interesting part of audio is not the data transfer, it's
the timing. And that's where hardware changed. And software too. And
OSS is broken and legacy.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
10:02 a.m.
On Tue, Sep 23, 2008 at 04:42:21PM +0200, Lennart Poettering wrote:
> Not vastly, its a DMA pipe with a DAC on the end
There's not necessarily a DAC at "the end" anymore. Could be SPDIF
too.
SPDIF is over 20 years old too. There is a DAC somewhere and will be until
you get a copy protection jack and license slot embedded in your skull...
the timing. And that's where hardware changed. And software too.
And
OSS is broken and legacy.
Not a lot - it started much like todays stuff, got all fancy and complicated
and is now back on the dumb end of the cycle with hardware raytraced sound
presumably going to be the next 'do it in hardware' cycle.
Alan
12:07 p.m.
On Tue, 23.09.08 11:02, Alan Cox (alan(a)redhat.com) wrote:
Not a lot - it started much like todays stuff, got all fancy and
complicated
and is now back on the dumb end of the cycle with hardware raytraced sound
presumably going to be the next 'do it in hardware' cycle.
Still the timing model, which is the most interesting part is broken
and out-of-date in OSS.
Anyway, this discussion is pointless too. Let's end this.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
10:40 a.m.
On Tue, Sep 23, 2008 at 02:37:48PM +0200, Lennart Poettering wrote:
I know. But ALSA hides that in a library, so you never have to deal
with these ugly details. Ain't that great?
Depends on the library. In ALSA's case, it's a particularly badly
designed one, annoyingly enough. As an API, OSS is better.
OG.
12:05 p.m.
On Tue, 23.09.08 17:40, Olivier Galibert (galibert(a)pobox.com) wrote:
> I know. But ALSA hides that in a library, so you never have to
deal
> with these ugly details. Ain't that great?
Depends on the library. In ALSA's case, it's a particularly badly
designed one, annoyingly enough. As an API, OSS is better.
I know both APIs very very well. Probably much better than most
people. I have been using features of both APIs that apparently noone
ever used before me. PA probably uses a larger part of the ALSA API
than any other client. And from that experience I can say that while
ALSA has issues it certainly gets much much more right than OSS ever
did.
But anyway. We have to agree to disagree. This discussion is
pointless. Let's end this here.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
7:38 a.m.
On Tue, 2008-09-23 at 14:21 +0200, Lennart Poettering wrote:
On Tue, 23.09.08 10:54, Dominik 'Rathann' Mierzejewski
(dominik(a)greysector.net) wrote:
Oh my. So you know someone who thinks that ioctl()s are ingenious
API
design?
What do ioctls and files/stream not provide that you are missing?
ioctls essentially are "descriptor"/"tag"/"arbitrary
argument".
An interface can hardly be more generic than this.
7:47 a.m.
On Tue, 23.09.08 14:38, Ralf Corsepius (rc040203(a)freenet.de) wrote:
On Tue, 2008-09-23 at 14:21 +0200, Lennart Poettering wrote:
> On Tue, 23.09.08 10:54, Dominik 'Rathann' Mierzejewski
(dominik(a)greysector.net) wrote:
> Oh my. So you know someone who thinks that ioctl()s are ingenious API
> design?
What do ioctls and files/stream not provide that you are missing?
ioctls essentially are "descriptor"/"tag"/"arbitrary
argument".
An interface can hardly be more generic than this.
Yes, and the fact that it is that generic is the weakness.
You know, we have this wonderful language called C. It's all about
tape-safety and having nice names for things and having proper
signatures for functions and being descriptive. ioctl()s go against
all that. They are not type-safe, have unreadable names, have no
signatures and are everthing but descriptive.
Let's say every single libc call would have been mutlipexed by a
single function call. i.e. instead of calling malloc() like this:
a = malloc(4711);
you'd call:
a = (void*) libc(LC_MLLC, 4711);
Now think of hwo your program would look like in its entirety:
unreadable. Absolutely crazy and unreadable.
Now ioctl() does exactly this: a vast number of function calls are
multiplexed via a single function call. Big fuckup. And everyone who
claims that that would be good API design is just wrong, really,
really wrong. It's not good. It's a fuckup. It's terrible.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
8:02 a.m.
On Tue, 2008-09-23 at 14:47 +0200, Lennart Poettering wrote:
On Tue, 23.09.08 14:38, Ralf Corsepius (rc040203(a)freenet.de) wrote:
>
> On Tue, 2008-09-23 at 14:21 +0200, Lennart Poettering wrote:
> > On Tue, 23.09.08 10:54, Dominik 'Rathann' Mierzejewski
(dominik(a)greysector.net) wrote:
>
> > Oh my. So you know someone who thinks that ioctl()s are ingenious API
> > design?
> What do ioctls and files/stream not provide that you are missing?
>
> ioctls essentially are "descriptor"/"tag"/"arbitrary
argument".
> An interface can hardly be more generic than this.
Yes, and the fact that it is that generic is the weakness.
You know, we have this wonderful language called C. It's all about
tape-safety and having nice names for things and having proper
signatures for functions and being descriptive. ioctl()s go against
all that. They are not type-safe, have unreadable names, have no
signatures and are everthing but descriptive.
Let's say every single libc call would have been mutlipexed by a
single function call. i.e. instead of calling malloc() like this:
a = malloc(4711);
you'd call:
a = (void*) libc(LC_MLLC, 4711);
Now think of hwo your program would look like in its entirety:
unreadable. Absolutely crazy and unreadable.
Now ioctl() does exactly this: a vast number of function calls are
multiplexed via a single function call. Big fuckup. And everyone who
claims that that would be good API design is just wrong, really,
really wrong. It's not good. It's a fuckup. It's terrible.
And I tell you: You are wrong, plain wrong.
ioctl's are a well defined _low level_ interface, providing a clean and
"natural" separation between kernel and userspace.
To make them easily applicable in high-level userspace applications,
they are supposed to be wrapped.
8:07 a.m.
On Tue, 23.09.08 15:02, Ralf Corsepius (rc040203(a)freenet.de) wrote:
> Let's say every single libc call would have been mutlipexed
by a
> single function call. i.e. instead of calling malloc() like this:
>
> a = malloc(4711);
>
> you'd call:
>
> a = (void*) libc(LC_MLLC, 4711);
>
> Now think of hwo your program would look like in its entirety:
> unreadable. Absolutely crazy and unreadable.
>
> Now ioctl() does exactly this: a vast number of function calls are
> multiplexed via a single function call. Big fuckup. And everyone who
> claims that that would be good API design is just wrong, really,
> really wrong. It's not good. It's a fuckup. It's terrible.
And I tell you: You are wrong, plain wrong.
ioctl's are a well defined _low level_ interface, providing a clean and
"natural" separation between kernel and userspace.
To make them easily applicable in high-level userspace applications,
they are supposed to be wrapped.
Yepp! That's exactly what I was saying: OSS as an application
programmers interface is a trainwreck because it directly exposes
ioctls.
ioctl as an API for normal programs == bad!
When ioctls are hidden to normal programs like ALSA does it == acceptable!
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
1:51 p.m.
On Tue, 2008-09-23 at 15:02 +0200, Ralf Corsepius wrote:
ioctl's are a well defined _low level_ interface, providing a
clean and
"natural" separation between kernel and userspace.
http://www.catb.org/esr/writings/taoup/html/ch20s03.html
To make them easily applicable in high-level userspace applications,
they are supposed to be wrapped.
That's just hiding the problem. Unfortunately, that's the best we can do
at the moment.
7:57 a.m.
Lennart Poettering wrote:
On Tue, 23.09.08 10:54, Dominik 'Rathann' Mierzejewski
(dominik(a)greysector.net) wrote:
>>> Do you mean Open Source Software or Open Sound System? In case of OSS,
>>> it's realy a shame, because it was (and still is) a great piece of
software
>>> with nice API and doesn't require any external libraries like ALSA.
>>> But you can't compare console/X to OSS/ALSA. The latter provide
functionality
>> I must correct you: the OSS API sucks. And ALSA is certainly a far
>> greater piece of software than OSS ever was, and among the reasons is
>> precisely the fact that it is a proper library instead of some fucked up kernel
>> interface based on ioctls().
>>
>> Everyone hates ioctl()s. The kernel people do. The userspace people
>> too. An API for application usage that is based around ioctl()s is
>> thus mandatorily a big failure.
> The people whose opinion I value disagree. I have no strong opinion
> of my own, because I never wrote code to interface with either ALSA
> or OSS.
Oh my. So you know someone who thinks that ioctl()s are ingenious API
design? You probably should choose your friends more carefully, then. ;-)
They are nicely minimalistic in that they permit device-specific
operations to be passed to a driver without waiting for some
overly-bulky generalized intermediate API that thinks it knows what
every device/driver might ever need to do. The down side is that it is
very hard to subsequently decouple the application from the device - for
example to let it use a remote device on a machine with different
bit/byte ordering.
--
Les Mikesell
lesmikesell(a)gmail.com
7:24 a.m.
On Tue, 23.09.08 08:09, Alan Cox (alan(a)redhat.com) wrote:
On Tue, Sep 23, 2008 at 01:39:24AM +0200, Lennart Poettering wrote:
> Everyone hates ioctl()s. The kernel people do. The userspace people
Not true. Ioctl has a very important place in things.
Sure they have. But its an awkward interface. Everything multiplexed
via a single syscall. Unreadable/unpronouncable names. No type-safety,
not even size-safety. No proper signatures. ioctl()s are awful.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
9:42 a.m.
Le Lun 15 septembre 2008 16:38, Andrew Parker a écrit :
On Mon, Sep 15, 2008 at 8:26 AM, Nicolas Mailhot
<nicolas.mailhot(a)laposte.net> wrote:
>>
>> I don't know of any bugs that prevent me or my colleagues from
>> using
>> the text mode console.
>
> Lucky you.
>
So because it doesn't work for you its not allowed to work for me?
Just because it works for you does not mean it's healthy in general.
--
Nicolas Mailhot
9:50 a.m.
On Monday, 15 September 2008 at 16:42, Nicolas Mailhot wrote:
Le Lun 15 septembre 2008 16:38, Andrew Parker a écrit :
>
> On Mon, Sep 15, 2008 at 8:26 AM, Nicolas Mailhot
> <nicolas.mailhot(a)laposte.net> wrote:
>>>
>>> I don't know of any bugs that prevent me or my colleagues from
>>> using
>>> the text mode console.
>>
>> Lucky you.
>>
>
> So because it doesn't work for you its not allowed to work for me?
Just because it works for you does not mean it's healthy in general.
Just because it doesn't work for you does not mean it must be removed.
Regards,
R.
--
Fedora http://fedoraproject.org/wiki/User:Rathann
Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
9:55 a.m.
Le Lun 15 septembre 2008 16:50, Dominik 'Rathann' Mierzejewski a écrit :
On Monday, 15 September 2008 at 16:42, Nicolas Mailhot wrote:
>
>
> Le Lun 15 septembre 2008 16:38, Andrew Parker a écrit :
> >
> > On Mon, Sep 15, 2008 at 8:26 AM, Nicolas Mailhot
> > <nicolas.mailhot(a)laposte.net> wrote:
> >>>
> >>> I don't know of any bugs that prevent me or my colleagues from
> >>> using
> >>> the text mode console.
> >>
> >> Lucky you.
> >>
> >
> > So because it doesn't work for you its not allowed to work for me?
>
> Just because it works for you does not mean it's healthy in general.
Just because it doesn't work for you does not mean it must be removed.
Since it's rotting it does not matter if it's explicitely removed or
not. The functionality is effectively going away through lack of
maintenance.
--
Nicolas Mailhot
10:07 a.m.
On Monday, 15 September 2008 at 16:55, Nicolas Mailhot wrote:
Le Lun 15 septembre 2008 16:50, Dominik 'Rathann' Mierzejewski a écrit :
>
> On Monday, 15 September 2008 at 16:42, Nicolas Mailhot wrote:
>>
>>
>> Le Lun 15 septembre 2008 16:38, Andrew Parker a écrit :
>> >
>> > On Mon, Sep 15, 2008 at 8:26 AM, Nicolas Mailhot
>> > <nicolas.mailhot(a)laposte.net> wrote:
>> >>>
>> >>> I don't know of any bugs that prevent me or my colleagues from
>> >>> using
>> >>> the text mode console.
>> >>
>> >> Lucky you.
>> >>
>> >
>> > So because it doesn't work for you its not allowed to work for me?
>>
>> Just because it works for you does not mean it's healthy in general.
>
> Just because it doesn't work for you does not mean it must be removed.
Since it's rotting it does not matter if it's explicitely removed or
not. The functionality is effectively going away through lack of
maintenance.
It does matter, since the removal affects me (and some other people, apparently),
while just keeping it means it will continue to work as it does now.
Regards,
R.
--
Fedora http://fedoraproject.org/wiki/User:Rathann
Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
10:30 a.m.
On Mon, 2008-09-15 at 16:55 +0200, Nicolas Mailhot wrote:
Le Lun 15 septembre 2008 16:50, Dominik 'Rathann' Mierzejewski a écrit :
>
> On Monday, 15 September 2008 at 16:42, Nicolas Mailhot wrote:
> Just because it doesn't work for you does not mean it must
be removed.
Since it's rotting it does not matter if it's explicitely removed or
not. The functionality is effectively going away through lack of
maintenance.
1. What is rotting, what is broken?
2. Who are you to decide that?
11:13 a.m.
On Mon, Sep 15, 2008 at 11:30 AM, Ralf Corsepius <rc040203(a)freenet.de> wrote:
On Mon, 2008-09-15 at 16:55 +0200, Nicolas Mailhot wrote:
>
> Le Lun 15 septembre 2008 16:50, Dominik 'Rathann' Mierzejewski a écrit :
> >
> > On Monday, 15 September 2008 at 16:42, Nicolas Mailhot wrote:
> > Just because it doesn't work for you does not mean it must be removed.
>
> Since it's rotting it does not matter if it's explicitely removed or
> not. The functionality is effectively going away through lack of
> maintenance.
1. What is rotting, what is broken?
The reason this thread began was that sound/pulseaudio doesn't work on
a console. That is -> resolved NOTABUG.
1:38 p.m.
Colin Walters wrote:
On Mon, Sep 15, 2008 at 11:30 AM, Ralf Corsepius
<rc040203(a)freenet.de> wrote:
> On Mon, 2008-09-15 at 16:55 +0200, Nicolas Mailhot wrote:
>> Le Lun 15 septembre 2008 16:50, Dominik 'Rathann' Mierzejewski a écrit :
>>> On Monday, 15 September 2008 at 16:42, Nicolas Mailhot wrote:
>>> Just because it doesn't work for you does not mean it must be removed.
>> Since it's rotting it does not matter if it's explicitely removed or
>> not. The functionality is effectively going away through lack of
>> maintenance.
> 1. What is rotting, what is broken?
The reason this thread began was that sound/pulseaudio doesn't work on
a console. That is -> resolved NOTABUG.
So what is the solution where you want to use audio on a headless box?
Or your X session (if you have one) is remote but the audio output
connected to the speakers for the room is local? Or you want music to
keep playing when the local X user changes? (Macs get this wrong too,
but at least they have the excuse that they are trying to sell you a
separate device that you can dedicate to audio if you actually want to
listen to an uninterrupted song).
--
Les Mikesell
lesmikesell(a)gmail.com
10:32 a.m.
On Mon, 2008-09-15 at 16:42 +0200, Nicolas Mailhot wrote:
> So because it doesn't work for you its not allowed to work
for me?
Just because it works for you does not mean it's healthy in general.
'healthy in general'? I'd love to see how we determine that criteria.
So, yah - let's not play this game, shall we?
Here is my question:
- does the presence of the text console limit the ability for the X
interfaces to work? I think the answer is no.
- does the presence of the text console make a considerable impact on
the available development time of the poeple working on X? I'd have to
see some numbers that say otherwise but the answer still feels like no.
let's not go overboard
-sv
10:48 a.m.
Le Lun 15 septembre 2008 17:32, Seth Vidal a écrit :
On Mon, 2008-09-15 at 16:42 +0200, Nicolas Mailhot wrote:
> > So because it doesn't work for you its not allowed to work for me?
>
> Just because it works for you does not mean it's healthy in general.
>
'healthy in general'? I'd love to see how we determine that criteria.
So, yah - let's not play this game, shall we?
Here is my question:
- does the presence of the text console limit the ability for the X
interfaces to work? I think the answer is no.
- does the presence of the text console make a considerable impact on
the available development time of the poeple working on X? I'd have to
see some numbers that say otherwise but the answer still feels like
no.
We have all sorts of packaging rules designed to avoid hitting console
limitations and problems.
Every few months we have people filling bugs because the presence of
two text stacks confuses them and they don't understand why things
working in one do not work in the other (and that's the people who do
fill bugs. they tend to be from asian countries where people
under-report problems).
We have spin teams that do not install the default distro font set to
make room for stuff like the console, and then ask for help because it
broke X text on some locale.
So console support is not free for the rest of the distro. And I'd be
happy to applaud this cost, if someone actively maintained the console
(instead of playing the "touch nothing, if something broke that's the
distro fault" game).
let's not go overboard
--
Nicolas Mailhot
11:41 a.m.
On Monday, 15 September 2008 at 17:48, Nicolas Mailhot wrote:
Le Lun 15 septembre 2008 17:32, Seth Vidal a écrit :
>
> On Mon, 2008-09-15 at 16:42 +0200, Nicolas Mailhot wrote:
>> > So because it doesn't work for you its not allowed to work for me?
>>
>> Just because it works for you does not mean it's healthy in general.
>>
>
> 'healthy in general'? I'd love to see how we determine that criteria.
>
> So, yah - let's not play this game, shall we?
>
> Here is my question:
> - does the presence of the text console limit the ability for the X
> interfaces to work? I think the answer is no.
> - does the presence of the text console make a considerable impact on
> the available development time of the poeple working on X? I'd have to
> see some numbers that say otherwise but the answer still feels like
> no.
We have all sorts of packaging rules designed to avoid hitting console
limitations and problems.
Every few months we have people filling bugs because the presence of
two text stacks confuses them and they don't understand why things
working in one do not work in the other (and that's the people who do
fill bugs. they tend to be from asian countries where people
under-report problems).
Bugzilla links, please.
We have spin teams that do not install the default distro font set
to
make room for stuff like the console, and then ask for help because it
broke X text on some locale.
Bugzilla/mailing list links, please.
So console support is not free for the rest of the distro. And
I'd be
happy to applaud this cost, if someone actively maintained the console
(instead of playing the "touch nothing, if something broke that's the
distro fault" game).
These ARE good arguments. Why didn't you use them in the first place
instead of hand-waving?
Regards,
R.
--
Fedora http://fedoraproject.org/wiki/User:Rathann
Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
12:32 p.m.
Le lundi 15 septembre 2008 Ã 18:41 +0200, Dominik 'Rathann' Mierzejewski
a écrit :
On Monday, 15 September 2008 at 17:48, Nicolas Mailhot wrote:
>
>
> Le Lun 15 septembre 2008 17:32, Seth Vidal a écrit :
> >
> > On Mon, 2008-09-15 at 16:42 +0200, Nicolas Mailhot wrote:
> >> > So because it doesn't work for you its not allowed to work for
me?
> >>
> >> Just because it works for you does not mean it's healthy in general.
> >>
> >
> > 'healthy in general'? I'd love to see how we determine that
criteria.
> >
> > So, yah - let's not play this game, shall we?
> >
> > Here is my question:
> > - does the presence of the text console limit the ability for the X
> > interfaces to work? I think the answer is no.
> > - does the presence of the text console make a considerable impact on
> > the available development time of the poeple working on X? I'd have to
> > see some numbers that say otherwise but the answer still feels like
> > no.
>
> We have all sorts of packaging rules designed to avoid hitting console
> limitations and problems.
>
> Every few months we have people filling bugs because the presence of
> two text stacks confuses them and they don't understand why things
> working in one do not work in the other (and that's the people who do
> fill bugs. they tend to be from asian countries where people
> under-report problems).
Bugzilla links, please.
Unfortunately, the last one I remember was so generally worded I can't
find a significant keyword to nail it in google
> We have spin teams that do not install the default distro font
set to
> make room for stuff like the console, and then ask for help because it
> broke X text on some locale.
Bugzilla/mailing list links, please.
https://fedorahosted.org/spin-kickstarts/browser/fedora-live-xfce.ks?rev=...
http://www.deadbabylon.de/blog/2007/11/08/create-your-own-localized-versi...
https://bugzilla.redhat.com/show_bug.cgi?id=445291
The first reflex of a spin author is always to drop fonts to "save
space" and keeping two different font sets does not help choosing the
right ones to drop. Spin space is contended.
> So console support is not free for the rest of the distro. And
I'd be
> happy to applaud this cost, if someone actively maintained the console
> (instead of playing the "touch nothing, if something broke that's the
> distro fault" game).
These ARE good arguments. Why didn't you use them in the first place
instead of hand-waving?
I've stated several times I was a layout maintainer in kbd and xkb.
(This is easy to check either in google or greping those component
credits.) Anyone that follows this list knows I contribute to the fonts
SIG. I'd say this is qualification enough to have an opinion on the
console state.
And if you do not know what that means, please do not talk about
handwaving.
--
Nicolas Mailhot
7:37 a.m.
Nicolas Mailhot wrote:
Simply put, non-X-console input is a mess (X input is a mess too but
at least there are people trying to fix it), non-X-console font
support has fossilized, and support for modern high resolution screens
is severely lacking.
Will you still be able to run a headless machine with its console
redirected to a serial port?
And that's ok. Do remember that X was defined at a time hardware
was
vastly less powerful and core X is not wasteful at all. Compared to
how the rest of the system has bloated, X is definitely lean and mean.
But there's no reason to assume that the X display(s) is/are directly
connected to the CPU in question. What do you do when they aren't?
--
Les Mikesell
lesmikesell(a)gmail.com
7:49 a.m.
Le Lun 15 septembre 2008 14:37, Les Mikesell a écrit :
Nicolas Mailhot wrote:
>
> Simply put, non-X-console input is a mess (X input is a mess too but
> at least there are people trying to fix it), non-X-console font
> support has fossilized, and support for modern high resolution
> screens
> is severely lacking.
Will you still be able to run a headless machine with its console
redirected to a serial port?
Why not ?
> And that's ok. Do remember that X was defined at a time
hardware was
> vastly less powerful and core X is not wasteful at all. Compared to
> how the rest of the system has bloated, X is definitely lean and
> mean.
But there's no reason to assume that the X display(s) is/are directly
connected to the CPU in question. What do you do when they aren't?
Do not parse
--
Nicolas Mailhot
8:03 a.m.
Nicolas Mailhot wrote:
>> Simply put, non-X-console input is a mess (X input is a mess too but
>> at least there are people trying to fix it), non-X-console font
>> support has fossilized, and support for modern high resolution
>> screens
>> is severely lacking.
> Will you still be able to run a headless machine with its console
> redirected to a serial port?
Why not ?
I think I'm confused by the term 'non X consoles'. Is that something
different than the native text mode you see before X starts?
>> And that's ok. Do remember that X was defined at a time
hardware was
>> vastly less powerful and core X is not wasteful at all. Compared to
>> how the rest of the system has bloated, X is definitely lean and
>> mean.
> But there's no reason to assume that the X display(s) is/are directly
> connected to the CPU in question. What do you do when they aren't?
Do not parse
I rarely use the console of the machine running my programs. I'll
either ssh for text mode or use a remote X or freenx/NX to connect from
elsewhere, and in the case of NX, often floating the session around
among several different displays keeping running programs intact. That
leaves the question of how to manage the host without needing X locally,
and back to the topic of pulseaudio, how to use the host's audio system
when the X sessions are displayed elsewhere.
And by the way, I highly recommend the freenx/NX combo if you ever move
from your desk.
--
Les Mikesell
lesmikesell(a)gmail.com
8:24 a.m.
Le Lun 15 septembre 2008 15:03, Les Mikesell a écrit :
Nicolas Mailhot wrote:
>
>>> Simply put, non-X-console input is a mess (X input is a mess too
>>> but
>>> at least there are people trying to fix it), non-X-console font
>>> support has fossilized, and support for modern high resolution
>>> screens
>>> is severely lacking.
>> Will you still be able to run a headless machine with its console
>> redirected to a serial port?
>
> Why not ?
I think I'm confused by the term 'non X consoles'. Is that something
different than the native text mode you see before X starts?
I think you have two different things. A VT to which you can attach an
X session, a serial port, a remote SSH, mingetty... and the software
stack used to display locally the VT text and collect user input.
I've no problem with the low-level VT bit. The current console
software stack OTOH has rotten and seriously needs replacement.
--
Nicolas Mailhot
1:57 p.m.
Nicolas Mailhot wrote:
>>>> Simply put, non-X-console input is a mess (X input is a mess too
>>>> but
>>>> at least there are people trying to fix it), non-X-console font
>>>> support has fossilized, and support for modern high resolution
>>>> screens
>>>> is severely lacking.
>>> Will you still be able to run a headless machine with its console
>>> redirected to a serial port?
>> Why not ?
> I think I'm confused by the term 'non X consoles'. Is that something
> different than the native text mode you see before X starts?
I think you have two different things. A VT to which you can attach an
X session, a serial port, a remote SSH, mingetty... and the software
stack used to display locally the VT text and collect user input.
I've no problem with the low-level VT bit. The current console
software stack OTOH has rotten and seriously needs replacement.
OK, the low level part that works in character mode and expects some
hardware to supply and render the fonts is absolutely necessary -
software other than X that renders custom fonts, not so much. Can you
make the distinction a little more clear when you are talking about
removing parts?
--
Les Mikesell
lesmikesell(a)gmail.com
8:39 a.m.
Nicolas Mailhot wrote:
Simply put, non-X-console input is a mess (X input is a mess too but
at least there are people trying to fix it), non-X-console font
support has fossilized, and support for modern high resolution screens
is severely lacking.
The console has not evolved for a long time, while text requirements
have gone up. At this point a dumbed down text-only X session is
probably the only credible console future (or something that is not X
at all but uses many libraries we associate with apps now).
Non-X-console state is so bad nowadays I don't bother reporting bugs
on it. Even if they are fixed they always reappear the next Fedora
cycle.
Well, people can log in, and people can run commands. As long as that
works, where's the problem ? I understand support for foreign characters
is going to be a problem, but how does that justify removing the entire
thing ?
There is simply not enough console users [cut] to do anything but
life support anymore.
On what facts do you base that opinion ?
I occasionally run into a Gnome app bug where drag'n'drop "hangs" the
desktop (the "drag" never "drops", sort of) where the only way out is
ctrl-alt-f1 to mingetty and killall the user-space app. Without
mingetty, ctrl-alt-del is the only other option (i.e. loose all unsaved
documents).
8:43 a.m.
On Mon, Sep 15, 2008 at 9:39 AM, Denis Leroy <denis(a)poolshark.org> wrote:
I occasionally run into a Gnome app bug where drag'n'drop "hangs" the
desktop (the "drag" never "drops", sort of) where the only way out
is
ctrl-alt-f1 to mingetty and killall the user-space app. Without mingetty,
ctrl-alt-del is the only other option (i.e. loose all unsaved documents).
We should make Ctrl-Alt-Backspace just break server grabs instead of
killing the server (and of course fix the bugs in the apps that hang
while holding a server grab).
8:48 a.m.
Colin Walters (walters(a)verbum.org) said:
> I occasionally run into a Gnome app bug where
drag'n'drop "hangs" the
> desktop (the "drag" never "drops", sort of) where the only way
out is
> ctrl-alt-f1 to mingetty and killall the user-space app. Without mingetty,
> ctrl-alt-del is the only other option (i.e. loose all unsaved documents).
We should make Ctrl-Alt-Backspace just break server grabs instead of
killing the server (and of course fix the bugs in the apps that hang
while holding a server grab).
Wait, that redefines the standard logout keyboard shortcut!
Bill
9:33 a.m.
On Mon, Sep 15, 2008 at 9:43 AM, Colin Walters <walters(a)verbum.org> wrote:
On Mon, Sep 15, 2008 at 9:39 AM, Denis Leroy
<denis(a)poolshark.org> wrote:
>
> I occasionally run into a Gnome app bug where drag'n'drop "hangs"
the
> desktop (the "drag" never "drops", sort of) where the only way
out is
> ctrl-alt-f1 to mingetty and killall the user-space app. Without mingetty,
> ctrl-alt-del is the only other option (i.e. loose all unsaved documents).
We should make Ctrl-Alt-Backspace just break server grabs instead of
killing the server (and of course fix the bugs in the apps that hang
while holding a server grab).
ok, so remove all the consoles when all the bugs have been fixed and
no new bugs are going to be written.
1:28 p.m.
Colin Walters wrote:
On Mon, Sep 15, 2008 at 9:39 AM, Denis Leroy
<denis(a)poolshark.org> wrote:
> I occasionally run into a Gnome app bug where drag'n'drop "hangs"
the
> desktop (the "drag" never "drops", sort of) where the only way
out is
> ctrl-alt-f1 to mingetty and killall the user-space app. Without mingetty,
> ctrl-alt-del is the only other option (i.e. loose all unsaved documents).
We should make Ctrl-Alt-Backspace just break server grabs instead of
killing the server (and of course fix the bugs in the apps that hang
while holding a server grab).
I hear the magic key to kill server grabs is going away in new X (maybe
already has)... which is a pity, because something on my desktop
occasionally grabs the mouse and won't let go.
So... I'm in favor of a 'break grabs' key enabled by default :-).
--
Matthew
"NT was a marketing name that stood for New Technology, but it was still
an amusing coincidence that WNT was VMS with each letter replaced by the
next one."
-- Jeremy Reimer
9:09 a.m.
On Mon, 2008-09-15 at 15:39 +0200, Denis Leroy wrote:
Nicolas Mailhot wrote:
> There is simply not enough console users [cut] to do anything
but
> life support anymore.
On what facts do you base that opinion ?
Probably, because most console users already quit using Fedora,
because already has been turned into a single user desktop OS?
This is at least what I will certainly do should this plan become true.
/me ducks and hides
9:41 a.m.
Ralf Corsepius wrote:
On Mon, 2008-09-15 at 15:39 +0200, Denis Leroy wrote:
> Nicolas Mailhot wrote:
>
> > There is simply not enough console users [cut] to do anything but
> > life support anymore.
>
> On what facts do you base that opinion ?
>
Probably, because most console users already quit using Fedora,
+1.
And situation is worse than simply loss of a rare segment of the market.
Who are "console users"? Most cases they are users who began for a long
time ago (when GUI was either poor or unavailable). Lacking such "long
time ago" users, we lack all their skills, knowledge, intuition. And as
begun for a long time, many of them have already made their career, and
even make decisions now. Decisions not for Fedora.
Anyway, while Fedora is (still) considered as "general purpose disto",
it should has console.
~buc
http://www.fedoraproject.org/wiki/DmitryButskoy
9:59 a.m.
On Mon, 2008-09-15 at 18:41 +0400, Dmitry Butskoy wrote:
Ralf Corsepius wrote:
> On Mon, 2008-09-15 at 15:39 +0200, Denis Leroy wrote:
>
>> Nicolas Mailhot wrote:
>>
>
>
>> > There is simply not enough console users [cut] to do anything but
>> > life support anymore.
>>
>> On what facts do you base that opinion ?
>>
>
> Probably, because most console users already quit using Fedora,
>
+1.
And situation is worse than simply loss of a rare segment of the market.
Who are "console users"? Most cases they are users who began for a long
time ago (when GUI was either poor or unavailable).
Yep, this is likely one group
(BTW: There are still situations, where
Fedora's GUI is either poor or unavailable). It's likely the same group
which is booting into "runlevel 3".
Other groups/use-cases, I see:
- Situations of emergency (Broken X-server, memory hogging-desktop
desktop apps etc.)
- Debugging.
- Machines without GUI installed.
Probably the latter is hard to imagine to the folks who came up this
proposal. Yes, folks, there are machines which are being used without a
GUI!
Anyway, while Fedora is (still) considered as "general purpose
disto",
it should has console.
I regret having to state this, but I have been thinking
Fedora has quit
being a "general purpose distro" for quite a while.
Ralf
1:45 p.m.
Ralf Corsepius wrote:
Other groups/use-cases, I see:
- Situations of emergency (Broken X-server, memory hogging-desktop
desktop apps etc.)
- Debugging.
- Machines without GUI installed.
Probably the latter is hard to imagine to the folks who came up this
proposal. Yes, folks, there are machines which are being used without a
GUI!
Servers need a GUI like a fish needs a bicycle (I forget who said that,
but it's still just as true).
> Anyway, while Fedora is (still) considered as "general
purpose disto",
> it should has console.
I regret having to state this, but I have been thinking Fedora has quit
being a "general purpose distro" for quite a while.
Which will make things 'interesting' if RHEL continues to try to use
fedora as a starting point.
--
Les Mikesell
lesmikesell(a)gmail.com
1:34 p.m.
New subject: Tried Pulse Audio Again--No Good For A11y
I just decided to give pa another go--so that I could speak from recent
experience. I went to my /etc/alsa/alsa.conf and uncommented line 11.
Then, I rebooted.
1.) There continues to be no audio indication of when gdm is ready.
This despite the fact that I have "SoundOnLogin=true" in my
/etc/gdm/custom.conf. The builtin GDM "audio icon" doesn't play, neither
does GDM beep when it launches, nor can I get a beep from pressing
back-space.
2.) Ctrl-S does not work in GDM. This is gdm-2.22.0-8.fc9. Should I
try from rawhide?
3.) Logging in I hear first the GDM "audio logo," think I'll call it
an earcon from now on. But, Orca launches in my secondary audio device.
That's inappropriate, but I have no way to control that except to unplug
my secondary and tertiary audio devices and start over.
4.) Logging back in with only one audio device on board, Orca does
indeed startup on that device--but it seems I have to choose between
Orca and playing other audio. How quaint! I thought we got past this
silly "one sound at a time" view back around alsa-0.9. Does anyone
recall the alsa FAQ used to claim this was appropriate back then?
Well, it still isn't appropriate, but that's what's happening. If I
paplay some .wav from a Gnome-Terminal, then attempt to go somewhere off
my Alt-F1 (Applications) menu--there's no Orca until my .wav ends. I
guess it would be like the screen blanking while the cd audio disc
plays? Very curious, indeed.
5.) While I paplay, I try to go Ctrl-Alt-F1. While I'm not prevented
from doing so, paplay believes it should pause playing while I'm away
from the gui tty. Now, who's the genius that figured out this "feature?"
Needless to say, line 11 is again pounded off.
Janina
1.
--
Janina Sajka, Phone: +1.202.595.7777; sip:janina@a11y.org
Partner, Capital Accessibility LLC http://CapitalAccessibility.Com
Marketing the Owasys 22C talking screenless cell phone in the U.S. and Canada
Learn more at http://ScreenlessPhone.Com
Chair, Open Accessibility janina(a)a11y.org
Linux Foundation http://a11y.org
2:12 p.m.
New subject: Tried Pulse Audio Again--No Good For A11y
On Tue, 2008-09-16 at 14:34 -0400, Janina Sajka wrote:
I just decided to give pa another go--so that I could speak from
recent
experience. I went to my /etc/alsa/alsa.conf and uncommented line 11.
Then, I rebooted.
1.) There continues to be no audio indication of when gdm is ready.
This despite the fact that I have "SoundOnLogin=true" in my
/etc/gdm/custom.conf. The builtin GDM "audio icon" doesn't play, neither
does GDM beep when it launches, nor can I get a beep from pressing
back-space.
What is the 'builtin audio icon' ? I have no idea what you are talking
about here. And I've explained months ago how you can get a sound when
the login screen appears - assuming you are willing to make simple
customizations, which seems to be the case, considering that you are
editing alsa.conf...
Why do you expect to get a beep from pressing backspace ? You can get
beeps in all sorts of ways: pressing up arrow, pressing enter, followed
by backspace, etc...
2.) Ctrl-S does not work in GDM. This is gdm-2.22.0-8.fc9. Should I
try from rawhide?
Yeah, I know we wanted to add such global hotkeys to
gnome-settings-daemon, but it hasn't happened, as far as I can see. I'll
try to find out where that stands. But this is not very related to
pulseaudio anyway...
3.) Logging in I hear first the GDM "audio logo," think
I'll call it
an earcon from now on. But, Orca launches in my secondary audio device.
That's inappropriate, but I have no way to control that except to unplug
my secondary and tertiary audio devices and start over.
Hardly pulseaudios fault if orca picks the wrong device. I have no idea
how orca decides which device to use.
4.) Logging back in with only one audio device on board, Orca does
indeed startup on that device--but it seems I have to choose between
Orca and playing other audio. How quaint! I thought we got past this
silly "one sound at a time" view back around alsa-0.9. Does anyone
recall the alsa FAQ used to claim this was appropriate back then?
I don't recall old alsa FAQs, but you can observe that all the rest of
the desktop happily shares the output device under pulseaudios control.
You'd think it should be possible for orca to do the same. That it is
not doing so is again not pulseaudios fault...
5.) While I paplay, I try to go Ctrl-Alt-F1. While I'm not
prevented
from doing so, paplay believes it should pause playing while I'm away
from the gui tty. Now, who's the genius that figured out this "feature?"
Insults won't help your cause.
4:28 p.m.
New subject: Tried Pulse Audio Again--No Good For A11y
Matthias Clasen writes:
On Tue, 2008-09-16 at 14:34 -0400, Janina Sajka wrote:
> I just decided to give pa another go--so that I could speak from recent
> experience. I went to my /etc/alsa/alsa.conf and uncommented line 11.
> Then, I rebooted.
>
> 1.) There continues to be no audio indication of when gdm is ready.
> This despite the fact that I have "SoundOnLogin=true" in my
> /etc/gdm/custom.conf. The builtin GDM "audio icon" doesn't play,
neither
> does GDM beep when it launches, nor can I get a beep from pressing
> back-space.
What is the 'builtin audio icon' ? I have no idea what you are talking
The sound the GDM plays when you've enabled audio. It plays after login,
which is nice. But that doesn't meet the user need to know when GDM is
ready for use.
I suspect no one thought to give this feature a name. If they did, I
haven't heard it. Typically a Marketing Dept would call such a thing a
"audio logo." Think of the sound that accompanies Intel's "Intel
Inside"
commercials.
about here. And I've explained months ago how you can get a sound
when
the login screen appears - assuming you are willing to make simple
customizations, which seems to be the case, considering that you are
editing alsa.conf...
Sorry, I don't recall that--nor can I find it in my mailboxes or via
Google. I do see an extended conversation on gdm-list that included both
of us. Looking at that mail I see that I reported this sound would play
after a Ctrl+Alt+Backspace--but not on boot. That continues to be the
case.
Why do you expect to get a beep from pressing backspace ? You can get
beeps in all sorts of ways: pressing up arrow, pressing enter, followed
by backspace, etc...
I don't necessarily. Again, the user need is to know when GDM is ready
for login. A beep on backspace is one way to achieve that. It was the
old behavior when "SoundOnLogin=TRUE"
> 2.) Ctrl-S does not work in GDM. This is gdm-2.22.0-8.fc9.
Should I
> try from rawhide?
Yeah, I know we wanted to add such global hotkeys to
gnome-settings-daemon, but it hasn't happened, as far as I can see. I'll
try to find out where that stands. But this is not very related to
pulseaudio anyway...
OK. Thank you. Ctrl+s to start Orca with speech, Ctrl+b to start it with
braille, and ctrl+m to start it with magnification are certainly
noncontroversial. We discussed additional, mouse-oriented a11y for users
of Gok on gdm-list. I don't believe we came to conclusions.
> 3.) Logging in I hear first the GDM "audio logo," think I'll call it
> an earcon from now on. But, Orca launches in my secondary audio device.
> That's inappropriate, but I have no way to control that except to unplug
> my secondary and tertiary audio devices and start over.
Hardly pulseaudios fault if orca picks the wrong device. I have no idea
how orca decides which device to use.
Orca makes no decisions about audio devices. Neither does gnome-speech.
So, it's rather an uncontrolled hand-wave.
> 4.) Logging back in with only one audio device on board, Orca
does
> indeed startup on that device--but it seems I have to choose between
> Orca and playing other audio. How quaint! I thought we got past this
> silly "one sound at a time" view back around alsa-0.9. Does anyone
> recall the alsa FAQ used to claim this was appropriate back then?
I don't recall old alsa FAQs, but you can observe that all the rest of
the desktop happily shares the output device under pulseaudios control.
You'd think it should be possible for orca to do the same. That it is
not doing so is again not pulseaudios fault...
Perhaps not, but commenting and uncomment line 11 in
/etc/alsa/alsa.conf--the line that invokes (or blocks) pulse audio
toggles this between broken and correct functionality. What else am I to
conclude about pulse audio?
> 5.) While I paplay, I try to go Ctrl-Alt-F1. While I'm not prevented
> from doing so, paplay believes it should pause playing while I'm away
> from the gui tty. Now, who's the genius that figured out this
"feature?"
Insults won't help your cause.
Well, my apologies if this offends you. Is it
supposed to work that way,
though? Is there actually a use case for that behavior? Or is this just
some incidental artifact?
Janina
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
--
Janina Sajka, Phone: +1.202.595.7777; sip:janina@a11y.org
Partner, Capital Accessibility LLC http://CapitalAccessibility.Com
Marketing the Owasys 22C talking screenless cell phone in the U.S. and Canada
Learn more at http://ScreenlessPhone.Com
Chair, Open Accessibility janina(a)a11y.org
Linux Foundation http://a11y.org
2:31 a.m.
New subject: Tried Pulse Audio Again--No Good For A11y
Le mardi 16 septembre 2008 à 17:28 -0400, Janina Sajka a écrit :
Matthias Clasen writes:
> On Tue, 2008-09-16 at 14:34 -0400, Janina Sajka wrote:
> > 5.) While I paplay, I try to go Ctrl-Alt-F1. While I'm
not prevented
> > from doing so, paplay believes it should pause playing while I'm away
> > from the gui tty. Now, who's the genius that figured out this
"feature?"
>
> Insults won't help your cause.
Well, my apologies if this offends you. Is it supposed to work that way,
though? Is there actually a use case for that behavior? Or is this just
some incidental artifact?
This is part of PA's design yes. And many people have already complained
it was hostile to their computer usage.
--
Nicolas Mailhot
5:41 a.m.
New subject: Tried Pulse Audio Again--No Good For A11y
On Wed, 2008-09-17 at 09:31 +0200, Nicolas Mailhot wrote:
Le mardi 16 septembre 2008 à 17:28 -0400, Janina Sajka a écrit :
> Matthias Clasen writes:
> > On Tue, 2008-09-16 at 14:34 -0400, Janina Sajka wrote:
> > > 5.) While I paplay, I try to go Ctrl-Alt-F1. While I'm not prevented
> > > from doing so, paplay believes it should pause playing while I'm away
> > > from the gui tty. Now, who's the genius that figured out this
"feature?"
> >
> > Insults won't help your cause.
> Well, my apologies if this offends you. Is it supposed to work that way,
> though? Is there actually a use case for that behavior? Or is this just
> some incidental artifact?
This is part of PA's design yes. And many people have already complained
it was hostile to their computer usage.
"Hostile" is a bit of a hard word here, don't you think? Maybe PA should
offer an option whether to mute/unmute when switching to different VCs
or not as there are valid use cases for both behaviors.
Nils
--
Nils Philippsen "Those who would give up Essential Liberty to purchase
Red Hat a little Temporary Safety, deserve neither Liberty
nils(a)redhat.com nor Safety." -- Benjamin Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
9:22 a.m.
New subject: Tried Pulse Audio Again--No Good For A11y
Le mercredi 17 septembre 2008 à 12:41 +0200, Nils Philippsen a écrit :
On Wed, 2008-09-17 at 09:31 +0200, Nicolas Mailhot wrote:
> Le mardi 16 septembre 2008 à 17:28 -0400, Janina Sajka a écrit :
> > Matthias Clasen writes:
> > > On Tue, 2008-09-16 at 14:34 -0400, Janina Sajka wrote:
>
> > > > 5.) While I paplay, I try to go Ctrl-Alt-F1. While I'm not
prevented
> > > > from doing so, paplay believes it should pause playing while I'm
away
> > > > from the gui tty. Now, who's the genius that figured out this
"feature?"
> > >
> > > Insults won't help your cause.
> > Well, my apologies if this offends you. Is it supposed to work that way,
> > though? Is there actually a use case for that behavior? Or is this just
> > some incidental artifact?
>
> This is part of PA's design yes. And many people have already complained
> it was hostile to their computer usage.
"Hostile" is a bit of a hard word here, don't you think?
I don't think anyone can accuse PA of softness or any other form of
moderation in this regard.
--
Nicolas Mailhot
5:39 a.m.
New subject: Tried Pulse Audio Again--No Good For A11y
On Tue, 2008-09-16 at 17:28 -0400, Janina Sajka wrote:
Matthias Clasen writes:
> On Tue, 2008-09-16 at 14:34 -0400, Janina Sajka wrote:
[...]
>
> > 5.) While I paplay, I try to go Ctrl-Alt-F1. While I'm not prevented
> > from doing so, paplay believes it should pause playing while I'm away
> > from the gui tty. Now, who's the genius that figured out this
"feature?"
>
> Insults won't help your cause.
Well, my apologies if this offends you. Is it supposed to work that way,
though? Is there actually a use case for that behavior? Or is this just
some incidental artifact?
There is a use case for this, namely if you have several "seats" with
different logged in users: in this case one probably only wants the
sounds of the "active session" being played and others muted. Just in
case you ask, we're using that setup at home, my wife and I are logged
in all the time an switch between users via the applet or
<Ctrl><Alt>F7/F9.
Nils
--
Nils Philippsen "Those who would give up Essential Liberty to purchase
Red Hat a little Temporary Safety, deserve neither Liberty
nils(a)redhat.com nor Safety." -- Benjamin Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
8:45 a.m.
New subject: Tried Pulse Audio Again--No Good For A11y
On Wed, 2008-09-17 at 12:39 +0200, Nils Philippsen wrote:
There is a use case for this, namely if you have several
"seats" with
different logged in users: in this case one probably only wants the
sounds of the "active session" being played and others muted. Just in
case you ask, we're using that setup at home, my wife and I are logged
in all the time an switch between users via the applet or
<Ctrl><Alt>F7/F9.
This is a good example of a common problem with free software: we focus
on the fringe cases at the detriment of the common ones (many time the
ratio can be less then 10/90).
Folks that do use multi-seat setups are already more advanced, so those
guys should flip a switch (maybe not even a PA but rather a desktop wide
switch saying "multi-seat"), the default should match peoples
expectations.
--
Dimi Paun <dimi(a)lattica.com>
Lattica, Inc.
10:08 a.m.
New subject: Tried Pulse Audio Again--No Good For A11y
On Wed, Sep 17, 2008 at 09:45:06AM -0400, Dimi Paun wrote:
This is a good example of a common problem with free software: we
focus
on the fringe cases at the detriment of the common ones (many time the
ratio can be less then 10/90).
Where "fringe case" is defined as "whatever I'm not doing" and
"common case"
is defined at as "the way I do it"?
--
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
10:42 a.m.
New subject: Tried Pulse Audio Again--No Good For A11y
On Wed, 2008-09-17 at 11:08 -0400, Matthew Miller wrote:
Where "fringe case" is defined as "whatever I'm
not doing" and "common
case" is defined at as "the way I do it"?
Not at all. It is not always easy to figure out, but it's not all that
difficult either. There are untold number of cases where we put the
carriage before the horse so to speak:
* slower boot times for _everybody_ because of fringe cases like
when /usr is loaded from the network. Never mind that such
setups are run by technically savvy people that could be bothered
to flip a few switches.
* geditor opens an idiotic tab by default, and it's slow to load
because it's cool to have a "programming" editor. Never mind that
most people are non-programmers, and even those want to see files
quickly without programming. On a fast machine it takes sometimes
2-3 sec to load the darn thing, whereas it takes 250ms to load
notepad in wine!
I could go on. But the bottom line is that we sometimes make bad
decisions for "default" values (I guess because they are mostly
taken by people that are too technical).
And I'm sorry to say it, but for vast majority of cases "default"
should be "what people expect" and that usually means "what Windows
does". I know it sounds heretic, but that's the reality of it. Not that
we should be stuck there forever, but we should have really good
reasons to deviate, and when we do we should do it gently. Instead, we
do it a lot of times "on a whim", and that ends up hurting the end user.
--
Dimi Paun <dimi(a)lattica.com>
Lattica, Inc.
1:49 p.m.
New subject: Tried Pulse Audio Again--No Good For A11y
Dimi Paun wrote:
And I'm sorry to say it, but for vast majority of cases "default"
should be "what people expect" and that usually means "what Windows
does".
If people want to run windows, it isn't difficult to find. I like to
run linux for the things it can do better than windows. Please don't
throw that away.
--
Les Mikesell
lesmikesell(a)gmail.com
2:09 p.m.
New subject: Tried Pulse Audio Again--No Good For A11y
On Wed, 2008-09-17 at 13:49 -0500, Les Mikesell wrote:
If people want to run windows, it isn't difficult to find. I
like to
run linux for the things it can do better than windows. Please don't
throw that away.
Nobody is proposing to throw everything away. Look -- I've been using
Linux _exclusively_ for about 12+ years. I like it.
But we do have our faults too. Blind hatred of Windows will not help
us build a better experience. We should learn from their successes
just like we learn from their failures. At least we have the benefit
of hindsight.
--
Dimi Paun <dimi(a)lattica.com>
Lattica, Inc.
10:07 a.m.
New subject: Tried Pulse Audio Again--No Good For A11y
On Wed, Sep 17, 2008 at 12:39:54PM +0200, Nils Philippsen wrote:
There is a use case for this, namely if you have several
"seats" with
different logged in users: in this case one probably only wants the
sounds of the "active session" being played and others muted. Just in
case you ask, we're using that setup at home, my wife and I are logged
in all the time an switch between users via the applet or
<Ctrl><Alt>F7/F9.
Yes, we do the same at my house.
(Presumably you are also using KDM, given that current GDM is apparently
totally broken in this regard?)
--
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
4:31 a.m.
New subject: Tried Pulse Audio Again--No Good For A11y
On Wed, 2008-09-17 at 11:07 -0400, Matthew Miller wrote:
On Wed, Sep 17, 2008 at 12:39:54PM +0200, Nils Philippsen wrote:
> There is a use case for this, namely if you have several "seats" with
> different logged in users: in this case one probably only wants the
> sounds of the "active session" being played and others muted. Just in
> case you ask, we're using that setup at home, my wife and I are logged
> in all the time an switch between users via the applet or
> <Ctrl><Alt>F7/F9.
Yes, we do the same at my house.
(Presumably you are also using KDM, given that current GDM is apparently
totally broken in this regard?)
No, it doesn't seem broken to me.
Nils
--
Nils Philippsen "Those who would give up Essential Liberty to purchase
Red Hat a little Temporary Safety, deserve neither Liberty
nils(a)redhat.com nor Safety." -- Benjamin Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
1 p.m.
New subject: Tried Pulse Audio Again--No Good For A11y
I've been meaning to comment on your multi-seat setup ...
Nils Philippsen writes:
On Tue, 2008-09-16 at 17:28 -0400, Janina Sajka wrote:
> Matthias Clasen writes:
> > On Tue, 2008-09-16 at 14:34 -0400, Janina Sajka wrote:
[...]
> >
> > > 5.) While I paplay, I try to go Ctrl-Alt-F1. While I'm not prevented
> > > from doing so, paplay believes it should pause playing while I'm away
> > > from the gui tty. Now, who's the genius that figured out this
"feature?"
> >
> > Insults won't help your cause.
> Well, my apologies if this offends you. Is it supposed to work that way,
> though? Is there actually a use case for that behavior? Or is this just
> some incidental artifact?
There is a use case for this, namely if you have several "seats" with
different logged in users: in this case one probably only wants the
sounds of the "active session" being played and others muted. Just in
case you ask, we're using that setup at home, my wife and I are logged
in all the time an switch between users via the applet or
<Ctrl><Alt>F7/F9.
I don't believe it necessarily follows that technology should enforce
who does, and who does not have audio in this circumstance.
Consider an office environment--perhaps it's similar to what you and
your wife have. There are several desks with chairs. Perhaps these are
in an open room. Perhaps there are dividers between the desks to provide
a small measure of privacy.
Each desk in this scenario is undoubtedly equipped with a telephone. No
one would think that the occupant of Desk B should be denied telephone
calls just because the occupant of Desk A is on the phone. Technology is
not required to enforce appropriate social behavior in this
circumstance. The humans who work in this environment have learned
appropriate behaviors in the past century.
Why is the computer desktop so different? What compells us to require
that technology enforce no audio for B while A is provided audio?
Perhaps the users want to listen to voice mail attachments received via
email. Even four or five feet separation is sufficient to do so. We
don't need technology to do for us such things as we humans clearly know
how to negotiate for ourselves.
Indeed, it seems to me precluding multiseat audio is one way of saying
that Fedora does not support telephone answering environments--airline
reservations, bank customer support, etc., etc.
What am I missing here?
Janina
1:17 p.m.
New subject: Tried Pulse Audio Again--No Good For A11y
On Mon, Sep 22, 2008 at 02:00:01PM -0400, Janina Sajka wrote:
I don't believe it necessarily follows that technology should
enforce
who does, and who does not have audio in this circumstance.
I don't think fast-user-switching as described above is really
multi-seat. For true multi-seat, yes, of course each seat would have
its own audio. For a single-seat, fast-user-switching scenario, there
needs to be a way to revoke audio from the first session when a new
user logs into a second session, or when users toggles between
different sessions. Otherwise there is a privacy problem where user A
could run a program that records the Mic input of the soundcard, user
B activates their session, and user A can record all sounds that user
B makes.
7:18 p.m.
New subject: Tried Pulse Audio Again--No Good For A11y
On Mon, 22.09.08 14:00, Janina Sajka (janina(a)rednote.net) wrote:
I've been meaning to comment on your multi-seat setup ...
Nils Philippsen writes:
> On Tue, 2008-09-16 at 17:28 -0400, Janina Sajka wrote:
> > Matthias Clasen writes:
> > > On Tue, 2008-09-16 at 14:34 -0400, Janina Sajka wrote:
> [...]
> > >
> > > > 5.) While I paplay, I try to go Ctrl-Alt-F1. While I'm not
prevented
> > > > from doing so, paplay believes it should pause playing while I'm
away
> > > > from the gui tty. Now, who's the genius that figured out this
"feature?"
> > >
> > > Insults won't help your cause.
> > Well, my apologies if this offends you. Is it supposed to work that way,
> > though? Is there actually a use case for that behavior? Or is this just
> > some incidental artifact?
>
> There is a use case for this, namely if you have several "seats" with
> different logged in users: in this case one probably only wants the
> sounds of the "active session" being played and others muted. Just in
> case you ask, we're using that setup at home, my wife and I are logged
> in all the time an switch between users via the applet or
> <Ctrl><Alt>F7/F9.
>
I don't believe it necessarily follows that technology should enforce
who does, and who does not have audio in this circumstance.
Consider an office environment--perhaps it's similar to what you and
your wife have. There are several desks with chairs. Perhaps these are
in an open room. Perhaps there are dividers between the desks to provide
a small measure of privacy.
Each desk in this scenario is undoubtedly equipped with a telephone. No
one would think that the occupant of Desk B should be denied telephone
calls just because the occupant of Desk A is on the phone. Technology is
not required to enforce appropriate social behavior in this
circumstance. The humans who work in this environment have learned
appropriate behaviors in the past century.
Why is the computer desktop so different? What compells us to require
that technology enforce no audio for B while A is provided audio?
Perhaps the users want to listen to voice mail attachments received via
email. Even four or five feet separation is sufficient to do so. We
don't need technology to do for us such things as we humans clearly know
how to negotiate for ourselves.
Indeed, it seems to me precluding multiseat audio is one way of saying
that Fedora does not support telephone answering environments--airline
reservations, bank customer support, etc., etc.
What am I missing here?
I am pretty sure the airlines and the banks are quite happy that we
are closing the security vulnerarbility that without this feature
allows people to eavesdrop on your audio, without you knowing.
To suspend audio for inactive sessions and only allow audio for active
sessions fixes a big security hole. And it's not just we who fixed
this hole like this. Apple for example does it too. And usually Apple
is the gold standard of user-friendliness, right?
Allowing multiple different users audio device access at the same is a
security nightmare. It has been with ALSA dmix. And it is even more so
in PA.
Far down on my todo list is adding some kind of handover logic between
multiple PA instances, so that we can add fading of audio when we
switch sessions. This would also allow us to continue playback from
inactive sessions if the now active user is OK with that. But this is
complex, security-sensitive and not a priority. So don't expect any
quick results.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
10:07 p.m.
New subject: Tried Pulse Audio Again--No Good For A11y
Lennart Poettering wrote:
To suspend audio for inactive sessions and only allow audio for active
sessions fixes a big security hole.
But it sucks if you are playing music for the room and someone else
wants to check their email.
And it's not just we who fixed
this hole like this. Apple for example does it too. And usually Apple
is the gold standard of user-friendliness, right?
No, it sucks just as much when itunes does it. You expect that kind of
stuff from Apple who only has a short history of multi-user machines and
who would really rather sell you an apple tv or ipod with dock that you
can dedicate to driving your speakers, though. Linux has always been
multi-user and doesn't have any such excuses for arbitrarily
disconnecting devices.
Allowing multiple different users audio device access at the same is
a
security nightmare. It has been with ALSA dmix. And it is even more so
in PA.
Doesn't the kernel have a mechanism for exclusive locks on devices if
someone wants to have exclusive access? It's not all that difficult to
eavesdrop on music playing loudly anyway...
Far down on my todo list is adding some kind of handover logic
between
multiple PA instances, so that we can add fading of audio when we
switch sessions. This would also allow us to continue playback from
inactive sessions if the now active user is OK with that. But this is
complex, security-sensitive and not a priority. So don't expect any
quick results.
What's the right way to set up a media player service that isn't
attached to anyone's session?
--
Les Mikesell
lesmikesell(a)gmail.com
8:05 a.m.
New subject: Tried Pulse Audio Again--No Good For A11y
On Mon, 22.09.08 22:07, Les Mikesell (lesmikesell(a)gmail.com) wrote:
Lennart Poettering wrote:
> To suspend audio for inactive sessions and only allow audio for active
> sessions fixes a big security hole.
But it sucks if you are playing music for the room and someone else wants
to check their email.
Yes, I know that some people don't like that behaviour. We had this
discussion already. I already put it on my TODO list months ago. We
can end this discussion here and now.
> And it's not just we who fixed
> this hole like this. Apple for example does it too. And usually Apple
> is the gold standard of user-friendliness, right?
No, it sucks just as much when itunes does it. You expect that kind of
stuff from Apple who only has a short history of multi-user machines and
who would really rather sell you an apple tv or ipod with dock that you can
dedicate to driving your speakers, though. Linux has always been multi-user
and doesn't have any such excuses for arbitrarily disconnecting
devices.
"arbitrarily"?
Oh man. Claiming that things are right because Linux always did it
this way is not very convincing. You never noticed that quite a few
things in Linux haven't been all that shiny right from day 0? Some
things got fixed by now, and this is just another instance.
> Allowing multiple different users audio device access at the same
is a
> security nightmare. It has been with ALSA dmix. And it is even more so
> in PA.
Doesn't the kernel have a mechanism for exclusive locks on devices if
someone wants to have exclusive access? It's not all that difficult to
eavesdrop on music playing loudly anyway...
Access to audio devices (both OSS and ALSA) is exclusive by default anyway.
> Far down on my todo list is adding some kind of handover logic
between
> multiple PA instances, so that we can add fading of audio when we
> switch sessions. This would also allow us to continue playback from
> inactive sessions if the now active user is OK with that. But this is
> complex, security-sensitive and not a priority. So don't expect any
> quick results.
What's the right way to set up a media player service that isn't attached
to anyone's session?
You can bypass PA if you wish. Or run a specific tailored PA
instance for it. It's up to you.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
3:25 p.m.
New subject: Tried Pulse Audio Again--No Good For A11y
Lennart Poettering wrote:
>> And it's not just we who fixed
>> this hole like this. Apple for example does it too. And usually Apple
>> is the gold standard of user-friendliness, right?
> No, it sucks just as much when itunes does it. You expect that kind of
> stuff from Apple who only has a short history of multi-user machines and
> who would really rather sell you an apple tv or ipod with dock that you can
> dedicate to driving your speakers, though. Linux has always been multi-user
> and doesn't have any such excuses for arbitrarily disconnecting
> devices.
"arbitrarily"?
Arbitrarily, as in guessing who should have exclusive access based on
nothing that particularly relates to the specific audio device. It is
no more right than automatically killing scheduled tape backups would be
because someone else logged in on a keyboard near the tape device.
Oh man. Claiming that things are right because Linux always did it
this way is not very convincing.
Linux what? The kernel doesn't make arbitrary access decisions by
itself, does it?
You never noticed that quite a few
things in Linux haven't been all that shiny right from day 0? Some
things got fixed by now, and this is just another instance.
Fixed - so the same machine doing audio output can't be used for
anything else?
>> Allowing multiple different users audio device access at the
same is a
>> security nightmare. It has been with ALSA dmix. And it is even more so
>> in PA.
> Doesn't the kernel have a mechanism for exclusive locks on devices if
> someone wants to have exclusive access? It's not all that difficult to
> eavesdrop on music playing loudly anyway...
Access to audio devices (both OSS and ALSA) is exclusive by default anyway.
Exclusive access is OK. Killing that access based on unrelated
circumstances isn't.
> What's the right way to set up a media player service that
isn't attached
> to anyone's session?
You can bypass PA if you wish. Or run a specific tailored PA
instance for it. It's up to you.
I meant in Fedora.
--
Les Mikesell
lesmikesell(a)gmail.com
6:13 p.m.
New subject: Tried Pulse Audio Again--No Good For A11y
On Tue, 23.09.08 15:25, Les Mikesell (lesmikesell(a)gmail.com) wrote:
>> No, it sucks just as much when itunes does it. You expect
that kind of
>> stuff from Apple who only has a short history of multi-user machines and
>> who would really rather sell you an apple tv or ipod with dock that you
>> can dedicate to driving your speakers, though. Linux has always been
>> multi-user and doesn't have any such excuses for arbitrarily
>> disconnecting
>> devices.
> "arbitrarily"?
Arbitrarily, as in guessing who should have exclusive access based on
nothing that particularly relates to the specific audio device. It is no
more right than automatically killing scheduled tape backups would be
because someone else logged in on a keyboard near the tape device.
We generally consider speakers/mikes/headphones to be part of the
workplace of the user, i.e. together with mouse/keyboard/screen
we switch them over when the active session changes.
And again, that's the way *I* think it makes the most sense.
Of course, you are free to consider audio to be hw that is completely
detached from sessions. I disagree. Most of the RH engineers I talked
to about this agree with how *I* see things. (And Apple too, ...)
Nonetheless, I do see some sense in the way you want to use the audio
devices. However, I don't think that would be the normal use-case, and I also
don't think that defaulting to this insecure configuration would be a
good choice.
So, let's end this discussion right now. I did acknowledge the
validity of your usecase, although I priorize a different
one. Supporting your preferred way of doing session switching for
audio is on my TODO list (although way at the end). That's the most
you will get from me. If you disagrees with my priorities, then bad
luck, you won't be able to change them.
BTW, Free Software is about scratching your own itches. Apparently
this functionality is very important to you, otherwise we wouldn't
have this discussion again and again and again. Hence: I AM HAPPY TO
MERGE YOUR PATCHES (if they are good)!
> Oh man. Claiming that things are right because Linux always did
it
> this way is not very convincing.
Linux what? The kernel doesn't make arbitrary access decisions by itself,
does it?
Oh man, stop it. Those decisions are not arbitrary. They make
sense. (Except maybe for you)
>> Doesn't the kernel have a mechanism for exclusive locks
on devices if
>> someone wants to have exclusive access? It's not all that difficult to
>> eavesdrop on music playing loudly anyway...
> Access to audio devices (both OSS and ALSA) is exclusive by default
> anyway.
Exclusive access is OK. Killing that access based on unrelated
circumstances isn't.
We don't "kill" access. We suspend access until you reactivate your
session.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
10:28 p.m.
New subject: Tried Pulse Audio Again--No Good For A11y
Lennart Poettering wrote:
> Arbitrarily, as in guessing who should have exclusive access based on
> nothing that particularly relates to the specific audio device. It is no
> more right than automatically killing scheduled tape backups would be
> because someone else logged in on a keyboard near the tape device.
We generally consider speakers/mikes/headphones to be part of the
workplace of the user, i.e. together with mouse/keyboard/screen
we switch them over when the active session changes.
But, I rarely log on to the keyboard/screen attached to the machines
running Linux. NX is so good that there is rarely any need to.
And again, that's the way *I* think it makes the most sense.
If you haven't, give freenx/NX a try, floating your running session
among displays at work, perhaps a wireless laptop, and pick them up from
home with everything still running. And try it with several people
sharing a machine. You might get used to the concept that your devices
are really not that closely coupled. Or perhaps at least that your
session isn't tied to the local console. X never intended it to be, but
before freenx it wasn't that great remotely.
Of course, you are free to consider audio to be hw that is
completely
detached from sessions. I disagree. Most of the RH engineers I talked
to about this agree with how *I* see things. (And Apple too, ...)
Keep in mind that Apple makes a very good business out of selling things
to help deal with what OS X lacks natively on the Macs. For example you
can't even drive two different output devices at once to have always-on
built-in speakers plus a USB device feeding an amp that you can power up
for more volume. But they'll sell you an apple tv or airport express
or ipod and dock to fix that for you. And I didn't realize RH was very
involved in audio at all.
Nonetheless, I do see some sense in the way you want to use the
audio
devices. However, I don't think that would be the normal use-case, and I also
don't think that defaulting to this insecure configuration would be a
good choice.
The default isn't a particular problem - but that's not the only
possible or even likely scenario, leaving the question of how to change
the configuration.
BTW, Free Software is about scratching your own itches. Apparently
this functionality is very important to you, otherwise we wouldn't
have this discussion again and again and again. Hence: I AM HAPPY TO
MERGE YOUR PATCHES (if they are good)!
Realistically, something like mediatomb feeding an independent media
player like the one included in a PS3 is probably a better solution for
what I want but I can't help thinking that a linux box should be able to
do it all by itself while still providing other services.
> Exclusive access is OK. Killing that access based on unrelated
> circumstances isn't.
We don't "kill" access. We suspend access until you reactivate your
session.
So if I could get control of the local audio device in a remote X or
freenx session that keeps running, would it keep control even if a
different user logs on at the console?
--
Les Mikesell
lesmikesell(a)gmail.com
7:33 a.m.
New subject: Tried Pulse Audio Again--No Good For A11y
On Tue, 23.09.08 22:28, Les Mikesell (lesmikesell(a)gmail.com) wrote:
> And again, that's the way *I* think it makes the most sense.
If you haven't, give freenx/NX a try, floating your running session among
displays at work, perhaps a wireless laptop, and pick them up from home
with everything still running. And try it with several people sharing a
machine. You might get used to the concept that your devices are really
not that closely coupled. Or perhaps at least that your session isn't tied
to the local console. X never intended it to be, but before freenx it
wasn't that great remotely.
If you use a terminal client, then audio should be forwarded to
it. Audio should always be sent to the same machine that shows you the
video. Audio is part of the workplace, not the server. From the
terminal client to the terminal server we send keyboard, mouse, audio
recording. From the terminal server to the terminal client we send
audio playback and screen contents.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
8:17 a.m.
New subject: Tried Pulse Audio Again--No Good For A11y
Lennart Poettering wrote:
>> And again, that's the way *I* think it makes the most sense.
> If you haven't, give freenx/NX a try, floating your running session among
> displays at work, perhaps a wireless laptop, and pick them up from home
> with everything still running. And try it with several people sharing a
> machine. You might get used to the concept that your devices are really
> not that closely coupled. Or perhaps at least that your session isn't tied
> to the local console. X never intended it to be, but before freenx it
> wasn't that great remotely.
If you use a terminal client, then audio should be forwarded to
it.
That should be an option of course, perhaps the default choice even
though it won't always work. If you are on a low bandwidth connection
which works fine otherwise with NX, audio will be horrible. And your
client may not have speakers - you may use many clients and good
speakers are expensive and not portable.
Audio should always be sent to the same machine that shows you the
video.
No, audio should always be sent to the device you choose. Guesswork is
not a good thing.
Audio is part of the workplace, not the server.
Sometimes you would want an audio 'session' at your local device,
sometimes you want to control the device on the server.
From the
terminal client to the terminal server we send keyboard, mouse, audio
recording. From the terminal server to the terminal client we send
audio playback and screen contents.
I'm usually in the same room with the server, with the server connected
to speakers intended for the whole room. But, I want to use the
keyboard, mouse, and monitor from a nearby desktop box or float the
display to a laptop - and when I pick up the session from home I don't
want to attempt audio because of the bandwidth issue. Windows RDP
connections attempt that but it's not pretty. The other point about NX
as a client is that as far as the local machine is concerned, it is just
one app running in one window, sort of like Xnest. You still have full
access to all the other apps you want to run locally and it usually
makes much more sense to run apps that require local audio locally than
to forward them from some remote session.
Thinking of your computer as a single piece might make sense for someone
who only has one, but does anyone really run fedora as their one and
only computer?
--
Les Mikesell
lesmikesell(a)gmail.com
10:28 a.m.
New subject: Tried Pulse Audio Again--No Good For A11y
On Wed, 2008-09-24 at 08:17 -0500, Les Mikesell wrote:
but does anyone really run fedora as their one and
only computer?
I do, and have for years. Before I ever got involved with Fedora, back
in the RHL days.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
10:36 a.m.
New subject: Tried Pulse Audio Again--No Good For A11y
2008/9/24 Jesse Keating <jkeating(a)redhat.com>
On Wed, 2008-09-24 at 08:17 -0500, Les Mikesell wrote:
> but does anyone really run fedora as their one and
> only computer?
I do, and have for years. Before I ever got involved with Fedora, back
in the RHL days.
I've been only using Fedora at home since Core 1. My kids, age 3 and 6,
both have their own computers, both Fedora and my wife switched from
Windblows to Fedora about this time last year!
And I ask, why wouldn't you use Fedora as your only computer??
--
projecthuh.com
All of my bits are free, are yours? Fedoraproject.org
10:48 a.m.
New subject: Tried Pulse Audio Again--No Good For A11y
On Wed, Sep 24, 2008 at 08:28:09AM -0700, Jesse Keating wrote:
On Wed, 2008-09-24 at 08:17 -0500, Les Mikesell wrote:
> but does anyone really run fedora as their one and
> only computer?
I do, and have for years. Before I ever got involved with Fedora, back
in the RHL days.
Ditto. And not just for home use either. I use Fedora, and only Fedora,
at work too.
josh
11:17 a.m.
New subject: Tried Pulse Audio Again--No Good For A11y
Jesse Keating wrote:
On Wed, 2008-09-24 at 08:17 -0500, Les Mikesell wrote:
> but does anyone really run fedora as their one and
> only computer?
Fedora at home. Fedora on work laptop. No stinkin' dual boot. Before
that RedHat starting at RH 6.1. Before that Solaris and MacOS. Never
used Windows.
11:16 a.m.
New subject: Tried Pulse Audio Again--No Good For A11y
Les Mikesell wrote:
Thinking of your computer as a single piece might make sense for
someone
who only has one, but does anyone really run fedora as their one and
only computer?
That's like saying Fedora should only be targeted at highly tech-savvy
users, which I have to take issue at. Do we really want to limit
ourselves to that audience?
(To those that stated "I only use Fedora on <list of computers>, I think
you all missed the point of the question, which was, 'do any Fedora
users have /only one computer/', not 'does anyone use only Fedora'.)
--
Matthew
I was recently amused by issuing 'rm -rf $KDEDIR'... from Konsole, while
in a KDE session. And nothing bad happened whatsoever. Try THAT on
Windows :-D.
11:57 a.m.
New subject: Tried Pulse Audio Again--No Good For A11y
On Wed, 2008-09-24 at 11:16 -0500, Matthew Woehlke wrote:
(To those that stated "I only use Fedora on <list of computers>, I think
you all missed the point of the question, which was, 'do any Fedora
users have /only one computer/', not 'does anyone use only Fedora'.)
Until I started working from home, yes. I had exactly one computer, my
work laptop. It ran Fedora and only Fedora. My wife had her own
laptop.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
12:11 p.m.
New subject: Tried Pulse Audio Again--No Good For A11y
Matthew Woehlke wrote:
> Thinking of your computer as a single piece might make sense for
> someone who only has one, but does anyone really run fedora as their
> one and only computer?
That's like saying Fedora should only be targeted at highly tech-savvy
users, which I have to take issue at. Do we really want to limit
ourselves to that audience?
If you don't serve that audience or offer a forward path beyond entry
level, who do you serve and who is going to promote it?
(To those that stated "I only use Fedora on <list of
computers>, I think
you all missed the point of the question, which was, 'do any Fedora
users have /only one computer/', not 'does anyone use only Fedora'.)
Yes, it was at least a two-part question. One is whether you have more
than one box - with the implication that in the likely scenario that you
do, you'll want to split services among them in various ways and access
each from the others. The other is whether Fedora is the best, or even
a possible choice for every function. My impression is that even though
individual computers are becoming more powerful, in practice things are
becoming more distributed and parts are more mobile. While there is a
trend toward hiding all of the networking under browser based
applications, it is still a mistake to throw away the native ability of
X to run about anything anywhere and handle multiple instances on the
same box. If you aren't using Fedora for every function, it should
still be a good choice for that - and with freenx/NX it is accessible
from other platforms as well.
--
Les Mikesell
lesmikesell(a)gmail.com
12:54 p.m.
New subject: Tried Pulse Audio Again--No Good For A11y
Les Mikesell wrote:
Matthew Woehlke wrote:
>> Thinking of your computer as a single piece might make sense for
>> someone who only has one, but does anyone really run fedora as their
>> one and only computer?
>
> That's like saying Fedora should only be targeted at highly tech-savvy
> users, which I have to take issue at. Do we really want to limit
> ourselves to that audience?
If you don't serve that audience or offer a forward path beyond entry
level, who do you serve and who is going to promote it?
Of course we /should/ serve those users, I never suggested otherwise!
But should we serve /only/ those users?
It's fine and good to make things work for people that do session
hopping. I just didn't like how the original question seemed to imply
that those are the only people we care about.
Maybe you could have asked instead, "do we really expect that no one
running Fedora has more then one computer?", which indicates a positive
interest in such people without seeming to assume that they are the only
group that exists.
--
Matthew
I was recently amused by issuing 'rm -rf $KDEDIR'... from Konsole, while
in a KDE session. And nothing bad happened whatsoever. Try THAT on
Windows :-D.
3:50 p.m.
New subject: Tried Pulse Audio Again--No Good For A11y
Matthew Woehlke wrote:
>>> Thinking of your computer as a single piece might make sense for
>>> someone who only has one, but does anyone really run fedora as their
>>> one and only computer?
>>
>> That's like saying Fedora should only be targeted at highly
>> tech-savvy users, which I have to take issue at. Do we really want to
>> limit ourselves to that audience?
>
> If you don't serve that audience or offer a forward path beyond entry
> level, who do you serve and who is going to promote it?
Of course we /should/ serve those users, I never suggested otherwise!
But should we serve /only/ those users?
I didn't say that either, but typically the simple case is a subset of
the more complex one so if the design is right you don't have to make
that choice.
It's fine and good to make things work for people that do session
hopping. I just didn't like how the original question seemed to imply
that those are the only people we care about.
I didn't quite mean it like that, but X and unix-like systems just
naturally divorce applications and sessions from hardware and it seems
wrong to throw that away even if you don't need it today. Especially if
it is just to avoid the trouble of properly managing profile data.
Maybe you could have asked instead, "do we really expect that no
one
running Fedora has more then one computer?", which indicates a positive
interest in such people without seeming to assume that they are the only
group that exists.
I'll go even farther that direction if you want: "do you really expect
that no one running fedora will ever have more than one computer?"
When/if they do, I'd expect them to want to share resources among them.
--
Les Mikesell
lesmikesell(a)gmail.com
4:20 p.m.
New subject: Tried Pulse Audio Again--No Good For A11y
Les Mikesell wrote:
Matthew Woehlke wrote:
> It's fine and good to make things work for people that do session
> hopping. I just didn't like how the original question seemed to imply
> that those are the only people we care about.
I didn't quite mean it like that, but X and unix-like systems just
naturally divorce applications and sessions from hardware and it seems
wrong to throw that away even if you don't need it today. Especially if
it is just to avoid the trouble of properly managing profile data.
Indeed; that's almost exactly what I said ranting about Firefox :-D. I'm
very much on your side here (just so long as we don't forget the trivial
case ;-) ).
> Maybe you could have asked instead, "do we really expect
that no one
> running Fedora has more then one computer?", which indicates a
> positive interest in such people without seeming to assume that they
> are the only group that exists.
I'll go even farther that direction if you want: "do you really expect
that no one running fedora will ever have more than one computer?"
When/if they do, I'd expect them to want to share resources among them.
I considered that addition to be implied, but yes, that's certainly
fine. Thanks. It's just that the original wording bugged me :-).
--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
I was recently amused by issuing 'rm -rf $KDEDIR'... from Konsole, while
in a KDE session. And nothing bad happened whatsoever. Try THAT on
Windows :-D.
12:46 p.m.
New subject: Tried Pulse Audio Again--No Good For A11y
2008/9/24 Les Mikesell <lesmikesell(a)gmail.com>
Thinking of your computer as a single piece might make sense for someone
who only has one, but does anyone really run fedora as their one and only
computer?
I have run Linux as my one and only OS for over a decade, right now both
machines I own run Fedora and that has been the case basically since FC1
came out. I would happily recommend switching a family' single machine to
pure Fedora.
- David
7 p.m.
New subject: Tried Pulse Audio Again--No Good For A11y
On Tue, 16.09.08 15:12, Matthias Clasen (mclasen(a)redhat.com) wrote:
> 3.) Logging in I hear first the GDM "audio logo,"
think I'll call it
> an earcon from now on. But, Orca launches in my secondary audio device.
> That's inappropriate, but I have no way to control that except to unplug
> my secondary and tertiary audio devices and start over.
Hardly pulseaudios fault if orca picks the wrong device. I have no idea
how orca decides which device to use.
Actually, nowadays I prefer seeing PA as black box, where only PA
decides what device clients should be connecting to, not the clients
themselves. Policy decisions should be up to the sound server, not the
client.
That said, in some situations (like probably this one) it does make
sense to have device selection in the clients
themsevles. Unfortunately ALSA device enumeratin is rather flaky and
we don't support it in the PA backend for libasound.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
5:03 a.m.
New subject: Tried Pulse Audio Again--No Good For A11y
On Tuesday 23 September 2008 01:00:06 Lennart Poettering wrote:
Actually, nowadays I prefer seeing PA as black box, where only PA
decides what device clients should be connecting to, not the clients
themselves. Policy decisions should be up to the sound server, not the
client.
This sounds like "we want to control everything" and, as the user of the machine
I want to control everything. It's my tool. That's how I expect it to behave,
not talk back to me (shades of 2001 here).
7:18 a.m.
New subject: Tried Pulse Audio Again--No Good For A11y
On Tue, 23.09.08 11:03, Bill Crawford (billcrawford1970(a)gmail.com) wrote:
On Tuesday 23 September 2008 01:00:06 Lennart Poettering wrote:
> Actually, nowadays I prefer seeing PA as black box, where only PA
> decides what device clients should be connecting to, not the clients
> themselves. Policy decisions should be up to the sound server, not the
> client.
This sounds like "we want to control everything" and, as the user of the
machine
I want to control everything. It's my tool. That's how I expect it to behave,
not talk back to me (shades of 2001 here).
Bah, bah, bah!
I take that "world domination" goal very personal, you know? I want to
control all your audio streams, muaahahahahah! Muahahahahah! All your
streams are belong to us! muahahahaah!
Seriously, of course the sound server should decide the device policy
based on *user settings*, and it already does just that. PA will decide
things for you -- but only based on your preferences.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
9:16 a.m.
New subject: Tried Pulse Audio Again--No Good For A11y
On Tue, 2008-09-23 at 14:18 +0200, Lennart Poettering wrote:
All your streams are belong to us!
You've seen the EULA example, right?
http://www.packagekit.org/img/gpk-eula.png
Richard.
9:53 a.m.
New subject: Tried Pulse Audio Again--No Good For A11y
On Tue, 23.09.08 15:16, Richard Hughes (hughsient(a)gmail.com) wrote:
On Tue, 2008-09-23 at 14:18 +0200, Lennart Poettering wrote:
> All your streams are belong to us!
You've seen the EULA example, right?
http://www.packagekit.org/img/gpk-eula.png
Awesome! How do I add this to my packages? ;-)
Although actually, I think for my goal of world domination it would
be counterprodutive to first ask for permission.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
3:12 p.m.
New subject: Tried Pulse Audio Again--No Good For A11y
On Tue, Sep 16, 2008 at 02:34:44PM -0400, Janina Sajka wrote:
5.) While I paplay, I try to go Ctrl-Alt-F1. While I'm not
prevented
from doing so, paplay believes it should pause playing while I'm away
from the gui tty. Now, who's the genius that figured out this "feature?"
That's ConsoleKit deactivating the streams on the non-active console.
This is so mult-user-switching can work and each user can have their
own audio.
3:46 p.m.
New subject: Tried Pulse Audio Again--No Good For A11y
On Tue, Sep 16, 2008 at 12:12 PM, Chuck Anderson <cra(a)wpi.edu> wrote:
That's ConsoleKit deactivating the streams on the non-active
console.
This is so mult-user-switching can work and each user can have their
own audio.
Technically.. is it PolicyKit or ConsoleKit doing the deactivation?
I always get confused as to which one of those is doing what.
Regardless, PolicyKit's authorization mechanisms both on the cmdline
and the gui should be usable to change how access control for the
streams work to widen the access scope to sound devices to any user at
the console and not just the active console..or even wider if desired.
-jef
4:02 p.m.
New subject: Tried Pulse Audio Again--No Good For A11y
On Tue, Sep 16, 2008 at 4:46 PM, Jeff Spaleta <jspaleta(a)gmail.com> wrote:
On Tue, Sep 16, 2008 at 12:12 PM, Chuck Anderson <cra(a)wpi.edu>
wrote:
> That's ConsoleKit deactivating the streams on the non-active console.
> This is so mult-user-switching can work and each user can have their
> own audio.
Technically.. is it PolicyKit or ConsoleKit doing the deactivation?
I always get confused as to which one of those is doing what.
Neither actually - pulseaudio is listening to ConsoleKit events and
giving up the stream itself.
Regardless, PolicyKit's authorization mechanisms both on the
cmdline
and the gui should be usable to change how access control for the
streams work to widen the access scope to sound devices to any user at
the console and not just the active console..or even wider if desired.
This is a bit of a grey area between "system configuration" and
"security", but I'd suggest that if someone needs the ability to
change the behavior, that should be a change to pulseaudio and not try
to express it in policykit.
4:09 p.m.
New subject: Tried Pulse Audio Again--No Good For A11y
On Tue, Sep 16, 2008 at 1:02 PM, Colin Walters <walters(a)verbum.org> wrote:
This is a bit of a grey area between "system configuration"
and
"security", but I'd suggest that if someone needs the ability to
change the behavior, that should be a change to pulseaudio and not try
to express it in policykit.
So its appropriate for policykit to expose direct access to sound
devices via hal? But not control over pulseaudio streams? Hmm...
-jef
5:05 p.m.
New subject: Tried Pulse Audio Again--No Good For A11y
Chuck Anderson writes:
On Tue, Sep 16, 2008 at 02:34:44PM -0400, Janina Sajka wrote:
> 5.) While I paplay, I try to go Ctrl-Alt-F1. While I'm not prevented
> from doing so, paplay believes it should pause playing while I'm away
> from the gui tty. Now, who's the genius that figured out this
"feature?"
That's ConsoleKit deactivating the streams on the non-active console.
This is so mult-user-switching can work and each user can have their
own audio.
OK. Thanks for the explanation.
So, the concept limits audio to a single console, even if the same user
is logged in somewhere else? I guess running pa as a systen daemon would
not exhibit this behavior?
Janina
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
--
Janina Sajka, Phone: +1.202.595.7777; sip:janina@a11y.org
Partner, Capital Accessibility LLC http://CapitalAccessibility.Com
Marketing the Owasys 22C talking screenless cell phone in the U.S. and Canada
Learn more at http://ScreenlessPhone.Com
Chair, Open Accessibility janina(a)a11y.org
Linux Foundation http://a11y.org
7:40 p.m.
New subject: Tried Pulse Audio Again--No Good For A11y
On Tue, 2008-09-16 at 18:05 -0400, Janina Sajka wrote:
Chuck Anderson writes:
> On Tue, Sep 16, 2008 at 02:34:44PM -0400, Janina Sajka wrote:
> > 5.) While I paplay, I try to go Ctrl-Alt-F1. While I'm not prevented
> > from doing so, paplay believes it should pause playing while I'm away
> > from the gui tty. Now, who's the genius that figured out this
"feature?"
>
> That's ConsoleKit deactivating the streams on the non-active console.
> This is so mult-user-switching can work and each user can have their
> own audio.
>
OK. Thanks for the explanation.
So, the concept limits audio to a single console, even if the same user
is logged in somewhere else? I guess running pa as a systen daemon would
not exhibit this behavior?
Actually, Lennart changed PA to not be strictly per-session, but
per-user, I think. But I don't know the details of how that works.
I've looked into your 'login screen ready' sound problem, and found that
it doesn't work atm due to a pulseaudio bug:
https://bugzilla.redhat.com/show_bug.cgi?id=462537
Matthias
10:57 p.m.
New subject: Tried Pulse Audio Again--No Good For A11y
On Tue, Sep 16, 2008 at 8:40 PM, Matthias Clasen <mclasen(a)redhat.com> wrote:
On Tue, 2008-09-16 at 18:05 -0400, Janina Sajka wrote:
> Chuck Anderson writes:
> > On Tue, Sep 16, 2008 at 02:34:44PM -0400, Janina Sajka wrote:
> > > 5.) While I paplay, I try to go Ctrl-Alt-F1. While I'm not
prevented
> > > from doing so, paplay believes it should pause playing while I'm away
> > > from the gui tty. Now, who's the genius that figured out this
"feature?"
> >
> > That's ConsoleKit deactivating the streams on the non-active console.
> > This is so mult-user-switching can work and each user can have their
> > own audio.
> >
> OK. Thanks for the explanation.
>
> So, the concept limits audio to a single console, even if the same user
> is logged in somewhere else? I guess running pa as a systen daemon would
> not exhibit this behavior?
>
Actually, Lennart changed PA to not be strictly per-session, but
per-user, I think. But I don't know the details of how that works.
Which is broken because in reality per-session and per-user are the
same thing. You can't log in multiple times:
http://cgwalters.livejournal.com/16885.html
7:25 p.m.
New subject: Tried Pulse Audio Again--No Good For A11y
On Tue, 16.09.08 23:57, Colin Walters (walters(a)verbum.org) wrote:
>> > That's ConsoleKit deactivating the streams on the
non-active console.
>> > This is so mult-user-switching can work and each user can have their
>> > own audio.
>> >
>> OK. Thanks for the explanation.
>>
>> So, the concept limits audio to a single console, even if the same user
>> is logged in somewhere else? I guess running pa as a systen daemon would
>> not exhibit this behavior?
>>
>
> Actually, Lennart changed PA to not be strictly per-session, but
> per-user, I think. But I don't know the details of how that works.
Which is broken because in reality per-session and per-user are the
same thing. You can't log in multiple times:
http://cgwalters.livejournal.com/16885.html
As far as I know we again allow multiple simultaneous X logins by the
same user. Also, PA supports console logins now, where multiple logins
are the common case.
I'd love to have a per-homedir/per-machine bus in D-Bus. This would
allow me to start PA up via normal activation. Unfortunately we don't
have such a bus and adding it to D-Bus is admittedly questionnable
since only in the fewest cases using such a bus is valid. Those cases
are the ones where machine-specific resources are managed by a user
dbus service. Besides PA only the new V4L daemon (possibly) comes to
my mind that fall into this category. Adding such a bus for just two
users probably doesn't make too much sense. Especially since according
to Scott Upstart will eventually support starting per-user "singleton"
daemons easily.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
11:55 a.m.
New subject: Tried Pulse Audio Again--No Good For A11y
On Mon, Sep 22, 2008 at 8:25 PM, Lennart Poettering
<mzerqung(a)0pointer.de> wrote:
As far as I know we again allow multiple simultaneous X logins by
the
same user.
If we do, it's broken.
Also, PA supports console logins now, where multiple logins
are the common case.
One of the many ways in which the consoles are broken.
I'd love to have a per-homedir/per-machine bus in D-Bus. This
would
allow me to start PA up via normal activation. Unfortunately we don't
have such a bus and adding it to D-Bus is admittedly questionnable
since only in the fewest cases using such a bus is valid. Those cases
are the ones where machine-specific resources are managed by a user
dbus service. Besides PA only the new V4L daemon (possibly) comes to
my mind that fall into this category. Adding such a bus for just two
users probably doesn't make too much sense. Especially since according
to Scott Upstart will eventually support starting per-user "singleton"
daemons easily.
Adding such a bus makes no sense because the desktop and apps will
break/disallow concurrent usage. About the only thing you can do in
such a second session is run a terminal, which you could do equally
well with just a new tab in your current session.
12:58 p.m.
New subject: Tried Pulse Audio Again--No Good For A11y
On Tue, 23.09.08 12:55, Colin Walters (walters(a)verbum.org) wrote:
> As far as I know we again allow multiple simultaneous X logins
by the
> same user.
If we do, it's broken.
Maybe we should come to some official agreement if we do want to allow
simultaneous X logins of the same user or not. In the last year or two
it was always a constant forth and back whether we would want to
support this or not. First people told me we should allow this, then
they told me we already gave up on it, then people told me we would
like to support it, now you again say we don't want it.
So, what's it now? Shall we support multiple simultaneous logins by the
same user on X or shall we not? I am pretty sure in GNOME allowing
this is a lost cause or would mean a lot of work, but maybe some of the
oh-I-have-a-gray-beard-i-like-fvwm fraction really insists on having
this feature.
What's the current default for gdm?
> dbus service. Besides PA only the new V4L daemon (possibly)
comes to
> my mind that fall into this category. Adding such a bus for just two
> users probably doesn't make too much sense. Especially since according
> to Scott Upstart will eventually support starting per-user "singleton"
> daemons easily.
Adding such a bus makes no sense because the desktop and apps will
break/disallow concurrent usage. About the only thing you can do in
such a second session is run a terminal, which you could do equally
well with just a new tab in your current session.
Sure, I see the problem. Always did. But I wonder if the current plan
is to fix all those apps, or that we already gave up on it.
Anyway, for now I support multiple logins, since that is the superset
of the single-login case. But nonetheless I'd be interested to know
what actually is on.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
2:11 p.m.
New subject: Tried Pulse Audio Again--No Good For A11y
Colin Walters wrote:
> As far as I know we again allow multiple simultaneous X logins by the
> same user.
If we do, it's broken.
Why shouldn't I be able to do as many xdm logins as I want as the same
user? This isn't an X issue.
--
Les Mikesell
lesmikesell(a)gmail.com
2:30 p.m.
New subject: Tried Pulse Audio Again--No Good For A11y
On Tue, 23.09.08 14:11, Les Mikesell (lesmikesell(a)gmail.com) wrote:
Colin Walters wrote:
>> As far as I know we again allow multiple simultaneous X logins by the
>> same user.
> If we do, it's broken.
Why shouldn't I be able to do as many xdm logins as I want as the same
user? This isn't an X issue.
Because many apps don't distuingish state from configuration cleanly.
For example: you configure your gnome panel to include a clock
applet. Then you open another session and add a network monitor applet
to it. What do you expect from this? That both panels will always stay
perfectly in sync and the network monitor applet is transparently
added to the first session as well? When you log out from both, what
happens when you log in again, do you get the panel layout from the
first session or from the second session?
Also, most WMs support multiple desktops, which is basically the same
as multiple sessions.
The question is: is it worth bothering at all with questions like the
panel question above? Since the feature is redundant we might simply
say: forget it, let's disable multiple logins and the problem is
gone.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
2:36 p.m.
New subject: Tried Pulse Audio Again--No Good For A11y
On Tue, Sep 23, 2008 at 3:30 PM, Lennart Poettering
<mzerqung(a)0pointer.de> wrote:
Also, most WMs support multiple desktops, which is basically the same
as multiple sessions.
No - a concrete difference is that when you click the Firefox icon
with multiple desktops, you get a new window for the same Firefox
process because Firefox uses the X server as a naming service. More
modern applications use the DBus session bus for this purpose.
There is X server per session bus per user login per user id.
Breaking that model greatly increases pain for very little to no gain.
3:50 p.m.
New subject: Tried Pulse Audio Again--No Good For A11y
Lennart Poettering wrote:
On Tue, 23.09.08 14:11, Les Mikesell (lesmikesell(a)gmail.com) wrote:
> Colin Walters wrote:
>>> As far as I know we again allow multiple simultaneous X logins by the
>>> same user.
>> If we do, it's broken.
> Why shouldn't I be able to do as many xdm logins as I want as the same
> user? This isn't an X issue.
Because many apps don't distuingish state from configuration cleanly.
So you'd cripple the system because there are some bad apps?
For example: you configure your gnome panel to include a clock
applet. Then you open another session and add a network monitor applet
to it. What do you expect from this? That both panels will always stay
perfectly in sync and the network monitor applet is transparently
added to the first session as well? When you log out from both, what
happens when you log in again, do you get the panel layout from the
first session or from the second session?
How is this different than running 2 instances of vi? If you edit the
same file at the same time you'll have a conflict. That doesn't mean
you should cripple the system to the point where it can't run 2
instances of vi.
Also, most WMs support multiple desktops, which is basically the
same
as multiple sessions.
Except I want my other logins to be from other places. Like one on the
console, one freenx/NX'd and floating, others xdm'd, perhaps Xnested.
Mostly I don't want to need to know the status of any of the other
desktops when I start a new one. I could probably live with one
floating freenx if it could float on and off the console and always
resize to match the NX client, but those don't seem to work right.
The question is: is it worth bothering at all with questions like
the
panel question above? Since the feature is redundant we might simply
say: forget it, let's disable multiple logins and the problem is
gone.
Windows terminal services has gotten this more or less right since at
least windows 2000 server that included 2 licenses for administrative
use. If they can do it with an interface that wasn't designed to be
remote or multiuser, it can't be that hard.
But, if it can't be done right, the WM should enforce it and give you a
choice of killing the old session when you attempt a new login instead
of just letting random things fail.
--
Les Mikesell
lesmikesell(a)gmail.com
3:57 p.m.
New subject: Tried Pulse Audio Again--No Good For A11y
On Tue, 2008-09-23 at 15:50 -0500, Les Mikesell wrote:
But, if it can't be done right, the WM should enforce it and give
you a
choice of killing the old session when you attempt a new login instead
of just letting random things fail.
Have you actually tried it in F9 or F10 ? gdm doesn't let you log in
multiple times, it brings you back to your old session if you try.
5:37 p.m.
New subject: Tried Pulse Audio Again--No Good For A11y
Matthias Clasen wrote:
> But, if it can't be done right, the WM should enforce it and give you a
> choice of killing the old session when you attempt a new login instead
> of just letting random things fail.
Have you actually tried it in F9 or F10 ? gdm doesn't let you log in
multiple times, it brings you back to your old session if you try.
No I haven't. What does 'bring you back to your old session' mean when
your subsequent login is remote - or both were?
--
Les Mikesell
lesmikesell(a)gmail.com
6:15 p.m.
New subject: Tried Pulse Audio Again--No Good For A11y
On Tue, 23.09.08 16:57, Matthias Clasen (mclasen(a)redhat.com) wrote:
> But, if it can't be done right, the WM should enforce it and
give you a
> choice of killing the old session when you attempt a new login instead
> of just letting random things fail.
Have you actually tried it in F9 or F10 ? gdm doesn't let you log in
multiple times, it brings you back to your old session if you try.
Just wondering, do the other dm's do that too?
As it appears I have to support KDE/... with PA, too.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
4:03 p.m.
New subject: Tried Pulse Audio Again--No Good For A11y
On Tue, Sep 23, 2008 at 4:50 PM, Les Mikesell <lesmikesell(a)gmail.com> wrote:
Except I want my other logins to be from other places. Like one on the
console, one freenx/NX'd and floating, others xdm'd, perhaps Xnested.
There are two answers on remote login:
1) Unix shell over ssh - we're not breaking this, but it is what it is
2) Access currently logged in desktop over VNC/your-protocol-here via vino
Ideally vino would also allow you to dynamically enable remote new
logins over GDM/XDMCP though policykit.
But Xnest and console are broken and should not be supported except as
debugging/development tools.
5:34 p.m.
New subject: Tried Pulse Audio Again--No Good For A11y
Colin Walters wrote:
On Tue, Sep 23, 2008 at 4:50 PM, Les Mikesell
<lesmikesell(a)gmail.com> wrote:
> Except I want my other logins to be from other places. Like one on the
> console, one freenx/NX'd and floating, others xdm'd, perhaps Xnested.
There are two answers on remote login:
1) Unix shell over ssh - we're not breaking this, but it is what it is
2) Access currently logged in desktop over VNC/your-protocol-here via vino
freenx/NX is much, much nicer for remote access than vnc. Nice enough
to give up logging in directly on the console at all if that won't mesh
and you do anything from other locations.
Ideally vino would also allow you to dynamically enable remote new
logins over GDM/XDMCP though policykit.
I'd settle for yanking the running session to my new login location if
the desktop resized appropriately. I think vino/vnc's goal is
controlling remote session with the concept that there really are 2
copies of the session. I want to have a remote session that is not
necessarily a copy of another one running somewhere else. I realize
that freenx does in fact have a copy of the session tucked away
somewhere but it's not intrusive, doesn't tie up a physical console, and
isn't restricted to one user/session at a time on a machine. It is a
better fit for long-running sessions and mobile users than vino/vnc
where you have to start the session from a fixed console and
subsequently tie it up - and leave it open to intrusion, even when you
aren't there.
But Xnest and console are broken and should not be supported except
as
debugging/development tools.
I think of Xnest as a test like a compiler being able to compile itself.
If it doesn't work, there is something inherently wrong.
--
Les Mikesell
lesmikesell(a)gmail.com
6:54 p.m.
New subject: Tried Pulse Audio Again--No Good For A11y
On Tue, Sep 23, 2008 at 1:03 PM, Colin Walters <walters(a)verbum.org> wrote:
1) Unix shell over ssh - we're not breaking this, but it is what
it is
2) Access currently logged in desktop over VNC/your-protocol-here via vino
Correct me if I'm wrong. Does remote vnc access via vino wake up the
locally locked display still in F10? Is that okay from a security
perspective?
I don't know how to reconcile the security arguments being made for
pulseaudio with regard to disabling streams on console switching, with
the fact that our default remote desktop implementation as implemented
by vino wakes up the local console screen, even if its a locked
session, if you connect remotely to the desktop in F9. I feel there's
a disconnect here as to what a secure desktop experience is suppose to
be.
-jef"the disconnect could just be in my head"spaleta
7:37 p.m.
New subject: Tried Pulse Audio Again--No Good For A11y
Hi,
On Tue, Sep 23, 2008 at 7:54 PM, Jeff Spaleta <jspaleta(a)gmail.com> wrote:
Correct me if I'm wrong. Does remote vnc access via vino wake up
the
locally locked display still in F10?
You're not wrong, and it's not the desired behavior:
http://bugzilla.gnome.org/show_bug.cgi?id=311780
Just hard to fix and no one has spent time doing it yet.
--Ray
9:45 p.m.
New subject: Tried Pulse Audio Again--No Good For A11y
On Tue, Sep 23, 2008 at 4:37 PM, Ray Strode <halfline(a)gmail.com> wrote:
You're not wrong, and it's not the desired behavior:
http://bugzilla.gnome.org/show_bug.cgi?id=311780
Just hard to fix and no one has spent time doing it yet.
Excellent! I absolutely love it when I'm wrong!
-jef
6:34 p.m.
New subject: Tried Pulse Audio Again--No Good For A11y
On Tue, 23.09.08 15:50, Les Mikesell (lesmikesell(a)gmail.com) wrote:
>>>> As far as I know we again allow multiple simultaneous
X logins by the
>>>> same user.
>>> If we do, it's broken.
>> Why shouldn't I be able to do as many xdm logins as I want as the same
>> user? This isn't an X issue.
> Because many apps don't distuingish state from configuration cleanly.
So you'd cripple the system because there are some bad apps?
Oh my, Lennart cripples computers. I should be banned. Just like DRM!
> For example: you configure your gnome panel to include a clock
> applet. Then you open another session and add a network monitor applet
> to it. What do you expect from this? That both panels will always stay
> perfectly in sync and the network monitor applet is transparently
> added to the first session as well? When you log out from both, what
> happens when you log in again, do you get the panel layout from the
> first session or from the second session?
How is this different than running 2 instances of vi? If you edit the same
file at the same time you'll have a conflict. That doesn't mean you should
cripple the system to the point where it can't run 2 instances of
vi.
vi has static config files. They are only read on vi's startup.
OTOH GNOME usually does instant-apply. I.e. what you configure is
immediately executed and saved for later.
You did not respond to my question what you'd think the proper
behaviour would be for gnome-panel. I'll take that as an
acknowledgment that you understand that the problem exists.
> The question is: is it worth bothering at all with questions like
the
> panel question above? Since the feature is redundant we might simply
> say: forget it, let's disable multiple logins and the problem is
> gone.
Windows terminal services has gotten this more or less right since at least
windows 2000 server that included 2 licenses for administrative use. If
they can do it with an interface that wasn't designed to be remote or
multiuser, it can't be that hard.
Are you sure you can log in twice on Win2k as exactly the same user id?
But, if it can't be done right, the WM should enforce it and give
you a
choice of killing the old session when you attempt a new login instead of
just letting random things fail.
Nah, if at all that's the job of the dm or the sm, not the wm.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
7:38 p.m.
New subject: multiple local X logins by same user (was: Tried Pulse Audio Again--No Good For A11y)
Lennart Poettering wrote:
You did not respond to my question what you'd think the proper
behaviour would be for gnome-panel. I'll take that as an
acknowledgment that you understand that the problem exists.
I don't use gnome, but... I'd expect plasma (KDE's desktop container and
taskbar) to write its settings out when I apply changes. This should
either overwrite any other changes made to the file (a common behavior
when running multiple independent instances of a program) or else merge
the changes in a way that doesn't break the app the next time it starts
up (but is not necessarily required to have any "desired effect"; IMO
that's permissible for such a usage.)
Therefore, I don't consider that there is a significant "problem" here.
Ideally, updating the configuration would be atomic (this is probably
needed regardless, although you aren't likely to have race conditions
when talking about user settings) and would notify all instances to
re-read the configuration, but I don't consider this crucial.
> Windows terminal services has gotten this more or less right
since at least
> windows 2000 server that included 2 licenses for administrative use. If
> they can do it with an interface that wasn't designed to be remote or
> multiuser, it can't be that hard.
Are you sure you can log in twice on Win2k as exactly the same user id?
I don't know about w2k, but it works in 2k3 (I just tested). Two logins,
same user, different apps running. Wow, it's almost like having virtual
desktops! :-)
So, er... yeah. To throw in my $0.02, I don't see why this shouldn't be
permitted.
(Incidentally, Firefox drives me nuts not letting me run it on my local
login and via 'ssh -X' from a remote machine. Some apps are even worse
behaved than not coping with two full local X sessions as to go so far
as to not permit multiple instances to be run /at all/.)
On Tue, 23.09.08 15:50, Les Mikesell (lesmikesell(a)gmail.com) wrote:
> But, if it can't be done right, the WM should enforce it and give you a
> choice of killing the old session when you attempt a new login instead of
> just letting random things fail.
Nah, if at all that's the job of the dm or the sm, not the wm.
Er... I guess. I suppose the DM has to figure out how to start a second
X root session. Beyond that, apps that break when you try to run two
instances in multiple X sessions are, IMO, just plain buggy. It's
perfectly normal for me to run apps over remote X, and not uncommon to
want to run Xephyr sessions. I expect apps (and this includes WM's and
other desktop bits) to work just fine if I try to run multiple instances
in multiple X sessions, regardless of what kind of X session I'm trying
to run it in (local, nested, remote, headless*).
(* i.e. vncserver, or any others that use an offscreen buffer for X output)
--
Matthew
Igor Peshansky: Don't hippos love water even more than dogs?
Dave Korn: Don't ask me. I didn't even know that hippos loved dogs.
7:57 p.m.
New subject: multiple local X logins by same user (was: Tried Pulse Audio Again--No Good For A11y)
On Tue, Sep 23, 2008 at 8:38 PM, Matthew Woehlke
<mw_triad(a)users.sourceforge.net> wrote:
(Incidentally, Firefox drives me nuts not letting me run it on my local
login and via 'ssh -X' from a remote machine. Some apps are even worse
behaved than not coping with two full local X sessions as to go so far as to
not permit multiple instances to be run /at all/.)
Basically every nontrivial app doesn't support it, because it's just
too crazy. One could spend an entire lifespan trying to figure out
"Ok, what if I do *this*?". If you want to access your Firefox
instance remotely, use vino or one of the other systems that lets you
access your existing session. It works, and we can collectively move
on to more important problems.
9:26 p.m.
New subject: multiple local X logins by same user
Colin Walters wrote:
On Tue, Sep 23, 2008 at 8:38 PM, Matthew Woehlke
<mw_triad(a)users.sourceforge.net> wrote:
>
> (Incidentally, Firefox drives me nuts not letting me run it on my local
> login and via 'ssh -X' from a remote machine. Some apps are even worse
> behaved than not coping with two full local X sessions as to go so far as to
> not permit multiple instances to be run /at all/.)
Basically every nontrivial app doesn't support it, because it's just
too crazy. One could spend an entire lifespan trying to figure out
"Ok, what if I do *this*?". If you want to access your Firefox
instance remotely, use vino or one of the other systems that lets you
access your existing session. It works, and we can collectively move
on to more important problems.
What is more important than predicable behavior? Something very
different happens when you run firefox for the first time in a remote
window compared to when it is already running.
--
Les Mikesell
lesmikesell(a)gmail.com
11:29 a.m.
New subject: multiple local X logins by same user
Colin Walters wrote:
On Tue, Sep 23, 2008 at 8:38 PM, Matthew Woehlke
<mw_triad(a)users.sourceforge.net> wrote:
>
> (Incidentally, Firefox drives me nuts not letting me run it on my local
> login and via 'ssh -X' from a remote machine. Some apps are even worse
> behaved than not coping with two full local X sessions as to go so far as to
> not permit multiple instances to be run /at all/.)
Basically every nontrivial app doesn't support it, because it's just
too crazy.
Erm? Every app that supports running two simultaneous independent
instances (which is to say, 90% or more of all non-trivial apps) won't
even notice they aren't in the same X session. It's only "crazy" for
apps that go ridiculously out of their way to make sure there is only
ever one instance running on a machine. In fact, *other* than Firefox I
can't think of a single program that has this problem.
One could spend an entire lifespan trying to figure out
"Ok, what if I do *this*?". If you want to access your Firefox
instance remotely, use vino or one of the other systems that lets you
access your existing session.
I don't *want* to access my existing session. I want to start a second,
completely independent session^1. Firefox is nearly the only program I
can think of that doesn't let me do this.
(^1 I'll admit that I'd prefer one that won't hose state information
when I run it, which I suppose is the problem we were talking about.
Nevertheless, KDE applications don't seem to have a problem here, so
trying to argue that it's "hard" is obviously just an excuse. There's
all sorts of Free and proprietary software I could list that can run
independent instances without hosing their state. Usually the
last-running instance clobbers the state left by any others, which,
while perhaps not ideal, is certainly "good enough" in many cases^2.)
(^2 I will grant that "last state wins" may be unacceptable for things
like web browser history, which should be not only lossless but possibly
shared, but there are already good solutions for that (usually called
"databases"), and Firefox *is* using SQL these days...)
--
Matthew
I was recently amused by issuing 'rm -rf $KDEDIR'... from Konsole, while
in a KDE session. And nothing bad happened whatsoever. Try THAT on
Windows :-D.
12:04 p.m.
New subject: multiple local X logins by same user
On Wednesday 24 September 2008 17:29:20 Matthew Woehlke wrote:
I don't *want* to access my existing session. I want to start a
second,
completely independent session^1. Firefox is nearly the only program I
can think of that doesn't let me do this.
I put "firefox -Pfoo %u" in a panel icon, with different foo in different
places, and can start three different firefox instances (I have three screens,
and I often use them for different purposes e.g. if I need to log into our web
app under an admin and non-admin user ID at the same time ... this is extremely
useful for testing purposes).
It's kludgy, but it works. Perhaps even a script that created a profile based on
the display name? "firefox -Pprofile-%DISPLAY" might cut it, if anyone fancies
trying it.
12:59 p.m.
New subject: multiple local X logins by same user
(Please do not quote my e-mail address unobfuscated in message bodies.)
Bill Crawford wrote:
I put "firefox -Pfoo %u" in a panel icon, with different
foo in different
places, and can start three different firefox instances (I have three screens,
and I often use them for different purposes e.g. if I need to log into our web
app under an admin and non-admin user ID at the same time ... this is extremely
useful for testing purposes).
It's kludgy, but it works. Perhaps even a script that created a profile based on
the display name? "firefox -Pprofile-%DISPLAY" might cut it, if anyone fancies
trying it.
Ah, so it's a limitation of the profile support, then? I guess that
makes sense, though I still consider it a bug :-). Thanks for the tip,
though!
--
Matthew
I was recently amused by issuing 'rm -rf $KDEDIR'... from Konsole, while
in a KDE session. And nothing bad happened whatsoever. Try THAT on
Windows :-D.
12:22 p.m.
New subject: multiple local X logins by same user
Matthew Woehlke wrote:
Erm? Every app that supports running two simultaneous independent
instances (which is to say, 90% or more of all non-trivial apps) won't
even notice they aren't in the same X session. It's only "crazy" for
apps that go ridiculously out of their way to make sure there is only
ever one instance running on a machine. In fact, *other* than Firefox I
can't think of a single program that has this problem.
It probably does give an efficiency boost to have the running app open a
new window (although if that's what you wanted, you probably would have
told it to open a new window instead of starting a new instance...). I
suppose it's really for the automated startup when you click a link
embedded in some other app though. But while it is going ridiculously
out of it's way, you'd think it could check to see if the new invocation
you want is running on the same $DISPLAY as the running instance or not.
(^2 I will grant that "last state wins" may be unacceptable
for things
like web browser history, which should be not only lossless but possibly
shared, but there are already good solutions for that (usually called
"databases"), and Firefox *is* using SQL these days...)
Any number of apps have to deal with shared files, sometimes over networks.
--
Les Mikesell
lesmikesell(a)gmail.com
9:03 p.m.
New subject: Tried Pulse Audio Again--No Good For A11y
Lennart Poettering wrote:
>> For example: you configure your gnome panel to include a clock
>> applet. Then you open another session and add a network monitor applet
>> to it. What do you expect from this? That both panels will always stay
>> perfectly in sync and the network monitor applet is transparently
>> added to the first session as well? When you log out from both, what
>> happens when you log in again, do you get the panel layout from the
>> first session or from the second session?
> How is this different than running 2 instances of vi? If you edit the same
> file at the same time you'll have a conflict. That doesn't mean you should
> cripple the system to the point where it can't run 2 instances of
> vi.
vi has static config files. They are only read on vi's startup.
OTOH GNOME usually does instant-apply. I.e. what you configure is
immediately executed and saved for later.
I've always hated that. I've had horrible things happen when I change
layouts on a large screen and the next login is on a small one. Things
in general seem to resize better now so maybe it isn't as much of a
problem. Can you still make apps open with the borders you need to
resize them off the screen completely?
You did not respond to my question what you'd think the proper
behaviour would be for gnome-panel. I'll take that as an
acknowledgment that you understand that the problem exists.
My idea of proper behavior is to not change defaults unless I specify
that I want defaults changed. I suppose that doesn't mesh very well
with gnome concepts but just because I try something once on one monitor
does not mean I'll want it always or ever again. And in the context of
multiple sessions for the same user, that would mean the last save wins
as you expect for other files.
>> The question is: is it worth bothering at all with questions
like the
>> panel question above? Since the feature is redundant we might simply
>> say: forget it, let's disable multiple logins and the problem is
>> gone.
> Windows terminal services has gotten this more or less right since at least
> windows 2000 server that included 2 licenses for administrative use. If
> they can do it with an interface that wasn't designed to be remote or
> multiuser, it can't be that hard.
Are you sure you can log in twice on Win2k as exactly the same user id?
Yes, and you can be running the same apps in different-sized windows in
each. You only get terminal services in the server products but it is
done surprisingly well - current versions take sound along for the ride too.
> But, if it can't be done right, the WM should enforce it and
give you a
> choice of killing the old session when you attempt a new login instead of
> just letting random things fail.
Nah, if at all that's the job of the dm or the sm, not the wm.
Which has the restriction of not understanding multiple concurrent sessions?
--
Les Mikesell
lesmikesell(a)gmail.com
5:47 a.m.
New subject: Tried Pulse Audio Again--No Good For A11y
On Tue, 2008-09-23 at 21:03 -0500, Les Mikesell wrote:
Lennart Poettering wrote:
>
>>> For example: you configure your gnome panel to include a clock
>>> applet. Then you open another session and add a network monitor applet
>>> to it. What do you expect from this? That both panels will always stay
>>> perfectly in sync and the network monitor applet is transparently
>>> added to the first session as well? When you log out from both, what
>>> happens when you log in again, do you get the panel layout from the
>>> first session or from the second session?
>> How is this different than running 2 instances of vi? If you edit the same
>> file at the same time you'll have a conflict. That doesn't mean you
should
>> cripple the system to the point where it can't run 2 instances of
>> vi.
>
> vi has static config files. They are only read on vi's startup.
>
> OTOH GNOME usually does instant-apply. I.e. what you configure is
> immediately executed and saved for later.
I've always hated that. I've had horrible things happen when I change
layouts on a large screen and the next login is on a small one. Things
in general seem to resize better now so maybe it isn't as much of a
problem. Can you still make apps open with the borders you need to
resize them off the screen completely?
> You did not respond to my question what you'd think the proper
> behaviour would be for gnome-panel. I'll take that as an
> acknowledgment that you understand that the problem exists.
My idea of proper behavior is to not change defaults unless I specify
that I want defaults changed. I suppose that doesn't mesh very well
with gnome concepts but just because I try something once on one monitor
does not mean I'll want it always or ever again. And in the context of
multiple sessions for the same user, that would mean the last save wins
as you expect for other files.
>>> The question is: is it worth bothering at all with questions like the
>>> panel question above? Since the feature is redundant we might simply
>>> say: forget it, let's disable multiple logins and the problem is
>>> gone.
>> Windows terminal services has gotten this more or less right since at least
>> windows 2000 server that included 2 licenses for administrative use. If
>> they can do it with an interface that wasn't designed to be remote or
>> multiuser, it can't be that hard.
>
> Are you sure you can log in twice on Win2k as exactly the same user id?
Yes, and you can be running the same apps in different-sized windows in
each. You only get terminal services in the server products but it is
done surprisingly well - current versions take sound along for the ride too.
Are you sure? I was just watching somebody try to use RDP to a Windows
Server 2008 box this weekend and it blanked out the first login and only
allowed the second login direct access. I could be wrong and maybe he
configured it wrong, but I though Windows only allowed one _active_
login at a time, and suspended the other remote sessions.
Dan
1:35 p.m.
New subject: Tried Pulse Audio Again--No Good For A11y
Dan Williams wrote:
Are you sure? I was just watching somebody try to use RDP to a
Windows
Server 2008 box this weekend and it blanked out the first login and only
allowed the second login direct access. I could be wrong and maybe he
configured it wrong, but I though Windows only allowed one _active_
login at a time, and suspended the other remote sessions.
I fired up two instances of krdc (on separate monitors, great having
more than one ;-) ), logged into the same (W2k3) machine as the same
(local) user, started a Cygwin session on each, and ran:
$ for f in `seq 100 200` ; do sleep 0.1 ; echo $f ; done
(I used `seq 500 600` for the other one)
...and watched both of them spit out numbers at the same time. It's not
exactly full-motion video, but it was certainly timesharing two active
login sessions as the same user. I'm not sure what else you're looking
for, but it sure seems to me that it works just fine.
Oh, and I also fired up Xephyr, dropped an xterm in it, and ran
'startkde'... as I write this, I have two KDE desktop sessions running
(one nested) as the same user.
I have yet to see a single good reason (other than "because stripping
advanced functionality is the Gnome way") not to support multiple X
sessions as the same user.
--
Matthew
I was recently amused by issuing 'rm -rf $KDEDIR'... from Konsole, while
in a KDE session. And nothing bad happened whatsoever. Try THAT on
Windows :-D.
12:23 p.m.
New subject: Tried Pulse Audio Again--No Good For A11y
Les Mikesell wrote:
Can you still make apps open with the borders you need to
resize them off the screen completely?
If you need borders to resize a window, then you need a better WM :-).
Not that there's anything wrong with borders, but a good WM will protect
you from this case by providing keyboard shortcuts to begin a resize
(and allowing you to use the keyboard to actually resize the window), so
that you can still resize even if the borders /are/ off the screen.
Of course, a good WM will also not create windows with borders off the
screen, so... :-)
--
Matthew
I was recently amused by issuing 'rm -rf $KDEDIR'... from Konsole, while
in a KDE session. And nothing bad happened whatsoever. Try THAT on
Windows :-D.
9:47 a.m.
New subject: Tried Pulse Audio Again--No Good For A11y
Matthias Clasen writes:
On Tue, 2008-09-16 at 18:05 -0400, Janina Sajka wrote:
> Chuck Anderson writes:
> > On Tue, Sep 16, 2008 at 02:34:44PM -0400, Janina Sajka wrote:
> > > 5.) While I paplay, I try to go Ctrl-Alt-F1. While I'm not prevented
> > > from doing so, paplay believes it should pause playing while I'm away
> > > from the gui tty. Now, who's the genius that figured out this
"feature?"
> >
> > That's ConsoleKit deactivating the streams on the non-active console.
> > This is so mult-user-switching can work and each user can have their
> > own audio.
> >
> OK. Thanks for the explanation.
>
> So, the concept limits audio to a single console, even if the same user
> is logged in somewhere else? I guess running pa as a systen daemon would
> not exhibit this behavior?
>
Actually, Lennart changed PA to not be strictly per-session, but
per-user, I think. But I don't know the details of how that works.
I also thought it was per user, but I got the same pause behavior even
after I logged in on Ctrl+Alt+F1, as I recall.
I've looked into your 'login screen ready' sound problem,
and found that
it doesn't work atm due to a pulseaudio bug:
https://bugzilla.redhat.com/show_bug.cgi?id=462537
Thanks for filing this one.
PS: IMHO, it would be worth the extra effort to clear this and the
associated issues as discussed upstream:
http://mail.gnome.org/archives/gdm-list/2008-September/msg00015.html
in time for the next spin of RHEL. The Linux desktop, with orca, gok,
and dasher as builtin AT, plus the solid support for a11y in Firefox 3
and Open Office 3 should finally make Linux a serious contender for U.S.
Government desktop sales under Sec. 508--something that hasn't been
there before.
Janina
Matthias
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
--
Janina Sajka, Phone: +1.202.595.7777; sip:janina@a11y.org
Partner, Capital Accessibility LLC http://CapitalAccessibility.Com
Marketing the Owasys 22C talking screenless cell phone in the U.S. and Canada
Learn more at http://ScreenlessPhone.Com
Chair, Open Accessibility janina(a)a11y.org
Linux Foundation http://a11y.org
7:05 p.m.
New subject: Tried Pulse Audio Again--No Good For A11y
On Tue, 16.09.08 20:40, Matthias Clasen (mclasen(a)redhat.com) wrote:
On Tue, 2008-09-16 at 18:05 -0400, Janina Sajka wrote:
> Chuck Anderson writes:
> > On Tue, Sep 16, 2008 at 02:34:44PM -0400, Janina Sajka wrote:
> > > 5.) While I paplay, I try to go Ctrl-Alt-F1. While I'm not prevented
> > > from doing so, paplay believes it should pause playing while I'm away
> > > from the gui tty. Now, who's the genius that figured out this
"feature?"
> >
> > That's ConsoleKit deactivating the streams on the non-active console.
> > This is so mult-user-switching can work and each user can have their
> > own audio.
> >
> OK. Thanks for the explanation.
>
> So, the concept limits audio to a single console, even if the same user
> is logged in somewhere else? I guess running pa as a systen daemon would
> not exhibit this behavior?
>
Actually, Lennart changed PA to not be strictly per-session, but
per-user, I think. But I don't know the details of how that works.
This is corrrect.
We spawn at most one PA instance per-machine/per-homedir. All sessions
that come and go share it. When the last session of a user terminates
and some timeout elapsed PA will terminate itself again.
I've looked into your 'login screen ready' sound problem,
and found that
it doesn't work atm due to a pulseaudio bug:
https://bugzilla.redhat.com/show_bug.cgi?id=462537
I belive this is more of a gdm bug, though. ;-)
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
7:03 p.m.
New subject: Tried Pulse Audio Again--No Good For A11y
On Tue, 16.09.08 18:05, Janina Sajka (janina(a)rednote.net) wrote:
Chuck Anderson writes:
> On Tue, Sep 16, 2008 at 02:34:44PM -0400, Janina Sajka wrote:
> > 5.) While I paplay, I try to go Ctrl-Alt-F1. While I'm not prevented
> > from doing so, paplay believes it should pause playing while I'm away
> > from the gui tty. Now, who's the genius that figured out this
"feature?"
>
> That's ConsoleKit deactivating the streams on the non-active console.
> This is so mult-user-switching can work and each user can have their
> own audio.
>
OK. Thanks for the explanation.
So, the concept limits audio to a single console, even if the same user
is logged in somewhere else? I guess running pa as a systen daemon would
not exhibit this behavior?
Every session owned by the same user will share a single PA
instance. As long as you switch bac and force from/to sessions owned
by the same user audio will not be suspended.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
6:57 p.m.
New subject: Tried Pulse Audio Again--No Good For A11y
On Tue, 16.09.08 14:34, Janina Sajka (janina(a)rednote.net) wrote:
3.) Logging in I hear first the GDM "audio logo," think
I'll call it
an earcon from now on. But, Orca launches in my secondary audio device.
That's inappropriate, but I have no way to control that except to unplug
my secondary and tertiary audio devices and start over.
In udev times ALSA devices don't have any particular order
anymore. Which one you consider "primary", "secondary" or
"tertiary"
is known to you, but Linux doesn't know about that. Nowadays the
indexes of ALSA sound cards depend on the initialization order of the
drivers. Those drivers are now usually initialized in parallel which
hence results in different orders at each boot.
PA completely ignores alsa device indexes. Instead it uses HAL UDIs
for identifiying devices, which is much more useful. When PA is first
started up and no default audio device is configured, then PA will
pick one. It is not defined which one it will pick, and as it appears
it picked the wrong one for you.
After login you can change the default device by right-clicking on it
in paucontrol. However, that setting is per-user, so it won't have any
effect on gdm.
I thought of writing a small module for PA which in the case that no
default device is configured will try some heuristic to find a
suitable default (i.e. prefer PCI over USB over Bluetooth cards). Not
sure this would fully fix your problem though.
4.) Logging back in with only one audio device on board, Orca does
indeed startup on that device--but it seems I have to choose between
Orca and playing other audio. How quaint! I thought we got past this
silly "one sound at a time" view back around alsa-0.9. Does anyone
recall the alsa FAQ used to claim this was appropriate back then?
I don't know how orca is configured. If it is a well behaving ALSA
client it should connect to the device called "default" which will
then result in a connection to PA. However, if it is a badly behaving
ALSA client and hardcodes device strings such as "hw:0" then orca
needs fixing.
Well, it still isn't appropriate, but that's what's
happening. If I
paplay some .wav from a Gnome-Terminal, then attempt to go somewhere off
my Alt-F1 (Applications) menu--there's no Orca until my .wav ends. I
guess it would be like the screen blanking while the cd audio disc
plays? Very curious, indeed.
This is intended behaviour. We will pause audio for inactive
sessions, to make sure that other users cannot eavesdrop on you when
they take over the active session.
5.) While I paplay, I try to go Ctrl-Alt-F1. While I'm not
prevented
from doing so, paplay believes it should pause playing while I'm away
from the gui tty. Now, who's the genius that figured out this
"feature?"
I did. And it actually is a feature. It fixes a long standing security
issue.
As long as you switch from/to sessions that are owned by the same user
audio stays on. We only suspend audio if you switch to a session owned
by a different user.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
7:21 p.m.
New subject: Tried Pulse Audio Again--No Good For A11y
On Tue, Sep 23, 2008 at 01:57:31AM +0200, Lennart Poettering wrote:
PA completely ignores alsa device indexes. Instead it uses HAL UDIs
for identifiying devices, which is much more useful. When PA is first
started up and no default audio device is configured, then PA will
pick one. It is not defined which one it will pick, and as it appears
it picked the wrong one for you.
After login you can change the default device by right-clicking on it
in paucontrol. However, that setting is per-user, so it won't have any
effect on gdm.
I thought of writing a small module for PA which in the case that no
default device is configured will try some heuristic to find a
suitable default (i.e. prefer PCI over USB over Bluetooth cards). Not
sure this would fully fix your problem though.
This may be a crazy idea--but why don't we just make the default
output device "all devices"--copy the audio streams to every device
until the user selects a specific device as the default. This would
neatly solve the issue in this thread as well as other peoples'
confusion of "why do I have no sound" when the sound is being directed
to a card without any speakers attached.
There should be a way to override this system-wide default as well.
Alternatively, perhaps hal-based quirks can specify the
system-specific default sound output device. e.g. for laptops or
desktop models the built-in soundcard would be a sane default. If
there is no hal quirk for the current system, you could fall back to
"all output devices" or the heuristics you describe above.
Basically:
1. system factory default: output to all sound cards simultaneously
2. system custom default: either hal-quirk based, heuristic-based, or
set by sysadmin.
3. per user setting: as we have now, per user default output device
setting.
7:32 p.m.
New subject: Tried Pulse Audio Again--No Good For A11y
On Mon, 22.09.08 20:21, Chuck Anderson (cra(a)WPI.EDU) wrote:
On Tue, Sep 23, 2008 at 01:57:31AM +0200, Lennart Poettering wrote:
> PA completely ignores alsa device indexes. Instead it uses HAL UDIs
> for identifiying devices, which is much more useful. When PA is first
> started up and no default audio device is configured, then PA will
> pick one. It is not defined which one it will pick, and as it appears
> it picked the wrong one for you.
>
> After login you can change the default device by right-clicking on it
> in paucontrol. However, that setting is per-user, so it won't have any
> effect on gdm.
>
> I thought of writing a small module for PA which in the case that no
> default device is configured will try some heuristic to find a
> suitable default (i.e. prefer PCI over USB over Bluetooth cards). Not
> sure this would fully fix your problem though.
This may be a crazy idea--but why don't we just make the default
output device "all devices"--copy the audio streams to every device
until the user selects a specific device as the default. This would
neatly solve the issue in this thread as well as other peoples'
confusion of "why do I have no sound" when the sound is being directed
to a card without any speakers attached.
Unfortunately doing this will substantially increase CPU load (because
we need to resample the streams for each of the devcies with a
slightly different sample rate and people are already complaining if
we do this for just a single stream...) and also practically disable
glitch-free audio. I.e. all the power savings are gone. Not a good
choice for a default.
There has been some work on adding SSE support to the
resampler. That's a step in the right direction. Maybe we can do what
you suggest some time in he future, but right now people would
probably just cry and call PA a teribble CPU hogger once more ;-)
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
11:35 p.m.
New subject: Tried Pulse Audio Again--No Good For A11y
On Mon, Sep 22, 2008 at 7:57 PM, Lennart Poettering
<mzerqung(a)0pointer.de> wrote:
[snip]
> 5.) While I paplay, I try to go Ctrl-Alt-F1. While I'm not
prevented
> from doing so, paplay believes it should pause playing while I'm away
> from the gui tty. Now, who's the genius that figured out this
> "feature?"
I did. And it actually is a feature. It fixes a long standing security
issue.
[snip]
I'm missing how write access (as opposed to read/recording) to an
audio device creates a material security vulnerability. It seems that
the majority of the complaints are that playback stops and that it
surprises the user. Recording stopping may also be surprising, but
it's easy to explain the security argument there.
If the answer is "differentiating read and write access is hard/not
possible with the current API" then thats what it is, but simply
blaming security is going to baffle people.
7:59 a.m.
New subject: Tried Pulse Audio Again--No Good For A11y
On Tue, 23.09.08 00:35, Gregory Maxwell (gmaxwell(a)gmail.com) wrote:
>> 5.) While I paplay, I try to go Ctrl-Alt-F1. While I'm
not prevented
>> from doing so, paplay believes it should pause playing while I'm away
>> from the gui tty. Now, who's the genius that figured out this
>> "feature?"
>
> I did. And it actually is a feature. It fixes a long standing security
> issue.
[snip]
I'm missing how write access (as opposed to read/recording) to an
audio device creates a material security vulnerability. It seems that
the majority of the complaints are that playback stops and that it
surprises the user. Recording stopping may also be surprising, but
it's easy to explain the security argument there.
It's true that being able to eavesdrop in your record streams is a
bigger security hole than just eavesdropping what you play. Nonethless
it's still a hole: they'd still be able to listen to one direction of
your voip call, and they'd still be able to play a fake stream that
you might then end up trusting.
We already had this discussion here twice or more times. I do believe
the right way is to suspend audio when we switch sessions by
default. I also acknowledge that it is valid for users to put security
second and have audio continue to play. In fact and as I already
mentioned, I have this on my TODO list, but way down.
I am always happy to take patches BTW. If this feature is important to
you the best thing to make it happen is actually write the code
yourself!
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
5:02 p.m.
On Mon, 2008-09-15 at 16:59 +0200, Ralf Corsepius wrote:
I regret having to state this, but I have been thinking Fedora has
quit
being a "general purpose distro" for quite a while.
More to the point, the only large active group trying to move things
forward for Fedora are those that care about the Desktop experience,
ergo those are the directions Fedora is going in. It's a serve yourself
kind of project, it is what you make of it.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
5:16 p.m.
Jesse Keating wrote:
On Mon, 2008-09-15 at 16:59 +0200, Ralf Corsepius wrote:
> I regret having to state this, but I have been thinking Fedora has quit
> being a "general purpose distro" for quite a while.
More to the point, the only large active group trying to move things
forward for Fedora are those that care about the Desktop experience,
ergo those are the directions Fedora is going in. It's a serve yourself
kind of project, it is what you make of it.
I don't think you can call it 'moving forward' if it breaks the things
that have been the most useful about Linux so far.
--
Les Mikesell
lesmikesell(a)gmail.com
2:35 a.m.
Le Mar 16 septembre 2008 00:16, Les Mikesell a écrit :
Jesse Keating wrote:
> On Mon, 2008-09-15 at 16:59 +0200, Ralf Corsepius wrote:
>> I regret having to state this, but I have been thinking Fedora has
>> quit
>> being a "general purpose distro" for quite a while.
>
> More to the point, the only large active group trying to move things
> forward for Fedora are those that care about the Desktop experience,
> ergo those are the directions Fedora is going in. It's a serve
> yourself
> kind of project, it is what you make of it.
I don't think you can call it 'moving forward' if it breaks the things
that have been the most useful about Linux so far.
Nevertheless this group tries at least to do stuff, and the
counter-proposals are too often "do nothing".
--
Nicolas Mailhot
4:45 a.m.
On Tue, 2008-09-16 at 09:35 +0200, Nicolas Mailhot wrote:
Le Mar 16 septembre 2008 00:16, Les Mikesell a écrit :
>
> Jesse Keating wrote:
>> On Mon, 2008-09-15 at 16:59 +0200, Ralf Corsepius wrote:
>>> I regret having to state this, but I have been thinking Fedora has
>>> quit
>>> being a "general purpose distro" for quite a while.
>>
>> More to the point, the only large active group trying to move things
>> forward for Fedora are those that care about the Desktop experience,
>> ergo those are the directions Fedora is going in. It's a serve
>> yourself
>> kind of project, it is what you make of it.
>
> I don't think you can call it 'moving forward' if it breaks the things
> that have been the most useful about Linux so far.
Nevertheless this group tries at least to do stuff, and the
counter-proposals are too often "do nothing".
Generally speaking, not referring to your proposal, these counter
proposals/critical remarks often are motivated from
a) Don't break what's not broken
b) A proposal is incomplete and misses to cover essential parts of a
problem.
c) A proposal is replacing one problem with another one.
d) A proposal is naive, silly and dumb.
In most cases, it's b) or c).
8:30 p.m.
On Mon, 2008-09-15 at 15:02 -0700, Jesse Keating wrote:
On Mon, 2008-09-15 at 16:59 +0200, Ralf Corsepius wrote:
> I regret having to state this, but I have been thinking Fedora has quit
> being a "general purpose distro" for quite a while.
More to the point, the only large active group trying to move things
forward for Fedora are those that care about the Desktop experience,
ergo those are the directions Fedora is going in. It's a serve yourself
kind of project, it is what you make of it.
I think you're begging the question.
Ralf is saying that the changes the desktop teams wants to make are not
FORWARD. They are in a direction that is sub-optimal for various things.
And to be fair a lot of other people who do things with fedora don't
require large changes for that to happen. The folks providing functional
daemons, for example, they don't need much more than a quasi-stable base
to run on.
-sv
10:14 p.m.
On Mon, 2008-09-15 at 21:30 -0400, Seth Vidal wrote:
On Mon, 2008-09-15 at 15:02 -0700, Jesse Keating wrote:
> On Mon, 2008-09-15 at 16:59 +0200, Ralf Corsepius wrote:
> > I regret having to state this, but I have been thinking Fedora has quit
> > being a "general purpose distro" for quite a while.
>
> More to the point, the only large active group trying to move things
> forward for Fedora are those that care about the Desktop experience,
> ergo those are the directions Fedora is going in. It's a serve yourself
> kind of project, it is what you make of it.
>
I think you're begging the question.
Ralf is saying that the changes the desktop teams wants to make are not
FORWARD.
Correct.
They are in a direction that is sub-optimal for various things.
Also correct.
And to be fair a lot of other people who do things with fedora
don't
require large changes for that to happen. The folks providing functional
daemons, for example, they don't need much more than a quasi-stable base
to run on.
Exactly.
At least I would not complain, if things "just worked". Unfortunately
this doesn't apply. With each Fedora release, I experience things which
are advertised as "revolutionary new features/great achievements" to
actually worsen my use-cases. Often this is presumably because these new
developments did not take into account certain setups'/use-cases'
requirements and likely had been designed on single-user-desktops.
Ralf
3:49 a.m.
On Mon, Sep 15, 2008 at 09:30:52PM -0400, Seth Vidal wrote:
Ralf is saying that the changes the desktop teams wants to make are
not
FORWARD. They are in a direction that is sub-optimal for various things.
And to be fair a lot of other people who do things with fedora don't
require large changes for that to happen. The folks providing functional
daemons, for example, they don't need much more than a quasi-stable base
to run on.
Yes. Sane development = Evolution, not revolution.
Karel
--
Karel Zak <kzak(a)redhat.com>
7:48 a.m.
On Tue, 2008-09-16 at 10:49 +0200, Karel Zak wrote:
On Mon, Sep 15, 2008 at 09:30:52PM -0400, Seth Vidal wrote:
> Ralf is saying that the changes the desktop teams wants to make are not
> FORWARD. They are in a direction that is sub-optimal for various things.
>
> And to be fair a lot of other people who do things with fedora don't
> require large changes for that to happen. The folks providing functional
> daemons, for example, they don't need much more than a quasi-stable base
> to run on.
Yes. Sane development = Evolution, not revolution.
Yes and we've gotten everywhere via evolutionary steps.
Revolutions just piss people off and get people killed.
-sv
9:56 p.m.
On Mon, 2008-09-15 at 15:02 -0700, Jesse Keating wrote:
On Mon, 2008-09-15 at 16:59 +0200, Ralf Corsepius wrote:
> I regret having to state this, but I have been thinking Fedora has quit
> being a "general purpose distro" for quite a while.
More to the point, the only large active group trying to move things
forward for Fedora are those that care about the Desktop experience,
ergo those are the directions Fedora is going in. It's a serve yourself
kind of project, it is what you make of it.
My view is different:
Due to the fact the number of desktop use-cases likely by way outweighs
the number of non-desktop use-cases, has caused the Fedora distribution
to get infected with designs missing (rsp. ignoring) the demands of
non-desktop uses-cases.
Overall this has caused the Fedora distro to regress/derail from what
once used to be a "general multipurpose distro" into a "single-user
desktop distro".
Ralf
3:42 a.m.
On Mon, Sep 15, 2008 at 03:02:42PM -0700, Jesse Keating wrote:
More to the point, the only large active group trying to move things
forward for Fedora are those that care about the Desktop experience,
I guess that the large group of kernel, tools and base-os people are
very happy to see this conclusion. So.. thanks! :-((
BTW, invisible != inactive.
Karel
--
Karel Zak <kzak(a)redhat.com>
2:10 p.m.
Dmitry Butskoy wrote:
> Probably, because most console users already quit using Fedora,
+1.
And situation is worse than simply loss of a rare segment of the market.
Who are "console users"? Most cases they are users who began for a long
time ago (when GUI was either poor or unavailable).
Users whose main (only) purpose for the machine is to provide network
services and there is little or no direct console use (firewall, router,
file/email/web/database server, media player etc.). That is, most of
the things computers are good at.
Lacking such "long
time ago" users, we lack all their skills, knowledge, intuition. And as
begun for a long time, many of them have already made their career, and
even make decisions now. Decisions not for Fedora.
Fedora's direction makes it not particularly suited for production
services, but...
Anyway, while Fedora is (still) considered as "general purpose
disto",
it should has console.
If you are going to do development/testing work for something to be
matched and ready for the 'next' version of enterprise distributions,
what OS should you use if not fedora?
--
Les Mikesell
lesmikesell(a)gmail.com
9:22 a.m.
Le Lun 15 septembre 2008 15:39, Denis Leroy a écrit :
Nicolas Mailhot wrote:
> Simply put, non-X-console input is a mess (X input is a mess too
but
> at least there are people trying to fix it), non-X-console font
> support has fossilized, and support for modern high resolution
> screens
> is severely lacking.
>
> The console has not evolved for a long time, while text requirements
> have gone up. At this point a dumbed down text-only X session is
> probably the only credible console future (or something that is not
> X
> at all but uses many libraries we associate with apps now).
>
> Non-X-console state is so bad nowadays I don't bother reporting bugs
> on it. Even if they are fixed they always reappear the next Fedora
> cycle.
Well, people can log in, and people can run commands. As long as that
works, where's the problem ? I understand support for foreign
characters
is going to be a problem, but how does that justify removing the
entire thing ?
Keeping this stuff alive is not free you know.
Displaying boot messages properly or doing a VT switch does not work
completely on my rawhide box right now. And no one decided to break
it. It just rotted away.
> There is simply not enough console users [cut] to do anything
but
> life support anymore.
On what facts do you base that opinion ?
On my experience of xkb layout maintainer for my language, kbd
maintainer for my language, main animator of the Fedora fonts SIG,
regular console user, etc.
Text support is hard. Text support requires ongoing maintenance (even
at iso-functionnality). Our GUI environment has gotten good enough
people that used to do console maintenance have less and less
incentive to do so, and as a result the console is slowly rotting
(ascii-only text + qwerty is easier and not exhibiting a lot of rot so
far, but that's only a question of time). Even hardcore kernel devs
will tell you to just use and xterm instead of bothering with console
problems nowadays.
The situation won't get better untill a lot more of the software stack
is shared between Xorg and the console.
--
Nicolas Mailhot
10:17 a.m.
On Mon, 2008-09-15 at 16:22 +0200, Nicolas Mailhot wrote:
Text support is hard. Text support requires ongoing maintenance
(even
at iso-functionnality). Our GUI environment has gotten good enough
people that used to do console maintenance have less and less
incentive to do so,
Rubbish - You are comparing apples and oranges.
Using consoles has completely different use-cases than desktops. This
thought might be incomprehensible news to kids who grew up with Windows,
but ...
and as a result the console is slowly rotting
(ascii-only text + qwerty is easier and not exhibiting a lot of rot so
far, but that's only a question of time). Even hardcore kernel devs
will tell you to just use and xterm instead of bothering with console
problems nowadays.
Of cause it's more convenient to use an xterm than a
console. But this
already had been the case 20 years ago - it doesn't invalidate reasons
for using consoles.
Ralf
10:28 a.m.
Le Lun 15 septembre 2008 17:17, Ralf Corsepius a écrit :
On Mon, 2008-09-15 at 16:22 +0200, Nicolas Mailhot wrote:
> Text support is hard. Text support requires ongoing maintenance
> (even
> at iso-functionnality). Our GUI environment has gotten good enough
> people that used to do console maintenance have less and less
> incentive to do so,
Rubbish - You are comparing apples and oranges.
Using consoles has completely different use-cases than desktops.
Ability to use the keyboard properly, to display the system text
documents, or use the local screen is the same.
I'm not complaining the console is lacking fancy GL acceleration. I'm
complaining the console is sucking more and more at text which is sort
of the console point.
This
thought might be incomprehensible news to kids who grew up with
Windows,
The argument being?
Of cause it's more convenient to use an xterm than a console. But
this
already had been the case 20 years ago - it doesn't invalidate reasons
for using consoles.
It does if the gap between them continues to grow.
--
Nicolas Mailhot
4:04 p.m.
Denis Leroy <denis(a)poolshark.org> writes:
I occasionally run into a Gnome app bug where drag'n'drop
"hangs" the
desktop (the "drag" never "drops", sort of) where the only way out
is
ctrl-alt-f1 to mingetty and killall the user-space app. Without
mingetty, ctrl-alt-del is the only other option (i.e. loose all
unsaved documents).
ctrl-alt-f1 is iffy on a lot of machines. Sometimes you need a reboot
to get back to X. Having the kernel involved in the whole affair has a
somewhat better chance of working. Well that or we might get a Linus
rant; that often gets things fixed a bit faster.
No, I haven't filed bugs for that. Sorry. I prefer to file bugs for
problems I can reliably reproduce; at least then I have a chance to
keep the bug open when the system tries to close it after the next
Fedora release.
/Benny
5:47 p.m.
On Tue, Sep 16, 2008 at 4:04 PM, Benny Amorsen <benny+usenet(a)amorsen.dk> wrote:
Denis Leroy <denis(a)poolshark.org> writes:
ctrl-alt-f1 is iffy on a lot of machines. Sometimes you need a reboot
to get back to X. Having the kernel involved in the whole affair has a
somewhat better chance of working. Well that or we might get a Linus
rant; that often gets things fixed a bit faster.
What machine is that? I've been installing Redhat/Fedora/Centos since
2003, not that long, but I have never seen Ctrl+Alt+F1 be iffy
--
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )
5:57 p.m.
Arthur Pemberton wrote:
On Tue, Sep 16, 2008 at 4:04 PM, Benny Amorsen
<benny+usenet(a)amorsen.dk> wrote:
> Denis Leroy <denis(a)poolshark.org> writes:
> ctrl-alt-f1 is iffy on a lot of machines. Sometimes you need a reboot
> to get back to X. Having the kernel involved in the whole affair has a
> somewhat better chance of working. Well that or we might get a Linus
> rant; that often gets things fixed a bit faster.
What machine is that? I've been installing Redhat/Fedora/Centos since
2003, not that long, but I have never seen Ctrl+Alt+F1 be iffy
It is not hardware specific. If you do that often enough, you will
probably hit it sometime or the other. It is not easily reproducible
however.
Rahul
6:32 p.m.
On Wed, Sep 17, 2008 at 04:27:38AM +0530, Rahul Sundaram wrote:
It is not hardware specific. If you do that often enough, you will
That I doubt.
probably hit it sometime or the other. It is not easily reproducible
however.
The mode switch logic is driver specific so would be hardware specific in X
6:35 p.m.
Alan Cox wrote:
On Wed, Sep 17, 2008 at 04:27:38AM +0530, Rahul Sundaram wrote:
> It is not hardware specific. If you do that often enough, you will
That I doubt.
> probably hit it sometime or the other. It is not easily reproducible
> however.
The mode switch logic is driver specific so would be hardware specific in X
Yes, I wasn't very clear. What I meant was it occurs in many systems
rather than being limited to one particular hardware.
Rahul
6:24 p.m.
On Tue, Sep 16, 2008 at 11:04:39PM +0200, Benny Amorsen wrote:
ctrl-alt-f1 is iffy on a lot of machines. Sometimes you need a
reboot
to get back to X. Having the kernel involved in the whole affair has a
That would be an X bug. X handles all the mode switching logic for this
stuff. There are good reasons to get the kernel involved these days (for one
we've gone from fifty or more vendors down to about five of any relevance
and they tend to use sensible means for mode switching) but it won't really
change any reliability in that area.
What it will help with is stuff like recovering from an X crash, implementing
full SAK support and oops display.
9:26 a.m.
Nicolas Mailhot wrote:
Simply put, non-X-console input is a mess (X input is a mess too but
at least there are people trying to fix it), non-X-console font
support has fossilized, and support for modern high resolution screens
is severely lacking.
Me and some people around me use console often enough. Perhaps just by
habits. Including a habit to "a bigger letter", "less colors",
"still
old monitors", "still wild country" etc.
There is only one big font issue for me, introduced since RHL8 -- switch
to 512-glyphs default console font (latarcyrheb). Such a font (when >
256 glyphs) leads to lack of some console colors. (The solution is to
use another console fonts, which are always present in system).
The console has not evolved for a long time,
Perhaps all the efforts was focused on GUI (to reach windoze etc.), but
this does not mean that console (as well as "classical" cmdline
interface) is an unneeded thing to be supported in a general purpose
distro...
Non-X-console state is so bad nowadays I don't bother reporting
bugs
on it.
Sad.
There is simply not enough console users and console
developpers to do anything but life support anymore.
At least 50% of my time is at console, not at X. I would not wish to
explain why I (still) use console and why, using it, I am not an idiot.
But I use it, hence I can help...
IMHO, the "not enough console users" is true for the current Fedora
environment, but not true *in general*. Considering (simplifying) Fedora
as RedHat employees (focused on GUI for market reasons) plus young
enthusiasts (who started their life from GUI), we see why we lack
console for now.
~buc
http://www.fedoraproject.org/wiki/DmitryButskoy
9:40 a.m.
Le Lun 15 septembre 2008 16:26, Dmitry Butskoy a écrit :
Nicolas Mailhot wrote:
> There is simply not enough console users and console
> developpers to do anything but life support anymore.
>
At least 50% of my time is at console, not at X. I would not wish to
explain why I (still) use console and why, using it, I am not an
idiot.
I spend much of my time on the console... the X terminal+ssh one. The
non-X terminal one is a waste of my time.
Please do not take anything I wrote as an attack on the CLI
usefulness. It isn't. I'm complaining of the state of the console
software stack, not on the CLI in general.
But I use it, hence I can help...
IMHO, the "not enough console users" is true for the current Fedora
environment, but not true *in general*.
The problem is that the population that runs Fedora is highly more
susceptible to fix problems that the population that does not run
Fedora (and tends to wait for someone else to do the work).
The non-Fedora population is the one that was happy with OSS and did
nothing with it (and as a result it got dumped for alsa by the people
who were doing the work).
--
Nicolas Mailhot
11:16 a.m.
Nicolas Mailhot wrote:
And that's ok. Do remember that X was defined at a time hardware
was
vastly less powerful and core X is not wasteful at all. Compared to
how the rest of the system has bloated, X is definitely lean and mean.
I agree with that point. Does an X-based mingetty replacement actually
exists ? Something that's proven to be sufficiently fail-safe (will work
even with half-broken X configurations and such?).
12:38 p.m.
Le lundi 15 septembre 2008 à 18:16 +0200, Denis Leroy a écrit :
Nicolas Mailhot wrote:
> And that's ok. Do remember that X was defined at a time hardware was
> vastly less powerful and core X is not wasteful at all. Compared to
> how the rest of the system has bloated, X is definitely lean and mean.
I agree with that point. Does an X-based mingetty replacement actually
exists ? Something that's proven to be sufficiently fail-safe (will work
even with half-broken X configurations and such?).
I suspect that as soon as much of the hardware pocking is moved from
xorg to the kernel and X can be run as a normal user "X-based mingetty
replacement" will be just running a x term fullscreen in an
autoconfigured X instance.
Of course one could theorically write a much lighter solution using only
freetype (cairo, pango?) and an xkb-config parser
--
Nicolas Mailhot
12:57 p.m.
Denis Leroy wrote:
Nicolas Mailhot wrote:
> And that's ok. Do remember that X was defined at a time hardware was
> vastly less powerful and core X is not wasteful at all. Compared to
> how the rest of the system has bloated, X is definitely lean and mean.
I agree with that point. Does an X-based mingetty replacement actually
exists ? Something that's proven to be sufficiently fail-safe (will work
even with half-broken X configurations and such?).
This is getting really confusing.
There will NEVER be a "X-based mingetty replacement". At least because
mingetty is "_MINIMAL_ getty for consoles".
Having to run X (and you know... it won't start with less then 256M ram)
on every machine with Fedora is a real problem.
For example on the desktop I'm writing from (and I'm sure not only here)
X is always high in top with both CPU and memory usage, it's the most
frequently crashing/freezing part of the system. And I don't think it
will ever change. You know, X is doing a really complex job.
Input/output devices, resolution changing, 3D acceleration, broken
games... They will always cause problems. I don't think it's possible to
create fail-safe X.
Having this problems on a machine which will never benefit from X, is a
rel problem.
On the other hand I rarely see mingetty sessions crash. And if
mingetty+bash+mc+gpm is more than enough for a system, having a full X
stack running on it is overkill (or stupid).
There are a lot of people in the community pushing really hard to make
Fedora a "Desktop OS", "desktop product". These people must understand
that their desktop isn't the only (and I hope not even the most
important) place Fedora is supposed to run. I personally run it on a
desktop a laptop and 6 servers. I like NetworkManager running on the
laptop. It makes switching from network to network very easy, it works
perfectly with wireless networks. But NetworkManager enabled by default
on a server I install is really confusing. It makes my (professional)
life harder. If we continue making power users'/administrators' life
harder while we try to be more "user-friendly" (and by user we always
think Joe-clueless) we will loose them. And this special kind of users
are the most important (correct me if I'm wrong) for Free Software.
And I would like to thank You for Your time if You managed to read till
here :)
4:13 p.m.
Suren Karapetyan <surenkarapetyan(a)gmail.com> writes:
Having to run X (and you know... it won't start with less then
256M
ram) on every machine with Fedora is a real problem.
The Nokia 770 runs X. Back in the day, 8MB 486's ran X. Heck, Sun 5-60's
(68020's with 6MB of memory) ran X quite nicely. When you see X in
"top", a lot of its memory use is actually graphics card memory.
An X solution is not impossible. I'm not saying it's the answer, but
you can't rule it out like that.
/Benny
5:57 p.m.
On Tue, 2008-09-16 at 23:13 +0200, Benny Amorsen wrote:
Suren Karapetyan <surenkarapetyan(a)gmail.com> writes:
> Having to run X (and you know... it won't start with less then 256M
> ram) on every machine with Fedora is a real problem.
The Nokia 770 runs X. Back in the day, 8MB 486's ran X. Heck, Sun 5-60's
(68020's with 6MB of memory) ran X quite nicely. When you see X in
"top", a lot of its memory use is actually graphics card memory.
I had and 486 at the time with 8MB and I can assure you that X was the
*only* process running when I tried to use it (ie it used all memory and
some swap and the machine was basically dieing for the swapping)
When I had money to go 12MB X became slightly usable with some Xterms,
Xeyes and friends. Nothing fancy tho or swapping would start killing
your machine again.
However 32MB of ram will run X with a minimal Window Manager and apps
really well, especially at lower resolutions.
An X solution is not impossible. I'm not saying it's the
answer, but
you can't rule it out like that.
On this I can agree :)
--
Simo Sorce * Red Hat, Inc * New York
6:33 p.m.
On Tue, Sep 16, 2008 at 06:57:18PM -0400, Simo Sorce wrote:
However 32MB of ram will run X with a minimal Window Manager and
apps
really well, especially at lower resolutions.
It also depends on your X server. XFree86 is not small, clean or efficient
compare to things like KDrive. X is a protocol with a bloated nasty default
implementation which is only slowly recovering from twenty years of neglect
1:02 p.m.
On Mon, Sep 15, 2008 at 6:39 AM, Nicolas Mailhot
<nicolas.mailhot(a)laposte.net> wrote:
Le Lun 15 septembre 2008 12:57, Dominik 'Rathann' Mierzejewski a écrit :
>
> On Monday, 15 September 2008 at 12:35, Nicolas Mailhot wrote:
>> Le Sam 13 septembre 2008 00:59, Arthur Pemberton a écrit :
>> > I'm confused. Is Fedora really going to remove non X consoles?
>>
>> Mid-term that wouln't be such a bad idea.
>
> One would have to say why it is a good idea in the first place.
Simply put, non-X-console input is a mess (X input is a mess too but
at least there are people trying to fix it), non-X-console font
support has fossilized, and support for modern high resolution screens
is severely lacking.
The console has not evolved for a long time, while text requirements
have gone up. At this point a dumbed down text-only X session is
probably the only credible console future (or something that is not X
at all but uses many libraries we associate with apps now).
Non-X-console state is so bad nowadays I don't bother reporting bugs
on it. Even if they are fixed they always reappear the next Fedora
cycle. There is simply not enough console users and console
developpers to do anything but life support anymore.
And that's ok. Do remember that X was defined at a time hardware was
vastly less powerful and core X is not wasteful at all. Compared to
how the rest of the system has bloated, X is definitely lean and mean.
Leave non X consoles alone. Plain and simple. If you want to make it
better fine, if not leave it alone. I don't even think that this is up
for debate.
--
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )
6:22 p.m.
Colin Walters wrote:
On Fri, Sep 12, 2008 at 6:36 PM, Matthew Woehlke
<mw_triad(a)users.sourceforge.net> wrote:
> No,
> thanks; I'd rather have X fail to start and dump me at a normal console from
> which I can fix the problem *without rebooting*, much less needing to dig up
> a rescue disk :P.
I believe we already do that today, and am not advocating removing
that functionality if possible.
Right. If X doesn't work, we currently fall back on non-X consoles.
You said earlier:
We're going to be removing the legacy non-X system consoles by
default
in the long run.
...which would cause a problem there.
Maybe we're simply miscommunicating. Did you mean "we are going to
arrange so that you never see a non-X console unless you a: ask for one
(ctrl-alt-fX) or b: something goes wrong"? That's not how I read that
the first time (now, I'm simply unsure what you meant). If that's the
case, cool, forget what I said :-). Just so long as those "legacy non-X
consoles" don't cease to exist, I've no gripes making them as hidden as
you like for people that don't go looking for them.
--
Matthew
What? This signature /again/?
5:39 a.m.
On Saturday, 13 September 2008 at 00:52, Colin Walters wrote:
On Fri, Sep 12, 2008 at 6:36 PM, Matthew Woehlke
<mw_triad(a)users.sourceforge.net> wrote:
> No,
> thanks; I'd rather have X fail to start and dump me at a normal console from
> which I can fix the problem *without rebooting*, much less needing to dig up
> a rescue disk :P.
I believe we already do that today, and am not advocating removing
that functionality if possible.
You said you were, just the day before. Are you retracting your statement?
Anyways, I've said what I need to, so hopefully people won't
be surprised later.
Surprised by what, exactly? If you disable text mode log in, you'd better be
prepared to handle an enraged mob with torches and pitchforks, because this
is going to get ugly real soon. ;)
Regards,
R.
--
Fedora http://fedoraproject.org/wiki/User:Rathann
Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
5:36 a.m.
On Saturday, 13 September 2008 at 00:16, Colin Walters wrote:
On Fri, Sep 12, 2008 at 5:59 PM, Matthew Woehlke
<mw_triad(a)users.sourceforge.net> wrote:
> Colin Walters wrote:
>>
>> We're going to be removing the legacy non-X system consoles by default
>> in the long run.
>
> Um... what happens then when X is broken?
What happens when the linux kernel is broken?
Bad analogy. You can work without X, but you can't without the kernel.
What happens when /bin/sh is broken?
Use /bin/csh. ;)
What happens when NetworkManager is broken?
I still use the old network scripts. You will pry them from my rotting
fingers, but not before.
You fix the bug.
Sure. If you can. If not, you file a bugreport, but in the meantime,
you want to be able to work.
Also, one thing I would like to see Fedora install by default is a
compressed recovery image, rather than just multiple kernels.
I don't want to have to reboot just to fix a typo in xorg.conf.
Did you spend too much time working on MS Windows?
Regards,
R.
--
Fedora http://fedoraproject.org/wiki/User:Rathann
Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
5:11 p.m.
On Fri, Sep 12, 2008 at 12:46 PM, Colin Walters <walters(a)verbum.org> wrote:
On Fri, Sep 12, 2008 at 3:43 PM, Janina Sajka
<janina(a)rednote.net> wrote:
> It seems a useful initial step toward resolution is to run pulseaudio
> as a system daemon, via an init script, /sbin/service, /sbin/chkconfig.
> The trade-offs vs the per user model that F-9 employs are probably more
> than acceptable to most a11y users.
>
> So, let me simply ask ... Has anyone a working init script for
> pulseaudio as a system daemon? Anything close that we could continue to
> refine as an alternative configuration option for Fedora?
We're going to be removing the legacy non-X system consoles by default
in the long run.
On a related note, here we get to my pet bug, too: 444172. I often
use my desktop with one X session to the machine itself, and another X
session remotely logged in to my work laptop via XDMCP. However, the
per-user model means that not only can I not use PA on the laptop to
play over the desktop's speakers, but I can't continue to play
anything through the first X session.
https://bugzilla.redhat.com/show_bug.cgi?id=444172
(It's filed under ConsoleKit, as that seemed to be where the problem
was. I'm more than happy to reassign it if that makes sense :))
-Chris
--
Chris Weyl
Ex astris, scientia
6:26 p.m.
On Fri, 12.09.08 15:11, Chris Weyl (cweyl(a)alumni.drew.edu) wrote:
>> So, let me simply ask ... Has anyone a working init script
for
>> pulseaudio as a system daemon? Anything close that we could continue to
>> refine as an alternative configuration option for Fedora?
>
> We're going to be removing the legacy non-X system consoles by default
> in the long run.
On a related note, here we get to my pet bug, too: 444172. I often
use my desktop with one X session to the machine itself, and another X
session remotely logged in to my work laptop via XDMCP. However, the
per-user model means that not only can I not use PA on the laptop to
play over the desktop's speakers, but I can't continue to play
anything through the first X session.
https://bugzilla.redhat.com/show_bug.cgi?id=444172
(It's filed under ConsoleKit, as that seemed to be where the problem
was. I'm more than happy to reassign it if that makes sense :))
We make sure that a user that is not active on a screen gets no access
to audio device so that he cannot wiretap what you say or hear. (this
works only to a certain degree ince we still lack revoke() in the kernel)
Now, if I correctly understood your problem, then your XDMCP session
on the second vt will run as local gdm user or similar. We thus make
sure that only the gdm user has access.
I see the problem you are experiencing. On the other hand I would say
PA/CK behave correctly here.
I think the proper fix is to start PA locally on the XDMCP vt, so that
your remote audio is actually forwarded to a PA server that is
attached to your X11 server. Not sure about the security implications
however...
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
11:30 p.m.
Colin Walters wrote:
On Fri, Sep 12, 2008 at 3:43 PM, Janina Sajka wrote:
> The problems we have right now are sufficiently sever to be
> showstoppers. At the SpeakupModified.Org we recommend disabling
> pulseaudio. As things stand in F-9, one gets no audio until after a user
> logs in on the GUI. So, how are those who need screen reader support
> supposed to use the a11y features of GDM? As it stands, there seems no
> way to get console audio without that GUI login. Also a nonstarter in
> the screen reader user community.
If you want to run terminal applications, can't you just log in to a
full screen gnome-terminal?
> It seems a useful initial step toward resolution is to run pulseaudio
> as a system daemon, via an init script, /sbin/service, /sbin/chkconfig.
> The trade-offs vs the per user model that F-9 employs are probably more
> than acceptable to most a11y users.
>
> So, let me simply ask ... Has anyone a working init script for
> pulseaudio as a system daemon? Anything close that we could continue to
> refine as an alternative configuration option for Fedora?
We're going to be removing the legacy non-X system consoles by default
in the long run.
Aside from the fact that this little nugget derailed the thread due to
the many people (rightly*, IMO) freaking out, I fail to see where any
part of your message to which I am replying was of any relevance
whatsoever to this thread. PA as a system daemon should work (or,
perhaps, not work) regardless of what happens to "non-X system consoles"
in the future. Nor do I even see where Janina said *anything* about
them, or even about consoles or the CLI in general.
Did I miss something?
(*...though you still haven't answered if you really want to kill non-X
consoles or just hide them really well, which would have avoided all that.)
--
Matthew
ENOWIT: .sig file for this machine not set up yet
11:43 p.m.
On Fri, Sep 12, 2008 at 11:30 PM, Matthew Woehlke
<mw_triad(a)users.sourceforge.net> wrote:
(*...though you still haven't answered if you really want to kill
non-X
consoles or just hide them really well, which would have avoided all that.)
Maybe someone could split this off into a different thread.
Back on topic: should I just file a bug against pulseaudio for each
usecase that doesn't work? or is there a PulseAudip updates in
in386.newkey that I should wait for?
--
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )
12:06 p.m.
On Sat, Sep 13, 2008 at 12:30 AM, Matthew Woehlke
<mw_triad(a)users.sourceforge.net> wrote:
Aside from the fact that this little nugget derailed the thread due to the
many people (rightly*, IMO) freaking out, I fail to see where any part of
your message to which I am replying was of any relevance whatsoever to this
thread. PA as a system daemon should work (or, perhaps, not work) regardless
of what happens to "non-X system consoles" in the future. Nor do I even see
where Janina said *anything* about them, or even about consoles or the CLI
in general.
As I understood it, pulse as a system daemon was at least partially by
the desire to use it on a console, outside of a normal X login (and
all the infrastructure that comes with X, like the DBus session bus
which defines the session).
12:27 p.m.
Colin Walters writes:
As I understood it, pulse as a system daemon was at least partially
by
the desire to use it on a console, outside of a normal X login (and
all the infrastructure that comes with X, like the DBus session bus
which defines the session).
That's one use case. Someone here had another use case that was GUI.
There are probably additional use cases, and pulseaudio.org lays out
advantages and disadvantages of per user vs daemon mode.
The need is to support all the legitimate use cases. At this point I
would be happy with a pointer to a reasonably similar init script as a
starting point.
I know you don't care about consoles--I got that. But, I do, and
apparently I'm not alone. Surely the Fedora tent is big enough.
PS: Speaking strictly personally, I runlevel 5 by default. I like it
that way. I'm thrilled to finally have an up to date browser in Firefox
3, which is working very well with Orca, thank you. And, I'm using Open
Office more and more.
But, I still launch 24 consoles when I boot, because I actually use most
of them in very specific ways. About 6 of these 24 run screen with 9
separate terminal windows defined by ~/.screenrc. I don't see gnome
terminal replacing that anytime soon.
Yes, I'm familiar with gnome terminal. I'm reduced to it, and reduced to
gedit, when I have to run my laptop all day long on batteries, meaning
that I suspend frequently. Because of issues between the TTS engine
driver and alsa, I can't effectively resume consoles right now--screen
appears to be full of null chars, which rather defeats the screen
reader.
I get by with terminal, and gedit for notes, but it's a case of getting
by. No way can I replicate my rapid, key-combination-based random access
to the various tasks I park in particular consoles on gnome-terminal,
when all I have to allow cycling among them is Alt+TAB or maybe a series
of desktop shortcuts. That would be too slow and inefficient, in my
experience to date.
Janina
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
--
Janina Sajka, Phone: +1.202.595.7777; sip:janina@a11y.org
Partner, Capital Accessibility LLC http://CapitalAccessibility.Com
Marketing the Owasys 22C talking screenless cell phone in the U.S. and Canada
Learn more at http://ScreenlessPhone.Com
Chair, Open Accessibility janina(a)a11y.org
Linux Foundation http://a11y.org
12:41 p.m.
On Sat, Sep 13, 2008 at 1:27 PM, Janina Sajka <janina(a)rednote.net> wrote:
But, I still launch 24 consoles when I boot, because I actually use most
of them in very specific ways. About 6 of these 24 run screen with 9
separate terminal windows defined by ~/.screenrc. I don't see gnome
terminal replacing that anytime soon.
It has tabs, and you can script it; I don't see what wouldn't work
with your setup.
10:06 p.m.
On Sat, Sep 13, 2008 at 12:41 PM, Colin Walters <walters(a)verbum.org> wrote:
On Sat, Sep 13, 2008 at 1:27 PM, Janina Sajka
<janina(a)rednote.net> wrote:
>
> But, I still launch 24 consoles when I boot, because I actually use most
> of them in very specific ways. About 6 of these 24 run screen with 9
> separate terminal windows defined by ~/.screenrc. I don't see gnome
> terminal replacing that anytime soon.
It has tabs, and you can script it; I don't see what wouldn't work
with your setup.
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
I just updated from an Intel Celeron D 2.8Ghz 533Mhz FSB to an Intel
P4 3.0Hz 800Mhz FSB, which in turned allowed my memory to operate at
400Mhz instead of 333MHz.
One of the noticeable improvements is that I can use Firefox +
Pulseaudio + Amarok. Previously, at 4 or 5 tabs, scrolling, or similar
activity in Firefox would somehow bring about Pulseaudio's demise. Top
reports Pulse audio between 30% and 55% CPU usage.
--
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )
9:57 a.m.
Colin Walters writes:
On Sat, Sep 13, 2008 at 1:27 PM, Janina Sajka
<janina(a)rednote.net> wrote:
>
> But, I still launch 24 consoles when I boot, because I actually use most
> of them in very specific ways. About 6 of these 24 run screen with 9
> separate terminal windows defined by ~/.screenrc. I don't see gnome
> terminal replacing that anytime soon.
It has tabs, and you can script it; I don't see what wouldn't work
with your setup.
Perhaps when X evolves enough that we aren't limited to it on one
console. Or, perhaps also when the at stack becomes much more robust.
Right now, while the gui has been usable (for about a year), it's prone
to something--God only knows what, because when my speech dies I have no
notion of any error, etc--I simply lose the whole environment. Usually,
Ctrl+Alt+Backspace lets me start over, but that doesn't encourage one to
replace 24 consoles with terminal tabs. Not infrequently,
ctrl+alt+backspace doesn't work, and I'm trying telinit 3 followed by
telinit 5. Too frequently, even this doesn't work and I have to reboot
if I want a stable gui--which discourages me from relying on it for real
work.
BTW: Not all my consoles are simple terminal screens. I run 9 mutt
instances in 9 screen terminals on Ctrl+Alt+F1, for instance. My inbox
is in Ctrl-A1, Fedora mail in Ctrl-a5, my standards related work in
Ctrl-a9, etc. Meanwhile, evolution and thunderbird are only marginally
usable from the screen reader perspective, and not with the same
alacrity that serves me in mutt. Heck, I can still cite specific web
pages where lynx does better than firefox3 from my a11y perspective.
Thankfully, there are plenty examples the other way around, too.
Janina
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
--
Janina Sajka, Phone: +1.202.595.7777; sip:janina@a11y.org
Partner, Capital Accessibility LLC http://CapitalAccessibility.Com
Marketing the Owasys 22C talking screenless cell phone in the U.S. and Canada
Learn more at http://ScreenlessPhone.Com
Chair, Open Accessibility janina(a)a11y.org
Linux Foundation http://a11y.org
11 a.m.
Janina Sajka wrote:
>> But, I still launch 24 consoles when I boot, because I
actually use most
>> of them in very specific ways. About 6 of these 24 run screen with 9
>> separate terminal windows defined by ~/.screenrc. I don't see gnome
>> terminal replacing that anytime soon.
> It has tabs, and you can script it; I don't see what wouldn't work
> with your setup.
>
Perhaps when X evolves enough that we aren't limited to it on one
console.
X has never been limited to one console - and the consoles are not
required to be attached to the host. Fedora's pulseaudio configuration
may assume otherwise, though.
Or, perhaps also when the at stack becomes much more robust.
Right now, while the gui has been usable (for about a year), it's prone
to something--God only knows what, because when my speech dies I have no
notion of any error, etc--I simply lose the whole environment.
I'm not sure how it interacts with speech - or even audio at all, but
freenx with the NX client from www.nomachine.com is fairly robust and
lets you suspend and reconnect the display, possibly from different
clients and locations. You might need to use the commercial version of
the NX server to get audio to work remotely.
BTW: Not all my consoles are simple terminal screens. I run 9 mutt
instances in 9 screen terminals on Ctrl+Alt+F1, for instance. My inbox
is in Ctrl-A1, Fedora mail in Ctrl-a5, my standards related work in
Ctrl-a9, etc. Meanwhile, evolution and thunderbird are only marginally
usable from the screen reader perspective, and not with the same
alacrity that serves me in mutt. Heck, I can still cite specific web
pages where lynx does better than firefox3 from my a11y perspective.
Thankfully, there are plenty examples the other way around, too.
I can't comment on how well you can find things on an NX screen without
seeing them, but otherwise I find NX to be much nicer than screen in
terms of being able to keep a whole desktop of programs running on a
central well-connected host and being able to pick up the display on a
work desktop, a roaming laptop, or through a vpn from home. You also
have access to the native programs on the machine where you run the NX
client, which might be linux, windows or a mac. I normally have enough
terminal and firefox sessions running that gnome collates them to one
task bar item that pops up a list when you click it.
While I don't want text mode to go away, the NX approach fixes a lot of
the problems with native X.
--
Les Mikesell
lesmikesell(a)gmail.com
5:31 a.m.
On Friday, 12 September 2008 at 21:46, Colin Walters wrote:
On Fri, Sep 12, 2008 at 3:43 PM, Janina Sajka
<janina(a)rednote.net> wrote:
>
> The problems we have right now are sufficiently sever to be
> showstoppers. At the SpeakupModified.Org we recommend disabling
> pulseaudio. As things stand in F-9, one gets no audio until after a user
> logs in on the GUI. So, how are those who need screen reader support
> supposed to use the a11y features of GDM? As it stands, there seems no
> way to get console audio without that GUI login. Also a nonstarter in
> the screen reader user community.
If you want to run terminal applications, can't you just log in to a
full screen gnome-terminal?
I can, but that's irrelevant. Why do you want to take my ability to
log in in text mode?
> It seems a useful initial step toward resolution is to run
pulseaudio
> as a system daemon, via an init script, /sbin/service, /sbin/chkconfig.
> The trade-offs vs the per user model that F-9 employs are probably more
> than acceptable to most a11y users.
>
> So, let me simply ask ... Has anyone a working init script for
> pulseaudio as a system daemon? Anything close that we could continue to
> refine as an alternative configuration option for Fedora?
We're going to be removing the legacy non-X system consoles by default
in the long run.
Please tell me this is some kind of bad joke! Is Fedora becoming like
MS Windows? Just when Microsoft announced that you'll be able to install
Windows 7 without a GUI, you're announcing something opposite for Fedora?
Are you going to drive away people who like the textmode better?
Seriously, that would be one of the changes that would drive *me* away
from Fedora. Please don't do that. I like Fedora too much and I've invested
too much time in improving it for me.
Regards,
R.
--
Fedora http://fedoraproject.org/wiki/User:Rathann
Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
6:10 a.m.
Colin Walters <walters <at> verbum.org> writes:
We're going to be removing the legacy non-X system consoles by
default
in the long run.
I am sincerely hoping that we are not heading for this kind of disaster:
http://technet.microsoft.com/en-us/library/cc750820.aspx
Don't worry about graphics drivers being moved into the kernel - that's not the
biggest evil here. Pay particular attention to this sentence:
"And there is no loss of reliability, since (a) the kernel mode implementations
of Win32 are fully protected from direct access by applications; and (b) the
Win32 server process is considered a critical system component of Windows NT
3.51, such that if the CSRSS.EXE process faults the entire Windows NT operating
system is _shutdown_."
Note how Microsoft engineers completely missed the real reliability point here.
The situation is grave (i.e. the reliability is crap) due to idiotic design -
and right from the start - they just documented it here.
They are here because they have no _alternative_ UI. No other way to log in. No
way to kill bad stuff and continue.
Let's not do that with Fedora. Please.
--
Bojan
6:16 p.m.
On Fri, 12.09.08 15:43, Janina Sajka (janina(a)rednote.net) wrote:
The problems we have right now are sufficiently sever to be
showstoppers. At the SpeakupModified.Org we recommend disabling
pulseaudio. As things stand in F-9, one gets no audio until after a user
logs in on the GUI. So, how are those who need screen reader support
supposed to use the a11y features of GDM? As it stands, there seems no
way to get console audio without that GUI login. Also a nonstarter in
the screen reader user community.
In Rawhide PA is started on demand (in addition to being started from
gnome-session) and thus should generally work fine on the console too.
It seems a useful initial step toward resolution is to run
pulseaudio
as a system daemon, via an init script, /sbin/service, /sbin/chkconfig.
The trade-offs vs the per user model that F-9 employs are probably more
than acceptable to most a11y users.
Nope. Please don't. This particular problem is solved in Rawhide.
So, let me simply ask ... Has anyone a working init script for
pulseaudio as a system daemon? Anything close that we could continue to
refine as an alternative configuration option for Fedora?
Some distros ship an init script.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
6:13 p.m.
On Wed, 10.09.08 20:56, Arthur Pemberton (pemboa(a)gmail.com) wrote:
I have a lot of seemingly pulse audio related issues on my F9
desktop.
Since I really like the idea behind Pulseaudio, I would like to see
these get sorted out, and would like to know how I can help in terms
of providing useful information.
Here is my situation
* Sounblaster Live 5.1 PCI -- has full 6 channel audio before, I had
for a short while after enabling it as per the pulseaudio wiki, but no
more
Does pavucontrol show the device as having 6 channels? Please make
sure that /etc/pulse/daemon.conf (or ~/.pulse/daemon.conf if you have
that) is configured for 6 channel audio with
"default-sample-channels=6".
Also, an output of "pulseaudio -vvvv" (you might need to stop pa first
by issuing pulseaudio -k first) would be very useful to track down
what is going on.
* Tvtime -- no audio (doing `padsp sox -r 48000 -w -c 2 -t ossdsp
/dev/dsp -t ossdsp /dev/dsp` works, but causes noticeable lag)
* Amarok (xine) -- audio, susceptible to crashes, esp when I scroll to
fast in Firefox
Xine should work fine. Make sure you are running the newest packages
for F9, then provide crash bt.
* Kopete -- used to work, mysteriously stopped working
* Konversation -- never worked
* Mythfront -- no sound yet (haven't followed
http://svn.mythtv.org/trac/ticket/3598#comment:16 yet)
I don't know these apps. Don't know much about KDE. Do these also use Xine?
* V4L tv capture card -- no sound now, used to rely on capturing AUX
on sound card before
"no sound"? What does that mean?
* PulseAudio -- seems to average 30% CPU usage when playing music,
doesn't like me using Firefox too much (seems like a resource issue)
Firefox doesn't use audio. Flash does. Flash is
broken. libflashsupport can fix a few issues but doesn't solve them
entirely.
If PA eats too much CPU this might be caused be the resampler we
use. Consider playinging around with "resample-method" in daemon.conf
and setting it to "trivial".
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
6:48 p.m.
On Mon, Sep 22, 2008 at 6:13 PM, Lennart Poettering
<mzerqung(a)0pointer.de> wrote:
On Wed, 10.09.08 20:56, Arthur Pemberton (pemboa(a)gmail.com) wrote:
> I have a lot of seemingly pulse audio related issues on my F9 desktop.
> Since I really like the idea behind Pulseaudio, I would like to see
> these get sorted out, and would like to know how I can help in terms
> of providing useful information.
>
> Here is my situation
>
> * Sounblaster Live 5.1 PCI -- has full 6 channel audio before, I had
> for a short while after enabling it as per the pulseaudio wiki, but no
> more
Does pavucontrol show the device as having 6 channels? Please make
sure that /etc/pulse/daemon.conf (or ~/.pulse/daemon.conf if you have
that) is configured for 6 channel audio with
"default-sample-channels=6".
Also, an output of "pulseaudio -vvvv" (you might need to stop pa first
by issuing pulseaudio -k first) would be very useful to track down
what is going on.
> * Tvtime -- no audio (doing `padsp sox -r 48000 -w -c 2 -t ossdsp
> /dev/dsp -t ossdsp /dev/dsp` works, but causes noticeable lag)
> * Amarok (xine) -- audio, susceptible to crashes, esp when I scroll to
> fast in Firefox
Xine should work fine. Make sure you are running the newest packages
for F9, then provide crash bt.
> * Kopete -- used to work, mysteriously stopped working
> * Konversation -- never worked
> * Mythfront -- no sound yet (haven't followed
> http://svn.mythtv.org/trac/ticket/3598#comment:16 yet)
I don't know these apps. Don't know much about KDE. Do these also use Xine?
> * V4L tv capture card -- no sound now, used to rely on capturing AUX
> on sound card before
"no sound"? What does that mean?
> * PulseAudio -- seems to average 30% CPU usage when playing music,
> doesn't like me using Firefox too much (seems like a resource issue)
Firefox doesn't use audio. Flash does. Flash is
broken. libflashsupport can fix a few issues but doesn't solve them
entirely.
If PA eats too much CPU this might be caused be the resampler we
use. Consider playinging around with "resample-method" in daemon.conf
and setting it to "trivial".
Lennart
Hi Lennart,
I appreciate your assistance, but I regret to say that I removed
PulseAudio this past weekend. It relatively easy, and my system almost
shamefully more functional now. I have since discovered at least one
feature that I did not did not even know existed as PulseAudio wasn't
functioning properly. This situation is made even more unfortunate as
I have recently discovered that current version on Microsoft Windows
has PulseAudio like features working just fine.
If there is a specific test that I can run, I'll be happy to do so,
but I cannot really run PulseAudio full time as is, I enjoy my music
collection too much for this.
Arthur Pemberton
--
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )
5685
days inactive
5703
days old
236 comments
43 participants
participants (43)
-
Alan Cox -
Andrew Parker -
Andy Lawrence -
Arthur Pemberton -
Benny Amorsen -
Bill Crawford -
Bill Nottingham -
Bojan Smojver -
Callum Lerwick -
Chris Weyl -
Chuck Anderson -
Colin Walters -
Dan Williams -
David Nielsen -
Denis Leroy -
Dimi Paun -
Dmitry Butskoy -
Dominik 'Rathann' Mierzejewski -
Gregory Maxwell -
Ignacio Vazquez-Abrams -
Janina Sajka -
Jef Spaleta -
Jerry James -
Jesse Keating -
Josh Boyer -
Karel Zak -
Lennart Poettering -
Les Mikesell -
Matthew Miller -
Matthew Woehlke -
Matthias Clasen -
Nicolas Mailhot -
Nils Philippsen -
Olivier Galibert -
Rahul Sundaram -
Ralf Corsepius -
Ray Strode -
Richard Hughes -
Seth Vidal -
Simo Sorce -
Srecko Morovic -
Suren Karapetyan -
Toshio Kuratomi