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.
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.
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.
On Mon, Nov 17, 2008 at 05:27:03PM -0500, David A. De Graaf wrote:
- 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
On Tue, Nov 18, 2008 at 3:11 AM, Michal Jaegermann michal@harddata.comwrote:
On Mon, Nov 17, 2008 at 05:27:03PM -0500, David A. De Graaf wrote:
- 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@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
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.
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
On Tue, Nov 18, 2008 at 6:59 AM, Anne Wilson cannewilson@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
2008/11/18 Jerry Amundson jamundso@gmail.com
On Tue, Nov 18, 2008 at 6:59 AM, Anne Wilson cannewilson@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@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
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.
On Tue, Nov 18, 2008 at 03:12:58PM -0500, David A. De Graaf wrote:
- 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'.
- 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.
- 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
- 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
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:
- 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".
- 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.
On Tue, Nov 18, 2008 at 3:12 PM, David A. De Graaf dad@datix.us wrote:
My minimal expectations are simple: ...
Availability of sound should most certainly not depend on X.
+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
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:
aplay should be able to make a sound before anyone has logged in.
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
- 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
- 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.
- 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
- 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
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
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.
...
- 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".
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
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
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 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