5:44 p.m.
It's probably too late to matter, but here's my reaction to F10:
I've recently installed Fedora 10 Live onto my new Asus N10J-A2
netbook and am not happy with the experience. I am very sad to see
the direction that Fedora is taking toward making it more Windows-like
and disregarding important *NIX precepts. I especially deplore the
trend toward forcing use of Gnome instead of properly treating X as just
another utility that may or may not be useful. I happen to dislike Gnome
and use XFCE in its place, but start it only when I deem it worthwhile.
Along with having Gnome rammed down our throats, comes the concealment
of valuable progress information during boot and shutdown. What's the
use of that? Can anyone say they prefer to be left with a blank
screen while important things are happening (or not happening)?
We have the new 'plymouth' system to thank. The designers chose not
only to suppress the grub menu, but all the important [OK] or [FAIL]
messages as various system elements start, or fail to start.
Instead we see an animated logo, devoid of information content.
The Release Notes tell how to overcome this defective design -
Edit /boot/grub/grub.conf to comment out the 'hiddenmenu' line,
and change the kernel line to delete 'rhgb' and add 'vga=0x315'
as boot options. Actually, the Notes advocate 0x318, which is invalid
on my machine, however the error message is improved. It now lists
the available VGA modes with an alphabetic label for immediate use,
but also with the proper hex code for addition to grub.conf.
I customarily edit /etc/inittab to use init level 3 so I can see the
important startup messages and delay entering X until I'm ready.
The F10 bootup and login procedure is all very sanitary, very
Windows-like, and very free of information. Is this good?
I think not.
The Gnomophiles on the design committee seem to have forgotten some
basic precepts of good system design. An increasing number of
subsystems that have nothing whatever to do with a graphical interface
now have Gnome as a prerequisite.
With Fedora 9 we had the spectacle of pulseaudio which would start
only in Gnome, but not in XFCE4. The complaints were loud due to the
frustration this engendered. I managed to deduce a complex fix so
that any and all users could use the audio system, including the
ability to again play a sound in rc.local (run by root), and to have
sound capability in consoles and in XFCE4 and in Gnome. This required
editing of the sacrosanct udev rules. Now these rules are gone in
F10, and I haven't found where they went.
The Release Notes promise us a "Glitch-Free PulseAudio".
Sorry folks. If anything, its worse.
The draconian permission restrictions, previously cryptically buried in
/etc/udev/rules.d, have now disappeared. Therefore they cannot be fixed.
Empirically, if I invoke startx to run Gnome, sound can be produced.
If I invoke startxfce4 to run XFCE4 the sound system is silent.
If I install in rc.local the command
/usr/bin/aplay /usr/share/sounds/startup3.wav
no sound occurs at bootup to let me know it's ready to logon.
Pulseaudio is a system daemon that should be started by a script in
/etc/init.d just like other system services, so its capabilities are
available to all users at all times, without regard to whether X is
running or not. The current design is unacceptable.
It's hopelessly frustrating.
I understand this ill-considered design has made it nearly impossible for
blind users to log on. It's merely inconvenient for me, since I enjoy
hearing an audible signal when the system is ready for me to log on.
Not having sound is certainly a showstopper for Fedora 10.
I've read about, but not experienced, the feature of NetworkManager
that requires a user to login before an encrypted wireless link will
connect. I would really like to hear someone explain how a remote
machine, connected only by wireless, can successfully auto-reboot.
A wireless connection, encrypted or not, is an attribute of a system,
not a user. Whether a user is logged in is irrelevant. To require a
user to login first is an incredibly dumb design.
Here are some specific complaints:
1) Now that I've managed to unsuppress the boot messages, the first
one seen is "Could not detect stabilization. Waiting 10 seconds."
So the vaunted faster bootup has been defeated by some mysterious
failure on my Asus N10 netbook.
2) The default Gnome login method, gdm, I think, now absolutely
forbids root to login. Previously it merely warned that this
was a bad practice. During installation you are strongly urged but
not compelled to create a regular user account. I did not, because
that would conflict with the standard set of user accounts and user
IDs that I apply to all my machines. I run a little script to create
all accounts in a standardized way. The Fedora 10 guardians (nearly)
defeated me. When installation finished and I rebooted I could not log
in, thanks to this newly stupid gdm restriction.
Fortunately, I remembered to switch to a console (CTL-ALT-F1), where
root was still allowed to login. I ran my little script to add the
standard list of users and saved the day.
Have Linux users really grown too stupid to understand the admonition
not to log in as root (except when really necessary)?
Finally, here are some real improvements and benefits of Fedora 10:
1) My Asus N10J netbook contains some new hardware that wasn't
well supported previously. The RTL8111/8168B gigabit ethernet port
worked in F9 but not during installation. Now it works fine.
2) The wireless adapter, Atheros Comm device 002a (rev 01), which
includes 802.11 a/b/n, requires the new ath9k driver, which wasn't
available in F9. It works perfectly.
3) There's a builtin camera that seems to work perfectly with the
newly expanded support for cameras. The 'cheese' program "just works",
displaying my handsome visage, albeit upside down and reversed. There are
option settings to fix that, but no way to save them (that I've found).
4) The sound system, with the caveats above, produces sound that's
barely audible. But that's an improvment, because F9 didn't support
the sound card at all.
--
David A. De Graaf DATIX, Inc. Hendersonville, NC
dad(a)datix.us www.datix.us
8:25 a.m.
On Sun, Nov 16, 2008 at 09:59:30PM +1100, David Timms wrote:
David A. De Graaf wrote:
> It's probably too late to matter, but here's my reaction to F10:
>
> I've recently installed Fedora 10 Live onto my new Asus N10J-A2
Is that Live Preview ? I didn't think that F10 release was released yet ?
DaveT.
It was this one:
-rw-rw-r-- 1 dad dad 730785792 2008-11-08 10:25 F10-Beta-i686-Live.iso
but with recent yum upgrades, /etc/fedora-release now contains
Fedora release 10 (Cambridge)
the kernel is -2.6.27.5-101.fc10.i686
I had also tried to install F10-PR-i686-Live.iso but that installation
failed in some way I cannot remember.
--
David A. De Graaf DATIX, Inc. Hendersonville, NC
dad(a)datix.us www.datix.us
4:27 p.m.
I've finally achieved glorious loud sound on my Asus N10JA3 netbook
running Fedora 10 and XFCE - a struggle against enormous odds.
1) Add to /etc/modprobe.conf this line
options snd-hda-intel model=3stack-dig
There are other options that are valid for the hardware codec reported
in /proc/asound/card0/codec#* :
Codec: Realtek ALC662 rev1
but this one seems to work.
2) Deactivate pulseaudio by removing one package:
rpm -e alsa-plugins-pulseaudio
3) Prevent xfce from autostarting pulseaudio by unchecking that item
in the Settings Manager.
4) Permissions that are automatically set for /dev/snd/* prevent
users from using the sound devices. I have been unable to find the
"proper" way to undo this travesty, but a brute force solution works.
Edit /etc/rc.d/rc.local to add
chmod 666 /dev/snd/*
/usr/bin/aplay /usr/share/sounds/startup3.wav
5) Reboot to a console login, with init level 3.
Enjoy the gorgeous sound of startup3.wav when the system is ready for
login (before *anyone* has logged in).
6) Run alsamixer. Observe many sliders for various functions.
Slide them up to a higher setting. Exit alsamixer an run
alsactl store
to save the settings.
7) Run startxfce4 and observe that aplay now works there, too.
Pulseaudio is a travesty and abomination. If I never hear of it again,
it'll be too soon. Those who have inflicted these secret and ridiculous
permission restrictions that block use of the sound system should be
disbarred from the Project. Obstacles to easy use cannot make Fedora
attractive to new users.
--
David A. De Graaf DATIX, Inc. Hendersonville, NC
dad(a)datix.us www.datix.us
7:11 p.m.
On Mon, Nov 17, 2008 at 05:27:03PM -0500, David A. De Graaf wrote:
4) Permissions that are automatically set for /dev/snd/* prevent
users from using the sound devices. I have been unable to find the
"proper" way to undo this travesty,
A way to undo this "travesty" is to add a file in
/etc/security/console.perms.d, say 90-my.perms, with permissions
like you want them to see. A format should be obvious if you will
look at other files but see also 'man 5 console.perms' and
'rpm -qd pam' for a bigger picture. The location name indicates that
this does have security implications but in a particular setup you
may not care.
but a brute force solution works.
To an extent. Logging from a keyboard and logging out, I guess,
will revert them to a state specified in existing files from
/etc/security/ tree.
Pulseaudio is a travesty and abomination.
That sounds a bit too overgeneralized; but did you bother to look at
'man pulseaudio'? Among other things it explains how to run it as a
system-wide daemon instead of an instance for every user and what
are tradeoffs. I tend to agree that this is not that well thought
off and geared to "windoze user" even if that user happens to run
something else.
Michal
3:51 a.m.
On Tue, Nov 18, 2008 at 3:11 AM, Michal Jaegermann <michal(a)harddata.com>wrote:
On Mon, Nov 17, 2008 at 05:27:03PM -0500, David A. De Graaf wrote:
>
> 4) Permissions that are automatically set for /dev/snd/* prevent
> users from using the sound devices. I have been unable to find the
> "proper" way to undo this travesty,
A way to undo this "travesty" is to add a file in
/etc/security/console.perms.d, say 90-my.perms, with permissions
like you want them to see. A format should be obvious if you will
look at other files but see also 'man 5 console.perms' and
'rpm -qd pam' for a bigger picture. The location name indicates that
this does have security implications but in a particular setup you
may not care.
> but a brute force solution works.
To an extent. Logging from a keyboard and logging out, I guess,
will revert them to a state specified in existing files from
/etc/security/ tree.
> Pulseaudio is a travesty and abomination.
That sounds a bit too overgeneralized; but did you bother to look at
'man pulseaudio'? Among other things it explains how to run it as a
system-wide daemon instead of an instance for every user and what
are tradeoffs. I tend to agree that this is not that well thought
off and geared to "windoze user" even if that user happens to run
something else.
Michal
I use Linux since RH9 aka Shrike and still can't stand pulseaudio.
--
fedora-test-list mailing list
fedora-test-list(a)redhat.com
To unsubscribe:
https://www.redhat.com/mailman/listinfo/fedora-test-list
--
Aioanei Rares
schaiba(a)fedoraproject.org
"China is a big country, inhabited by many Chinese." --Charles de Gaulle
6:11 a.m.
On Tue, Nov 18, 2008 at 11:51:17AM +0200, Aioanei Rares wrote:
On Mon, Nov 17, 2008 at 05:27:03PM -0500, David A. De Graaf wrote:
>
> 4) Permissions that are automatically set for /dev/snd/* prevent
> users from using the sound devices. I have been unable to find the
> "proper" way to undo this travesty,
> Pulseaudio is a travesty and abomination.
That sounds a bit too overgeneralized; but did you bother to look at
'man pulseaudio'?
I use Linux since RH9 aka Shrike and still can't stand
pulseaudio.
One does wonder. Without arguing the merits of any of these decisions,
one does wonder, as RHEL6 is supposedly going to be based upon F9 and
F10, if the powers that be at RH pay any attention to the community's
general disapproval of pulse-audio, tying sound to consolekit and making
consolekit far more difficult to turn off, packagekit, the removal of root
login in gdm, plymouth, the closer tie-ins to Gnome in general, etc.
Again, I'm not arguing one way or the other. However, judging from
forums and various personal conversations, the people most annoyed are
usually RH's target, the sysadmin types.
When I say community
disapproval, I don't necessarily mean everyone--again, I'm referring to
my own experience, general impression from the Fedora forums, and private
emails and conversations.
I repeat one more time, that I am not arguing here that any of these are
good or bad decisions. I'm simply saying that my experience is that
many sysadmin types are displeased with many of these decisions.
Especially when one considers how the next crop of sysadmins will
probably come from the Ubuntu generation, I sometimes think RH may
really start losing some of their market share if they ignore this.
--
Scott Robbins
PGP keyID EB3467D6
( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 )
gpg --keyserver pgp.mit.edu --recv-keys EB3467D6
Buffy: Ampata wasn't evil. At least, not to begin with.
And...I do think she cared
about you.
Xander: Yeah, but I think that whole sucking the life out of people
thing
would've been a strain on the relationship.
6:59 a.m.
On Tuesday 18 November 2008 12:11:51 Scott Robbins wrote:
When I say community
disapproval, I don't necessarily mean everyone--again, I'm referring to
my own experience, general impression from the Fedora forums, and private
emails and conversations.
It's always necessary to remember that those who are happy are silent. Lists
and forums are no guide to the percentage of happy users exist.
Anne
10:30 a.m.
On Tue, Nov 18, 2008 at 6:59 AM, Anne Wilson <cannewilson(a)googlemail.com> wrote:
On Tuesday 18 November 2008 12:11:51 Scott Robbins wrote:
> When I say community
> disapproval, I don't necessarily mean everyone--again, I'm referring to
> my own experience, general impression from the Fedora forums, and private
> emails and conversations.
It's always necessary to remember that those who are happy are silent. Lists
and forums are no guide to the percentage of happy users exist.
It's also always necessary to remember that those who are mad as hell
may also be silent, tired of wasting their time sounding off against
the deaf ears of the powers that be.
jerry
--
There's plenty of youth in America - it's time we find the "fountain of
smart".
12:51 p.m.
2008/11/18 Jerry Amundson <jamundso(a)gmail.com>
On Tue, Nov 18, 2008 at 6:59 AM, Anne Wilson
<cannewilson(a)googlemail.com>
wrote:
> On Tuesday 18 November 2008 12:11:51 Scott Robbins wrote:
>> When I say community
>> disapproval, I don't necessarily mean everyone--again, I'm referring to
>> my own experience, general impression from the Fedora forums, and
private
>> emails and conversations.
>
> It's always necessary to remember that those who are happy are silent.
Lists
> and forums are no guide to the percentage of happy users exist.
It's also always necessary to remember that those who are mad as hell
may also be silent, tired of wasting their time sounding off against
the deaf ears of the powers that be.
jerry
+1
--
There's plenty of youth in America - it's time we find the "fountain of
smart".
--
fedora-test-list mailing list
fedora-test-list(a)redhat.com
To unsubscribe:
https://www.redhat.com/mailman/listinfo/fedora-test-list
--
Linux counter #213090
2:12 p.m.
On Mon, Nov 17, 2008 at 06:11:04PM -0700, Michal Jaegermann wrote:
On Mon, Nov 17, 2008 at 05:27:03PM -0500, David A. De Graaf wrote:
> Pulseaudio is a travesty and abomination.
That sounds a bit too overgeneralized;
Michal Jaegermann:
Thank you for your calming, rational and helpful reply.
My previous rant against pulseaudio was misdirected.
Pulseaudio works perfectly well - there is no need to remove the
alsa-plugins-pulseaudio package - but the "security" restrictions
surrounding it are onerous and inappropriate for the default setup (in my
opinion). Overcoming these restrictions is obscure and unnecessesarily
difficult and is likely to discourage Fedora users who are unwilling
to discover the secret handshake. This default configuration is
inappropriate. It can and should be made more user-friendly.
My minimal expectations are simple:
1) aplay should be able to make a sound before anyone has logged in.
2) sound should be available to all users both at a console
and in X - xfce, gnome, kde or any other graphical environment.
This includes allowing crontab entries to make sounds, regardless of
who's logged in.
Availability of sound should most certainly not depend on X.
This implies that the pulseaudio daemon must be started at bootup,
preferably as a regular system service, and that the sound device files
should be accessible by anyone.
Here are the changes needed for sound to work for me.
First, make sure the soundcard works. In most cases, the proper
driver module will be installed automatically. But for my Asus N10JA2
netbook with Audio device: Intel Corporation 82801G (ICH7 Family)
High Definition Audio Controller (rev 02) it was necessary to add this
line to /etc/modprobe.conf:
options snd-hda-intel model=3stack-dig
1) Edit /etc/group, adding every user to group pulse-access, or at
least every user that will be permitted to enjoy the sound system.
Be sure to include root.
pulse-access:x:495:root,dad,srd
2) To relax the restrictions that block users from using the sound
system, create a new file, /etc/security/console.perms.d/80-sound.perms
# define the sound device class
<sound>=/dev/snd/*
# permissions
<console> 0666 <sound> 0666
This allows the sound devices to be accessible to all users.
3) Start a system-wide pulseaudio daemon by adding lines to
/etc/rc.d/rc.local. The daemon starts before anyone has logged in,
and runs forever.
/usr/bin/pulseaudio -D --system --log-level=3 --log-target=syslog
/usr/bin/aplay /usr/share/sounds/startup3.wav
4) Prevent xfce from starting another redundant pulseaudio process.
Edit /etc/xdg/xfce4/xinitrc to comment out these lines:
## if test x"`which pulseaudio 2>/dev/null`" != x""; then
## pulseaudio -D &
## fi
If anyone can explain why this is not an appropriate default setup for
Fedora, I would love to hear it.
--
David A. De Graaf DATIX, Inc. Hendersonville, NC
dad(a)datix.us www.datix.us
2:46 p.m.
On Tue, Nov 18, 2008 at 03:12:58PM -0500, David A. De Graaf wrote:
1) Edit /etc/group, adding every user to group pulse-access, or at
least every user that will be permitted to enjoy the sound system.
Be sure to include root.
pulse-access:x:495:root,dad,srd
Why do you have include root? It has that access anyway by a virtue
of beeing root.
I was adding users to a group pulse-rt but if you are starting
pulseaudio with '--system' then this will not make difference
accordingly to 'man pulseaudio'.
2) To relax the restrictions that block users from using the sound
system, create a new file, /etc/security/console.perms.d/80-sound.perms
# define the sound device class
<sound>=/dev/snd/*
# permissions
<console> 0666 <sound> 0666
I would probably made that into
<console> 0664 <sound> 0664 root.pulse-access
in your case ....
This allows the sound devices to be accessible to all users.
... to make that accessible for those you want this access to happen.
3) Start a system-wide pulseaudio daemon by adding lines to
/etc/rc.d/rc.local. The daemon starts before anyone has logged in,
and runs forever.
/usr/bin/pulseaudio -D --system --log-level=3 --log-target=syslog
/usr/bin/aplay /usr/share/sounds/startup3.wav
4) Prevent xfce from starting another redundant pulseaudio process.
Edit /etc/xdg/xfce4/xinitrc to comment out these lines:
## if test x"`which pulseaudio 2>/dev/null`" != x""; then
## pulseaudio -D &
## fi
I guess that I would be a bit more careful
if ! pgrep -u $(whoami) -f pulseaudio >/dev/null ; then
type -p pulseaudio >/dev/null && pulseaudio -D &
fi
If anyone can explain why this is not an appropriate default setup
for
Fedora, I would love to hear it.
See 'man pulseaudio' about pulse-rt and related things. It may be a
good idea once you played startup3.wav to do 'pulseaudio -k' and
restart it again later in a different stance.
Yes, I know; something straight for newbies.
Michal
11:07 a.m.
On Tue, Nov 18, 2008 at 01:46:44PM -0700, Michal Jaegermann wrote:
On Tue, Nov 18, 2008 at 03:12:58PM -0500, David A. De Graaf wrote:
>
> 1) Edit /etc/group, adding every user to group pulse-access, or at
> least every user that will be permitted to enjoy the sound system.
> Be sure to include root.
> pulse-access:x:495:root,dad,srd
Why do you have include root? It has that access anyway by a virtue
of beeing root.
I was adding users to a group pulse-rt but if you are starting
pulseaudio with '--system' then this will not make difference
accordingly to 'man pulseaudio'.
If root is not included in group pulse-access, root isn't able to
use aplay to make sound. In rc.local a system-wide pulseaudio daemon
starts successfully, but the next line to play a sound fails to do so.
After login, neither a root console nor a root xterm can play a sound.
So, when there is a "system-wide" instance of pulseaudio running,
unless a user is in group pulse-rt he cannot aplay a sound.
This is consistent with the man page paragraph "Group pulse-access".
> 2) To relax the restrictions that block users from using the sound
> system, create a new file, /etc/security/console.perms.d/80-sound.perms
>
> # define the sound device class
> <sound>=/dev/snd/*
> # permissions
> <console> 0666 <sound> 0666
I would probably made that into
<console> 0664 <sound> 0664 root.pulse-access
Empirically, if I do that, neither root nor dad can ever aplay a sound.
There are cases where the man page and the actual program seem
to conflict. With the system-wide pulseaudio running, the command
pulseaudio --kill
fails to kill it, when run by either dad or root!
When I tried to delicately amend the xfce initrc to use the --start
option so that it would start only if none was running, eg,
if test x"`which pulseaudio 2>/dev/null`" != x""; then
## pulseaudio -D &
pulseaudio --start -D --log-target=syslog
fi
the program blithely ignored the existing instance and started up
another. Thus I was compelled to edit out the entire startup phrase:
## if test x"`which pulseaudio 2>/dev/null`" != x""; then
## pulseaudio -D &
## fi
There are hidden and secret rules beyond the mind of man to comprehend
here. In my opinion, the security mavens have gone wild, and made a
system that is nearly impossible for ordinary mortals to use.
I have yet to learn of a security risk that justifies impairing the
sound system to this degree. If the danger is that wiseguys will send
obnoxious sound to someone else's machine, antisocial behaviour should
provoke social response.
If a colleague does it, tell him to stop.
If an employee does it, fire him after the third offense.
If your child does it, increase his allowance.
--
David A. De Graaf DATIX, Inc. Hendersonville, NC
dad(a)datix.us www.datix.us
3:49 p.m.
On Tue, Nov 18, 2008 at 3:12 PM, David A. De Graaf <dad(a)datix.us> wrote:
+1
I assume this isn't a priority because "real servers don't need sound",
so
just punt it to the desktop. Same for NetworkManager vs network.
(btw - it doesn't help seeing pulseaudio sucking ~30% of the CPU while
playing video on 'underpowered' netbooks)
--
Jason "zcat" Farrell
My minimal expectations are simple:
...
Availability of sound should most certainly not depend on X.
4:11 p.m.
David A. De Graaf wrote:
On Mon, Nov 17, 2008 at 06:11:04PM -0700, Michal Jaegermann wrote:
> On Mon, Nov 17, 2008 at 05:27:03PM -0500, David A. De Graaf wrote:
>
>
>> Pulseaudio is a travesty and abomination.
>>
> That sounds a bit too overgeneralized;
>
Michal Jaegermann:
Thank you for your calming, rational and helpful reply.
My previous rant against pulseaudio was misdirected.
Pulseaudio works perfectly well - there is no need to remove the
alsa-plugins-pulseaudio package - but the "security" restrictions
surrounding it are onerous and inappropriate for the default setup (in my
opinion). Overcoming these restrictions is obscure and unnecessesarily
difficult and is likely to discourage Fedora users who are unwilling
to discover the secret handshake. This default configuration is
inappropriate. It can and should be made more user-friendly.
My minimal expectations are simple:
1) aplay should be able to make a sound before anyone has logged in.
2) sound should be available to all users both at a console
and in X - xfce, gnome, kde or any other graphical environment.
This includes allowing crontab entries to make sounds, regardless of
who's logged in.
Availability of sound should most certainly not depend on X.
This implies that the pulseaudio daemon must be started at bootup,
preferably as a regular system service, and that the sound device files
should be accessible by anyone.
Here are the changes needed for sound to work for me.
First, make sure the soundcard works. In most cases, the proper
driver module will be installed automatically. But for my Asus N10JA2
netbook with Audio device: Intel Corporation 82801G (ICH7 Family)
High Definition Audio Controller (rev 02) it was necessary to add this
line to /etc/modprobe.conf:
options snd-hda-intel model=3stack-dig
1) Edit /etc/group, adding every user to group pulse-access, or at
least every user that will be permitted to enjoy the sound system.
Be sure to include root.
pulse-access:x:495:root,dad,srd
2) To relax the restrictions that block users from using the sound
system, create a new file, /etc/security/console.perms.d/80-sound.perms
# define the sound device class
<sound>=/dev/snd/*
# permissions
<console> 0666 <sound> 0666
This allows the sound devices to be accessible to all users.
3) Start a system-wide pulseaudio daemon by adding lines to
/etc/rc.d/rc.local. The daemon starts before anyone has logged in,
and runs forever.
/usr/bin/pulseaudio -D --system --log-level=3 --log-target=syslog
/usr/bin/aplay /usr/share/sounds/startup3.wav
4) Prevent xfce from starting another redundant pulseaudio process.
Edit /etc/xdg/xfce4/xinitrc to comment out these lines:
## if test x"`which pulseaudio 2>/dev/null`" != x""; then
## pulseaudio -D &
## fi
If anyone can explain why this is not an appropriate default setup for
Fedora, I would love to hear it.
FC10/KDE
I tried your setting and sound works okay on eeePC 702 , but the Mic
Capture keep shutting off
I set sound settings in gnome-volume-control, including enabling tab
Recording Capture Mic but it keeps disabling it so I can't get the mic
to work.
In Playback Microphone is enabled
7:24 p.m.
David A. De Graaf wrote:
If anyone can explain why this is not an appropriate default setup
for
Fedora, I would love to hear it.
Much of the decisions have been discussed in fedora-devel list. I
suggest you read the archives and post there if you want a answer to
your question. I don't think Lennart, the primary developer of
PulseAudio is subscribed to list at all.
Also note that ConsoleKit is setting device permissions IIRC for
security reasons and PulseAudio is merely relying on the common framework.
Rahul
7:16 a.m.
David A. De Graaf wrote:
I've finally achieved glorious loud sound on my Asus N10JA3
netbook
running Fedora 10 and XFCE - a struggle against enormous odds.
...
2) Deactivate pulseaudio by removing one package:
rpm -e alsa-plugins-pulseaudio
...
As a matter of interest, does one actually have to remove pulseaudio
to stop it?
Why can it not be turned on and off with chkconfig like other daemons?
I don't actually feel as strongly about pulse as others do,
but I'd like to be able to see how things work with and without it,
without calling on "yum remove".
12:08 p.m.
On Tue, Nov 18, 2008 at 01:16:19PM +0000, Timothy Murphy wrote:
As a matter of interest, does one actually have to remove pulseaudio
to stop it?
Why can it not be turned on and off with chkconfig like other daemons?
It is not started like other daemons. It is not even written in
such way that starting it like now and as a system daemon, which is
possible, are equivalent. That thingy starts as a side effect of
your desktop session or otherwise you have to perform some "magic".
IMO a trend of tying up to a desktop session various things needed
for a proper operations of a system is severly misguided.
Michal
1:23 p.m.
David A. De Graaf wrote:
It's probably too late to matter, but here's my reaction to
F10:
I've recently installed Fedora 10 Live onto my new Asus N10J-A2
netbook and am not happy with the experience. I am very sad to see
the direction that Fedora is taking toward making it more Windows-like
and disregarding important *NIX precepts. I especially deplore the
trend toward forcing use of Gnome instead of properly treating X as just
another utility that may or may not be useful. I happen to dislike Gnome
and use XFCE in its place, but start it only when I deem it worthwhile.
It would just be easier to start off with the Xfce live cd in this case.
Rahul
2:19 p.m.
On Wed, Nov 19, 2008 at 12:53:51AM +0530, Rahul Sundaram wrote:
David A. De Graaf wrote:
>
> I've recently installed Fedora 10 Live onto my new Asus N10J-A2
It would just be easier to start off with the Xfce live cd in this case.
Rahul
I agree completely. I did try to use your Xfce Live iso, but after
two days, bittorrent stopped at 99% and simply wouldn't deliver the
last bits.
I'm a big fan of your work to create a Live F10 Xfce iso, but I wish
there were a way to download it directly.
--
David A. De Graaf DATIX, Inc. Hendersonville, NC
dad(a)datix.us www.datix.us
7:09 p.m.
David A. De Graaf wrote:
On Wed, Nov 19, 2008 at 12:53:51AM +0530, Rahul Sundaram wrote:
> David A. De Graaf wrote:
>> I've recently installed Fedora 10 Live onto my new Asus N10J-A2
> It would just be easier to start off with the Xfce live cd in this case.
>
> Rahul
I agree completely. I did try to use your Xfce Live iso, but after
two days, bittorrent stopped at 99% and simply wouldn't deliver the
last bits.
I'm a big fan of your work to create a Live F10 Xfce iso, but I wish
there were a way to download it directly.
I can try and make it available in a ftp server but it won't be
official. You can also use the kickstart file to regenerate the live cd
locally.
Rahul
5630
days inactive
5634
days old
21 comments
12 participants
participants (12)
-
Anne Wilson -
cornel panceac -
David A. De Graaf -
Development discussions related to Fedora -
Jason Farrell -
Jerry Amundson -
Jim -
Michal Jaegermann -
Rahul Sundaram -
Rares Aioanei -
Scott Robbins -
Timothy Murphy