Fedora 9 Alpha Link

[Demz]

hope this works for some people , i just found a leak :) http://spreader.yandex.net/fedora/linux/releases/test/

http://spreader.yandex.net/fedora/linux/releases/test/9-Alpha/Fedora/i386/iso/Fedora-9-Alpha-i386-DVD.iso
http://spreader.yandex.net/fedora/linux/releases/test/9-Alpha/Fedora/i386/iso/Fedora-9-Alpha-i386-disc1.iso
http://spreader.yandex.net/fedora/linux/releases/test/9-Alpha/Fedora/i386/iso/Fedora-9-Alpha-i386-disc2.iso
http://spreader.yandex.net/fedora/linux/releases/test/9-Alpha/Fedora/i386/iso/Fedora-9-Alpha-i386-disc3.iso
http://spreader.yandex.net/fedora/linux/releases/test/9-Alpha/Fedora/i386/iso/Fedora-9-Alpha-i386-disc4.iso
http://spreader.yandex.net/fedora/linux/releases/test/9-Alpha/Fedora/i386/iso/Fedora-9-Alpha-i386-disc5.iso
http://spreader.yandex.net/fedora/linux/releases/test/9-Alpha/Fedora/i386/iso/Fedora-9-Alpha-i386-disc6.iso
http://spreader.yandex.net/fedora/linux/releases/test/9-Alpha/Fedora/i386/iso/Fedora-9-Alpha-i386-rescuecd.iso
http://spreader.yandex.net/fedora/linux/releases/test/9-Alpha/Fedora/i386/iso/SHA1SUM

http://spreader.yandex.net/fedora/linux/releases/test/9-Alpha/Fedora/x86_64/iso/Fedora-9-Alpha-x86_64-DVD.iso
http://spreader.yandex.net/fedora/linux/releases/test/9-Alpha/Fedora/x86_64/iso/Fedora-9-Alpha-x86_64-disc1.iso
http://spreader.yandex.net/fedora/linux/releases/test/9-Alpha/Fedora/x86_64/iso/Fedora-9-Alpha-x86_64-disc2.iso
http://spreader.yandex.net/fedora/linux/releases/test/9-Alpha/Fedora/x86_64/iso/Fedora-9-Alpha-x86_64-disc3.iso
http://spreader.yandex.net/fedora/linux/releases/test/9-Alpha/Fedora/x86_64/iso/Fedora-9-Alpha-x86_64-disc4.iso
http://spreader.yandex.net/fedora/linux/releases/test/9-Alpha/Fedora/x86_64/iso/Fedora-9-Alpha-x86_64-disc5.iso
http://spreader.yandex.net/fedora/linux/releases/test/9-Alpha/Fedora/x86_64/iso/Fedora-9-Alpha-x86_64-disc6.iso
http://spreader.yandex.net/fedora/linux/releases/test/9-Alpha/Fedora/x86_64/iso/Fedora-9-Alpha-x86_64-disc7.iso
http://spreader.yandex.net/fedora/linux/releases/test/9-Alpha/Fedora/x86_64/iso/Fedora-9-Alpha-x86_64-rescuecd.iso
http://spreader.yandex.net/fedora/linux/releases/test/9-Alpha/Fedora/x86_64/iso/SHA1SUM

http://spreader.yandex.net/fedora/linux/releases/test/9-Alpha/Live/i686/Fedora-9-Alpha-Live-KDE-i686.iso
http://spreader.yandex.net/fedora/linux/releases/test/9-Alpha/Live/i686/Fedora-9-Alpha-Live-i686.iso
http://spreader.yandex.net/fedora/linux/releases/test/9-Alpha/Live/i686/SHA1SUM

http://spreader.yandex.net/fedora/linux/releases/test/9-Alpha/Live/x86_64/Fedora-9-Alpha-Live-KDE-x86_64.iso
http://spreader.yandex.net/fedora/linux/releases/test/9-Alpha/Live/x86_64/Fedora-9-Alpha-Live-x86_64.iso
http://spreader.yandex.net/fedora/linux/releases/test/9-Alpha/Live/x86_64/SHA1SUM

[Jags_FL]

Thanks Demz

So its you not Firewing1 this time ... :)

[strikeforce]

http://lewk.org/blog/f8-f9alpha-livediff

If you want to see a list of packages.

Kudos I'll be trying it out.

[bob]

You guys are so BAD! :rolleyes: (downloading now....) :D

[stefan1975]

hi all,

anyone got any feedback on the 9 alpha? I am running F8 right now and rather disappointed with it so I am hoping this will solve some of my(performance) issues.

is there any way to upgrade F8 to F9 alpha byt the way or do I still have to download the install iso?

thanks,
stefan

[leigh123linux]

hi all,

anyone got any feedback on the 9 alpha? I am running F8 right now and rather disappointed with it so I am hoping this will solve some of my(performance) issues.

is there any way to upgrade F8 to F9 alpha byt the way or do I still have to download the install iso?

thanks,
stefan

Rawhide is sluggish :( , so I doubt that you will fix your performance issues by running F9 alpha !!

[JN4OldSchool]

Rawhide is sluggish :( , so I doubt that you will fix your performance issues by running F9 alpha !!

Is this just a product of you running KDE4 or have you used gnome also on the latest? Has this been a trend from the beginning and what are your thoughts on them improving it towards the end of the development cycle? I am DLing the DVD iso now, I will probably also try the live KDE version. I also noticed the first KDE 4 release was not only sluggish, but almost unresponsive at times. I chalked this up to the KDE factor.

[scottro]

One issue I had when trying to do some minimal installs (by installing F8, then running update after enabling devel) is that I was once again having trouble with the AR5007EG card. It *might* be tied to ConsoleKit in some obscure way. (Anyone interested, do a search with keywords interesting and rawhide.) I didn't notice any real difference in performance, but these were just test installs.

[leigh123linux]

Is this just a product of you running KDE4 or have you used gnome also on the latest? Has this been a trend from the beginning and what are your thoughts on them improving it towards the end of the development cycle? I am DLing the DVD iso now, I will probably also try the live KDE version. I also noticed the first KDE 4 release was not only sluggish, but almost unresponsive at times. I chalked this up to the KDE factor.



On my Rawhide install I have Gnome, KDE4 & XFCE and they all run slow , I had similar issues with F8 test 1 but it was sorted out by test 3 so I expect F9 beta will be quicker .

[stefan1975]

Rawhide is sluggish :( , so I doubt that you will fix your performance issues by running F9 alpha !!

mmm that is just too bad. I am currently running F8_x64 and rather satisfied with the overall features but it is SOOooo slow for me and I believe that I have pretty decent hardware. I mean even starting gnome from GDM takes longer then a cold boot of my Arch linux E17 pc which is a elderly P4 with 512mb.

I was hoping that F9 would fix such things like real time app starting, faster X, faster boot, etc. Sometimes it makes me look at Arch for my main work laptop as well, though it does not offer pulseaudo, SELinux or extra-key-support out of the box.

I have read something about Ubuntu 8.04 doing prefetching by default which would speed it up considerably, does anyone know which technique this is, i have searched the specific kernel patches for Arch or Fedora but cannot find any nor do I know if it actually works and I really need an extra performance boost., Hell since the latest performace-pack even M$ Vitsa seems on par (speed wise that is) with F8.

cheers,
stefan.

[leigh123linux]

mmm that is just too bad. I am currently running F8_x64 and rather satisfied with the overall features but it is SOOooo slow for me and I believe that I have pretty decent hardware. I mean even starting gnome from GDM takes longer then a cold boot of my Arch linux E17 pc which is a elderly P4 with 512mb.

I was hoping that F9 would fix such things like real time app starting, faster X, faster boot, etc. Sometimes it makes me look at Arch for my main work laptop as well, though it does not offer pulseaudo, SELinux or extra-key-support out of the box.

I have read something about Ubuntu 8.04 doing prefetching by default which would speed it up considerably, does anyone know which technique this is, i have searched the specific kernel patches for Arch or Fedora but cannot find any nor do I know if it actually works and I really need an extra performance boost., Hell since the latest performace-pack even M$ Vitsa seems on par (speed wise that is) with F8.

cheers,
stefan.

Have you tried preload ?

su -
yum install preload
chkconfig --level 345 preload on
service preload restart

It should improve startup after 2-3 bootups


[root@localhost ~]# yum info preload
livna 100% |=========================| 2.1 kB 00:00
fedora 100% |=========================| 2.1 kB 00:00
fusion 100% |=========================| 951 B 00:00
updates 100% |=========================| 2.3 kB 00:00
Excluding Packages in global exclude list
Finished
Installed Packages
Name : preload
Arch : x86_64
Version: 0.4
Release: 5.fc8
Size : 81 k
Repo : installed
Summary: Preload is an adaptive readahead daemon
Description:
preload runs as a daemon and gathers information about processes running on
the system and shared-objects that they use. This information is saved in a
file to keep across runs of preload


[root@localhost ~]#

[strikeforce]

Preload will slow down your booting up but will speed up your loading up of applications after bootup. You can tweak it to not be as aggressive if you want.

[leigh123linux]

Preload will slow down your booting up but will speed up your loading up of applications after bootup. You can tweak it to not be as aggressive if you want.

I haven't noticed any slow down on bootup and Gnome seems to load quicker :cool:

[stefan1975]

I haven't noticed any slow down on bootup and Gnome seems to load quicker :cool:


i will give it a go then. hope it helps (a lot). it has been getting more annoying since I started noticing it and comparing it to other systems. OOo takes +15 seconds to load and FF2 around 10 seconds. Opera 9.5b seems a lot faster on my system and I cannot seem to get used to epiphany although it is much faster. I tried switching my F8 laptop to E17 but the repos available for that don't give me a very stable E17 experience (yes i know it is still beta but Elive and gOS are much more stable with E17).

preload is running now and i will decide what to do when I have it running for some weeks, i also enabled readahead early and late now. wait for F9 to come cheer me up, dive in the Arch way or perhaps give another Ubuntu LTS another go come april. The previous LTS wasnt all too bad either imho, not very fast either though. I probably won't go with those slackware based tiny distros, somehow I cannot grow fond of slack.

stefan

[leigh123linux]

i will give it a go then. hope it helps (a lot). it has been getting more annoying since I started noticing it and comparing it to other systems. OOo takes +15 seconds to load and FF2 around 10 seconds. Opera 9.5b seems a lot faster on my system and I cannot seem to get used to epiphany although it is much faster. I tried switching my F8 laptop to E17 but the repos available for that don't give me a very stable E17 experience (yes i know it is still beta but Elive and gOS are much more stable with E17).

preload is running now and i will decide what to do when I have it running for some weeks, i also enabled readahead early and late now. wait for F9 to come cheer me up, dive in the Arch way or perhaps give another Ubuntu LTS another go come april. The previous LTS wasnt all too bad either imho, not very fast either though. I probably won't go with those slackware based tiny distros, somehow I cannot grow fond of slack.

stefan

I think preload replaces readahead early ( as far as I know readahead early is going to be dropped from Fedora )

[glennzo]

Anyone have the Alpha installed and running yet? Disaster of sorts here. Installed it to /dev/sda6. The install appeared to go well but upon reboot things go very very badly. Somehow it loads my existing desktop from the install of Fedora 8 on /dev/sda5. Along the way there are many errors about how it can't load modules and can't find files. Things are pretty crossed up with the Alpha install. I copied my grub stuff from Fedora 8 over to the Alpha install of grub and can boot Fedora 8 and everything is OK. I'm having a hard time understanding just what the trouble is. Why does it start to boot and seemingly switch to loading all the Fedora 8 data? It's as if it's jumping over to /dev/sda5 somewhere along the way.

Edit: See anything wrong below with grub or fdisk? grub is the Fedora 9 alpha version.
default=1
timeout=30
splashimage=(hd0,5)/boot/grub/splash.xpm.gz
title Fedora 9 Alpha (2.6.24-2.fc9)
root (hd0,5)
kernel /boot/vmlinuz-2.6.24-2.fc9 ro root=LABEL=/ rhgb quiet
initrd /boot/initrd-2.6.24-2.fc9.img
title Fedora 8 (2.6.23.14-107.fc8)
root (hd0,4)
kernel /boot/vmlinuz-2.6.23.14-107.fc8 ro root=LABEL=/ rhgb quiet vga=791
initrd /boot/initrd-2.6.23.14-107.fc8.img
title Fedora 8 (2.6.23.9-85.fc8)
root (hd0,4)
kernel /boot/vmlinuz-2.6.23.9-85.fc8 ro root=LABEL=/ rhgb quiet vga=791
initrd /boot/initrd-2.6.23.9-85.fc8.img
title Windows Vista
rootnoverify (hd0,1)
chainloader +1
title Windows XP
rootnoverify (hd0,2)
chainloader +1
Disk /dev/sda: 160.0 GB, 160041885696 bytes
255 heads, 63 sectors/track, 19457 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0xb65eac19

Device Boot Start End Blocks Id System
/dev/sda1 1 192 1536000 27 Unknown
Partition 1 does not end on cylinder boundary.
/dev/sda2 * 192 13975 110712832 7 HPFS/NTFS
Partition 2 does not end on cylinder boundary.
/dev/sda3 13976 16586 20972857+ 7 HPFS/NTFS
/dev/sda4 16587 19457 23061307+ 5 Extended
/dev/sda5 16587 17891 10482381 83 Linux
/dev/sda6 17892 19196 10482381 83 Linux
/dev/sda7 19197 19457 2096451 82 Linux swap / Solaris

[glennzo]

When I edit grub to read root=LABEL=/12 the system errors out and stops booting. Here's the last few lines:
mount: could not find filesystem '/dev/root'
setuproot: moving /dev/ failed: no such file or directory
setuproot: error mounting /proc: no such file or directory
setuproot: error mounting /sys: no such file or directory
switchroot: mount failed: no such file or directory

Stops there. I have to shut the computer down.

[leigh123linux]

Anyone have the Alpha installed and running yet? Disaster of sorts here. Installed it to /dev/sda6. The install appeared to go well but upon reboot things go very very badly. Somehow it loads my existing desktop from the install of Fedora 8 on /dev/sda5. Along the way there are many errors about how it can't load modules and can't find files. Things are pretty crossed up with the Alpha install. I copied my grub stuff from Fedora 8 over to the Alpha install of grub and can boot Fedora 8 and everything is OK. I'm having a hard time understanding just what the trouble is. Why does it start to boot and seemingly switch to loading all the Fedora 8 data? It's as if it's jumping over to /dev/sda5 somewhere along the way.

Edit: See anything wrong below with grub or fdisk? grub is the Fedora 9 alpha version.
default=1
timeout=30
splashimage=(hd0,5)/boot/grub/splash.xpm.gz
title Fedora 9 Alpha (2.6.24-2.fc9)
root (hd0,5)
kernel /boot/vmlinuz-2.6.24-2.fc9 ro root=LABEL=/ rhgb quiet
initrd /boot/initrd-2.6.24-2.fc9.img
title Fedora 8 (2.6.23.14-107.fc8)
root (hd0,4)
kernel /boot/vmlinuz-2.6.23.14-107.fc8 ro root=LABEL=/ rhgb quiet vga=791
initrd /boot/initrd-2.6.23.14-107.fc8.img
title Fedora 8 (2.6.23.9-85.fc8)
root (hd0,4)
kernel /boot/vmlinuz-2.6.23.9-85.fc8 ro root=LABEL=/ rhgb quiet vga=791
initrd /boot/initrd-2.6.23.9-85.fc8.img
title Windows Vista
rootnoverify (hd0,1)
chainloader +1
title Windows XP
rootnoverify (hd0,2)
chainloader +1
Disk /dev/sda: 160.0 GB, 160041885696 bytes
255 heads, 63 sectors/track, 19457 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0xb65eac19

Device Boot Start End Blocks Id System
/dev/sda1 1 192 1536000 27 Unknown
Partition 1 does not end on cylinder boundary.
/dev/sda2 * 192 13975 110712832 7 HPFS/NTFS
Partition 2 does not end on cylinder boundary.
/dev/sda3 13976 16586 20972857+ 7 HPFS/NTFS
/dev/sda4 16587 19457 23061307+ 5 Extended
/dev/sda5 16587 17891 10482381 83 Linux
/dev/sda6 17892 19196 10482381 83 Linux
/dev/sda7 19197 19457 2096451 82 Linux swap / Solaris




Try relabeling it

su -
e2label /dev/sda6 /1

then change grub.conf to

default=1
timeout=30
splashimage=(hd0,5)/boot/grub/splash.xpm.gz
title Fedora 9 Alpha (2.6.24-2.fc9)
root (hd0,5)
kernel /boot/vmlinuz-2.6.24-2.fc9 ro root=LABEL=/1 rhgb quiet
initrd /boot/initrd-2.6.24-2.fc9.img
title Fedora 8 (2.6.23.14-107.fc8)
root (hd0,4)
kernel /boot/vmlinuz-2.6.23.14-107.fc8 ro root=LABEL=/ rhgb quiet vga=791
initrd /boot/initrd-2.6.23.14-107.fc8.img
title Fedora 8 (2.6.23.9-85.fc8)
root (hd0,4)
kernel /boot/vmlinuz-2.6.23.9-85.fc8 ro root=LABEL=/ rhgb quiet vga=791
initrd /boot/initrd-2.6.23.9-85.fc8.img
title Windows Vista
rootnoverify (hd0,1)
chainloader +1
title Windows XP
rootnoverify (hd0,2)
chainloader +1

[Demz]

Thanks Demz

So its you not Firewing1 this time ... :)
i just beat Firewing1 this time but he's usually busy these days with his other stuff

[glennzo]

Done deal Leigh. Thanks for the tip. Now Fedora 9 Alpha boots as it should.

[Demz]

any screenshots of this yet?

[glennzo]

any screenshots of this yet?I'm back in 8. No mouse in Fedora 9, wired or wireless (both usb) so my visit was short lived for now. But it looks like Fedora 8 to me.

Edit: Oh, but there's a whole new set of 'firstboot' screens. Whole new look there.

[leigh123linux]

Done deal Leigh. Thanks for the tip. Now Fedora 9 Alpha boots as it should.

I forgot to mention that you also needed to edit fstab .

[glennzo]

I forgot to mention that you also needed to edit fstab .Thanks again Leigh. Next time I boot to Alpha I'll have a look see.

[JN4OldSchool]

I'm back in 8. No mouse in Fedora 9, wired or wireless (both usb) so my visit was short lived for now. But it looks like Fedora 8 to me.

Edit: Oh, but there's a whole new set of 'firstboot' screens. Whole new look there.

Tried live gnome on the HP laptop and didnt have mouse either. Well, I had movement, just the old invisible cursor thing...Didnt mess with it...It did boot though!

[Iron_Mike]

OK, so where are the 1st reviews????

[Demz]

still nothing either on osnews or slashdot about reviews or no screeny's either, im just interested in seeing the new anaconda

[leigh123linux]

I can't see why they need to use the development version of the xorg server as I doubt Nvidia or ATI will ever support it . :rolleyes:
If they ship F9 with this version I doubt that I will ever bother to use it as it will be useless for my needs .
In Rawhide I upgraded xorg to the F8 version so I could use the Nvidia driver.

[bob]

Trying the X86_64 version for a change, and thanks to my wife's Xmas present of a DVD-RW, I'm using the DVD install. Went pretty smoothly, although there's a glitch on first login when you're presented with only 'Guest' and 'Other' and have to use root (other) to create your user account. Somehow, I think that problem will be fixed pretty quickly.

For now, sound works, video's okay and speed's at least on par with Fedora8, so I'll work through the 385 updates (one dependency error or it would be 386) and see how it goes. It's a spare partition on the drive after all, might as well put it to use.

[Demz]

from there Feature list they will go to Xorg-server1.5 but if they do have a plan

Contingency Plan


Most of the above features are separable, and can be turned off if they're looking catastrophic. though i dont know why they wouldnt just fall back to Xorg 1.4/7.3

here's some KDE screenshots i found of Fedora9 Alpha http://www.phoronix.com/scan.php?page=article&item=992&num=1

also here's some Gnome Screeny's to.. http://www.phoronix.com/scan.php?page=article&item=991&num=1

Just noticed, there not using the Echo-Icon-Theme in this? or can we expect this in either of the beta's

[Thetargos]

For the longest time Fedora Alpha releases have been sluggish, they are built with all debug symbols compiled, which causes a sensible loss of performance in many instances for the many programs of the distro. This is so that bug-buddy tracebacks could be submitted directly (I believe) or at the very least that they could be used as dumps for reporting bugs to the -devel list and bugzilla. Also by default Fedora pre-releases do not use the 'silent' kernel command line parameter to make it easier to debug or spot potential problems with the distro.

Stefan, there are many, many factors affecting "performance", among them even your definition of "performance". Desktop performance has been very hard to test in Linux for the longest time, and one one area where interest from many parties (particularly those at the kernel level). I can tell you a ton of stuff that affects performance in terms of interactivity in the desktop, but paradoxically don't affect the real performance for other applications (for instance kernel preemptive-ness, task scheduling, tick rate, API speed, etc.), then there's the issue of the hardware support. Even though you may be running fairly decent hardware, some parts of it (especially hard disks and HDD controllers) can greatly affect stuff like loading times for both the system, applications and file transactions. This may be due to a number of factors: The driver for the controller, the controller doesn't like the disk, the BIOS gets some disk parameters wrong, the disks isn't as fast as it should (like it is the case with early S-ATA drives which were actually PATA drives with an S-ATA connector, yielding very poor performance, even if the controller used UDMA6 mode).

You may always want to build your own kernel with some performance hacks to try and squeeze as much performance out of it as you could, if you are so inclined to.

[RupertPupkin]

Aw man, I thought this was announcing a Fedora 9 release for the Alpha platform. Red Hat used to support Alpha (and SPARC). Imagine my disappointment when I found out what this really was. :(

Just out of curioisty, is anyone here running Linux on an Alpha box?

[glennzo]

I forgot to mention that you also needed to edit fstab .What do I need to edit in that file?
LABEL=/ <--- This? / ext3 defaults 1 1
tmpfs /dev/shm tmpfs defaults 0 0
devpts /dev/pts devpts gid=5,mode=620 0 0
sysfs /sys sysfs defaults 0 0
proc /proc proc defaults 0 0
/dev/sda7 swap swap defaults 0 0

[stefan1975]

For the longest time Fedora Alpha releases have been sluggish, they are built with all debug symbols compiled, which causes a sensible loss of performance in many instances for the many programs of the distro. This is so that bug-buddy tracebacks could be submitted directly (I believe) or at the very least that they could be used as dumps for reporting bugs to the -devel list and bugzilla. Also by default Fedora pre-releases do not use the 'silent' kernel command line parameter to make it easier to debug or spot potential problems with the distro.

Stefan, there are many, many factors affecting "performance", among them even your definition of "performance". Desktop performance has been very hard to test in Linux for the longest time, and one one area where interest from many parties (particularly those at the kernel level). I can tell you a ton of stuff that affects performance in terms of interactivity in the desktop, but paradoxically don't affect the real performance for other applications (for instance kernel preemptive-ness, task scheduling, tick rate, API speed, etc.), then there's the issue of the hardware support. Even though you may be running fairly decent hardware, some parts of it (especially hard disks and HDD controllers) can greatly affect stuff like loading times for both the system, applications and file transactions. This may be due to a number of factors: The driver for the controller, the controller doesn't like the disk, the BIOS gets some disk parameters wrong, the disks isn't as fast as it should (like it is the case with early S-ATA drives which were actually PATA drives with an S-ATA connector, yielding very poor performance, even if the controller used UDMA6 mode).

You may always want to build your own kernel with some performance hacks to try and squeeze as much performance out of it as you could, if you are so inclined to.

Hi,

thanks for the elaborate reply! I know there are many things that can influence the overall performance and then still performance is subjective and in the eye of the beholder, further comparing M$ Vitsa performance to linux is apples and pears as well. However imho linux is linux on any distro. Of course there are differences in started deamons at runtime, the compile flags are different, gentoo compiles everything at you local platform, you can compile i386, i686 or x64 but generally speaking 2.6.24 kernel is the same across distros and the main thing that sets them apart is the extras they slap on, the service, the theming and the intended user group.

Ubuntu is more geared towards the end user and starts everything which does make it the fastest kid on the block, fedora is a good middle ground with more emphasis on the user, the security and innovation whereas with Arch you mainly have to build your own system.

However I have still noticed Extreme differences in performance between in my case Arch and F8. Even running the same kernel, the same hardware (with a fast HDD by the way) and the same apps. I mean starting gnome in 45 seconds from GDM or cold boot to working desktop in the same time is a big difference, admitted that Arch does not run SElinux in my case but I do use a firewall, HAL, etc. Real time app startup of for example Firefox in 10+ seconds compared to 3 is also a sizable difference. Vector and Zenwalk were even faster but I don't like the general feel of those distros.

So i can relate to you where you say that drivers e.a. can influence the performance but the hardware support in the kernel accross distros is the same imho.

thanks again,
stefan.

[leigh123linux]

What do I need to edit in that file?
LABEL=/ <--- This? / ext3 defaults 1 1
tmpfs /dev/shm tmpfs defaults 0 0
devpts /dev/pts devpts gid=5,mode=620 0 0
sysfs /sys sysfs defaults 0 0
proc /proc proc defaults 0 0
/dev/sda7 swap swap defaults 0 0


Yes change it to match the new LABEL name

LABEL=/1 / ext3 defaults 1 1

[Thetargos]

Hi,

thanks for the elaborate reply! I know there are many things that can influence the overall performance and then still performance is subjective and in the eye of the beholder, further comparing M$ Vitsa performance to linux is apples and pears as well. However imho linux is linux on any distro. Of course there are differences in started deamons at runtime, the compile flags are different, gentoo compiles everything at you local platform, you can compile i386, i686 or x64 but generally speaking 2.6.24 kernel is the same across distros and the main thing that sets them apart is the extras they slap on, the service, the theming and the intended user group.

Ubuntu is more geared towards the end user and starts everything which does make it the fastest kid on the block, fedora is a good middle ground with more emphasis on the user, the security and innovation whereas with Arch you mainly have to build your own system.

However I have still noticed Extreme differences in performance between in my case Arch and F8. Even running the same kernel, the same hardware (with a fast HDD by the way) and the same apps. I mean starting gnome in 45 seconds from GDM or cold boot to working desktop in the same time is a big difference, admitted that Arch does not run SElinux in my case but I do use a firewall, HAL, etc. Real time app startup of for example Firefox in 10+ seconds compared to 3 is also a sizable difference. Vector and Zenwalk were even faster but I don't like the general feel of those distros.

So i can relate to you where you say that drivers e.a. can influence the performance but the hardware support in the kernel accross distros is the same imho.

thanks again,
stefan.
Even if you compare the very same kernel on different distros (custom built with the very same config options on both sides) there are another number of factors affecting performance. I really find it strange, for example, that GNOME would take so long to load from GDM, it only takes about 10 secs on my machine, so it may very well be SELinux the culprit (you can always try disabling it and seeing if that has any impact). Another thing that you rightly so bring up is Firefox. Firefox in Fedora is well known to be bloated. The sheer number of "extensions" added, plus other "tweaks" make it very slow to cold start. You can always install swift-fox, or if you are so inclined, rebuild the .src.rpm without the bloat, or simply build from source and squeeze as much performance out of it as you can (what swift-fox actually does). One of the particular areas that Firefox differs from many other distros in Fedora is its internationalization support, while many others only support one or at most four or five languages, Firefox in Fedora supports pretty much all languages supported by Fedora... At a cost (apparently).

I do agree with you about many flaky points performance wise (perceptually, at least) in Fedora, however, in my experience Fedora yields better performance for 3D apps, HDD transfer rates, and memory operations (tested with ramspeed) than other distros (most prominently Ubuntu, in my case). Also GNOME's UI at default is "faster" in Fedora than Ubuntu (again, at least in my experience), particularly window dragging (no window border traces), transparent console window dragging ("background" moving seamlessly, minimum to no tearing), etc, etc. Some parts of GTK or at least GNOME's implementation seem slower than other toolkits/DE's (for example QT/KDE or XFCE, which also uses GTK). There are a number of "tests" you can run on your systems to see how Fedora compares to Arch (for example) in regards to what you find it flaky. Again, that loading time of GNOME in your F8 doesn't look normal at all.

[strikeforce]

http://www.phoronix.com/scan.php?page=article&item=992&num=1

Screenshots for those non-KDE users to see what KDE4 is all about.

IMO it is **** HOT.

[FriedChips]

The only thing that has me with rawhide is that I cannot install the nvidia proprietary driver... Maybe this is different for you guys since you downloaded this, I actually updated a x86_64 F8 system to rawhide. If anyone has any suggestions for a workaround let me know. The other thing that is bothering me is that if I delete something off the desktop in KDE4 it is not actually deleted so it will show back up on the desktop after a reboot. Anyone else seeing this?

[strikeforce]

Have you enabled the livna-development repo?

[leigh123linux]

The only thing that has me with rawhide is that I cannot install the nvidia proprietary driver... Maybe this is different for you guys since you downloaded this, I actually updated a x86_64 F8 system to rawhide. If anyone has any suggestions for a workaround let me know. The other thing that is bothering me is that if I delete something off the desktop in KDE4 it is not actually deleted so it will show back up on the desktop after a reboot. Anyone else seeing this?

I think you will need to upgrade the xorg server to the F8 version ( as I believe nvidia still refuse to support development versions of xorg ) for the nvidia driver to work ( plus I think they don't maintain kmods for Rawhide )
I use a dkms based nvidia driver in Rawhide .

[JN4OldSchool]

I think you will need to upgrade the xorg server to the F8 version ( as I believe nvidia still refuse to support development versions of xorg ) for the nvidia driver to work ( plus I think they don't maintain kmods for Rawhide )
I use a dkms based nvidia driver in Rawhide .

Didnt you say this earlier? :p

[FriedChips]

I tried to "downgrade" to F8 xorg, no go, replaced the packages and restarted the xserver but, it wouldn't go, no error messages or anything... I don't mind using the "official package" from nvidia. I just can't get back to the old xorg server and still have it work.. Maybe I'll give it another go and start a thread on the issues I see.

[bob]

Interesting! Gnome's working okay on X86_64, however I did a groupinstall KDE and it fails to start, throwing this response into /var/log/messages:

Feb 6 12:00:34 localhost gdm-simple-slave[2865]: DEBUG: GreeterServer: Stopping greeter server...
Feb 6 12:00:34 localhost console-kit-daemon[2309]: WARNING: Unable to open directory /etc/ConsoleKit/run-session.d: Error opening directory '/etc/ConsoleKit/run-sessio
n.d': No such file or directory
Feb 6 12:00:34 localhost console-kit-daemon[2309]: WARNING: Unable to open directory /usr/lib64/ConsoleKit/run-session.d: Error opening directory '/usr/lib64/ConsoleKi
t/run-session.d': No such file or directory
Feb 6 12:00:34 localhost console-kit-daemon[2309]: WARNING: Cannot create file /var/run/ConsoleKit/database~: No such file or directory
Feb 6 12:00:34 localhost console-kit-daemon[2309]: WARNING: Cannot unlink /var/run/ConsoleKit/database: No such file or directory
Feb 6 12:00:34 localhost console-kit-daemon[2309]: WARNING: Unable to open directory /etc/ConsoleKit/run-session.d: Error opening directory '/etc/ConsoleKit/run-sessio
n.d': No such file or directory
Feb 6 12:00:34 localhost console-kit-daemon[2309]: WARNING: Unable to open directory /usr/lib64/ConsoleKit/run-session.d: Error opening directory '/usr/lib64/ConsoleKi
t/run-session.d': No such file or directory
Feb 6 12:00:34 localhost console-kit-daemon[2309]: WARNING: Cannot create file /var/run/ConsoleKit/database~: No such file or directory
Feb 6 12:00:34 localhost console-kit-daemon[2309]: WARNING: Cannot unlink /var/run/ConsoleKit/database: No such file or directory
Feb 6 12:00:34 localhost gdm-simple-slave[2865]: DEBUG: GreeterServer: obj_path=/org/freedesktop/DBus/Local interface=org.freedesktop.DBus.Local method=Disconnected
Feb 6 12:00:34 localhost gdm-simple-slave[2865]: DEBUG: GreeterServer: Disconnected

The one update that failed is:
---> Package xorg-x11-xinit.x86_64 0:1.0.7-3.fc9 set to be updated
--> Processing Conflict: xorg-x11-xinit conflicts dbus < 1.1.4-3.fc9

I wonder if there's a connection or whether this might end up at Bugzilla.

[rjstaaf]

Bob,

I got the same conflict on xorg-x11-xinit so I just excluded it and the updates were still running when I had to leave for work this morning. It was a network install and I did not customize any of the default package selections although I did remove alot before I started the update. I think there were still 297 updates.

I guess we will see if the machine blew up when I get home tonight :D

[RahulSundaram]

Interesting! Gnome's working okay on X86_64, however I did a groupinstall KDE and it fails to start, throwing this response into /var/log/messages:



The one update that failed is:


I wonder if there's a connection or whether this might end up at Bugzilla.

A new dbus is going to be pushed out soon which will fix this issue.

[sideways]

Is the kernel-devel rpm included in the alpha release?

I've declined from participating in alpha/beta testing in Fedora since they decided to not include it a while back. (It's too much trouble for me to get internet access working otherwise - "too much trouble" = "I can't be bothered")

[RahulSundaram]

I can't see why they need to use the development version of the xorg server as I doubt Nvidia or ATI will ever support it . :rolleyes:
If they ship F9 with this version I doubt that I will ever bother to use it as it will be useless for my needs .
In Rawhide I upgraded xorg to the F8 version so I could use the Nvidia driver.

We need to use the latest development versions to get feedback and fix things before it goes stable. That's the whole point of the development cycle. Otherwise we can't ever move to the next Xorg, GCC, Kernel etc.

[Thetargos]

"include" how? Aren't you able to simply go fetch it from your current working networked installation and then install it to build whatever driver you need? I just recently put together a FrankenPC just for the purpose of testing F9 and upcoming releases on it, I too can't be left without my main rig for testing out things, which is why I hunted down a number of unused parts I had laying around and built the machine (I was missing a case, so I had to get one $20 bucks for a testing system wasn't too bad, IMO)

[Thetargos]

I can't see why they need to use the development version of the xorg server as I doubt Nvidia or ATI will ever support it . :rolleyes:
If they ship F9 with this version I doubt that I will ever bother to use it as it will be useless for my needs .
In Rawhide I upgraded xorg to the F8 version so I could use the Nvidia driver.
Indeed... But that's part of the need for these companies to provide at least some parts as open source. Good thing AMD has already started (there's a long way to go still, but at least they're doing their part). I doubt nVidia will follow any time soon, though you can never know, it does seems like this move has been paying well to AMD where it counts: units sold.

[RahulSundaram]

Is the kernel-devel rpm included in the alpha release?

I've declined from participating in alpha/beta testing in Fedora since they decided to not include it a while back. (It's too much trouble for me to get internet access working otherwise - "too much trouble" = "I can't be bothered")

There is no explicit decision to exclude it. I just talked to rel-eng folks. If you want kernel-devel package included, do file a bug report against distribution in http://bugzilla.redhat.com. It won't be installed by default but can be made available in the DVD image if there is a real need for it.

[leigh123linux]

We need to use the latest development versions to get feedback and fix things before it goes stable. That's the whole point of the development cycle. Otherwise we can't ever move to the next Xorg, GCC, Kernel etc.

I know this is true but I can't live without 3D accelerated graphics , I have tried the nouveau driver but it is no better than the nv driver at the moment ( I hope this will improve with time ).
It would be great if Nvidia could release enough details to the nouveau project so they could get 3D working but I doubt this will ever happen ( instead they are forced to try and reverse engineer a driver ) .
I have no problem with testing the latest kernels or GCC .
It was a shame that xorg 1.4 was so badly flawed that it was unusable .

[bob]

Oopsie! :eek: Well, as promised, the dependency issue was cleared up, however 1). I'm still not able to enter KDE; same results. 2). Now my network connection's borked. I'm on perhaps the easiest setup, plain old Roadrunner cable, yet it's now broken and 'system-config-network' gives no joy. "***glibc detected*** /sbin/dhclient: double free or corruption (!prev): 0x0000000000684a20 ***" followed by a lengthy backtrace. Ah well, might be time to hang it up. :(

[RahulSundaram]

1) Try setting SELinux to permissive. We need to fix policies. Bug reports on that would be useful. Also if you are starting from GDM or KDM, try to get to runlevel 3 and run startkde from there. It should work. KDE 4.0 is a bit unpolished and a new update to KDE 4.0.1 has been pushed to rawhide. Make sure you have the latest version

2) Please file the bug report with the traceback against system-config-network. Try if NetworkManager works better too.

[bob]

Sorry, Rahul, but no joy on either of those. Setting SELinux to permissive does not restore the network even on reboot and system-config-network restart fails. Also, changing to init3 after booting and removing the .tmp X0-lock means that startx fails, even as root, not just as KDE but also as Gnome. I'll have to drag & burn the backtrace to Fedora8 to file a bugzilla. As long as I'm wasting a CD on this, anything else that might be helpful? Dmesg? /var/log/messages? Might as well lump it all together.

[RahulSundaram]

Hi

# sysreport

That should collect everything that you would need.

[bob]

Okay, will do tomorrow. Update, BTW, strangely, KDE now loads from init5 (normally, in other words). Finally just loaded. Why? Who knows...? Anyway, eth0 is still dead to the world and even disabling SELinux completely won't restore it. The failure's noted right in the boot messages.

[scottro]

I note you're having the same ConsoleKit error that I had when I was playing with rawhide last week. In my case, I put it down to trying to do a minimal install. Afterwards, even when I added ConsoleKit, it didn't add an /etc/init.d script and continued to give those same errors of no such file or directory.
The only thing that was affected, however, was my Atheros 5007EG wireless card, which was using a module built from a madwifi snapshot plus a patch.

I don't really have time to help test this week, but I did find with various random custom installs that whenever there was no ConsoleKit init.d script, other things, seemingly completely unconnected, failed to work. Ever since ConsoleKit got tied to whether sound works or not, however, I tend to blame it too much.

[scottro]

To add a bit, I tried installing it tonight. I downloaded the DVD to hard drive then booted from a rescue CD which I also downloaded.
To my surprise, the graphic installer didn't work--it would get a screen but nothing on the screen was legible. It's an Acer 4720z laptop, Intel GM695/GL960 chipset.

Judging from my experience with the live KDE 4 CD, doing a trial upgrade from an install of F8 and my experience with Fedora and video hardware in general, I suspect I could install in text mode and it would work. However, if it doesn't, I'd be aggravated, so I'll probably wait for the beta.

[Demz]

thats why i wanna wait for the Beta, plus iv'e read to many others are having Mouse problems . i think the Beta they'll have most fixed

[bob]

As info, bugzilla 431854 filed. I'll hang onto my installation for a few days and see what results come in. BTW, FedoraUnity is also announcing the Fedora 9 Alpha via Jigdo (just got an email).

[Iron_Mike]

Yeah, I hear ya. My networking is borked under 9. The devices show up under system-config-network but that's about it. One thing that become real obvious is that it assumed the desktop properties of my F8 that is installed on totally different partitions, weird.........

[Seve]

Hello:
Not that it helps, but the network is borked here as well with Alpha 9.
That is, as soon as I applied the updates ..... :eek:
Prior to that it was for the most part working well .. :)

Seve

[bob]

Ah well, it's an Alpha and I'm sure a fix will be out soon.

[nick.stumpos]

just got the alpha downloaded, installing as I type, but its sounding like it might not be worth the go, o well at least ill keep busy reporting bugs for a while.

[glennzo]

One thing that become real obvious is that it assumed the desktop properties of my F8 that is installed on totally different partitions, weird.........
Hi Iron Mike. Anything like my comments in post 16 and 17? Leigh's reply in post 18? I was booting Alpha and ending up with my Fedora 8 desktop.

[FriedChips]

Hi Iron Mike. Anything like my comments in post 16 and 17? Leigh's reply in post 18? I was booting Alpha and ending up with my Fedora 8 desktop.

I assume that you have double-checked your grub.conf?

[glennzo]

I assume that you have double-checked your grub.conf?
Was that question directed to me FriedChips? Yes, all fixed thanks to Leigh's guidance. It was fixed following his post #18 as I recall.

[Iron_Mike]

Hi Iron Mike. Anything like my comments in post 16 and 17? Leigh's reply in post 18? I was booting Alpha and ending up with my Fedora 8 desktop.

Hey Glennzo,

Same probs, the only difference is I was calling 9 alpha with the "chainloader +1" option

[bob]

BTW folks, the problem is with the dhclient-4.0.0.7.fc9 . I've grabbed the 4.0.0.6 from the mirrors and done a 'rpm -Uvh --force' to downgrade and I'm back online (typing from there right now). Whew! So, off to Bugzilla to post the results "fix".

Edit: Just an aside, but using yum is a bad option since it wants to remove 14 packages to get rid of dhclient; most of them critical. In this case, if you haven't added the 'allowdowngrade' option to yum, use the 'rpm' fix instead.

[stevea]

BTW folks, the problem is with the dhclient-4.0.0.7.fc9 . I've grabbed the 4.0.0.6 from the mirrors and done a 'rpm -Uvh --force' to downgrade and I'm back online (typing from there right now). Whew! So, off to Bugzilla to post the results "fix".

Edit: Just an aside, but using yum is a bad option since it wants to remove 14 packages to get rid of dhclient; most of them critical. In this case, if you haven't added the 'allowdowngrade' option to yum, use the 'rpm' fix instead.

Try the 4.0.0.9.fc9 , works for me.

[bob]

Okay then, we're WAY past the borked version. Good deal. I'll switch over and give an update another try.

[Seve]

Hello:
Does anyone notice a difference in boot times from F8 ?

Seve

[Demz]

should be a noticeable difference with bootup times, whether it shows in this Alpha i dont know but you might wanan read this Seve,,

http://fedoraproject.org/wiki/Features/Upstart

https://bugzilla.redhat.com/show_bug.cgi?id=429028

[Seve]

Hello Greg:
Thanks for the link :)

I was just wondering if users actually saw any difference ?

I see quite an improvement over F8. [64bit to 64bit]

Seve

[scottro]

Sigh, I should really be filing at bugzilla, but don't have the time right now to do enough background for it to be useful to them.
On the bright side, pulseaudio seems to more or less work out of the box, though I haven't installed mplayer because AFAIK, no livna repos yet.

The installer doesn't work for me. I have tried with a rescue cd from an iso burned to hard disk, then went so far as to download, burn and boot from disk one. As I said in an earlier post, when the GUI installer starts, it's just little splats of color on the screen. I then tried a text install, and it crashed. I haven't seen much mention of such a thing, so I'm guessing it's something funky with my acer.

So, I used the Live CD to install. After rebooting, I did yum update and it installed 2.6.24-2.fc9.
I then went to build my madwifi modules but there was no build directory in /usr/lib/modules/2.6.24-2.fc9. That directory is a link to /usr/src/kernels/<kernelversion>. It hadn't installed those kernel sources, though it installed the sources to 2.6.24-1.
So, I uninstalled 2.6.24.2 with rpm -e --nodeps, figuring I'd reinstall it. However, now yum doesn't show it as an available update. This is what I mean when I say I don't have time--if I had time to do proper research, I'd be googling for it and checking the repos, etc.

So, I rebooted into 2.6.24-1-26 or whatever it is (checks uname -a--yup, that's it.)
Built madwifi without issues. However, before I'd done that, on each boot, eth0 failed to get an address. After logging in, (I log into text mode) I had to manually run dhclient on it.

After getting the wireless installed, I did my usual adding sleep and dhclient ath0 to rc.local. However, the same issue with wireless. It boots and everything is fine however, ath0, the wireless, doesn't have an address. pkill dhclient, dhclient ath0 works without problems though.

So, I'll see what happens after a few upgrades. If I have time tomorrow night, maybe I'll do more research into the mysterious disappearance of kernel-2.6.24.2.fc9. Even trying to install it by name doesn't work. Peculiar--maybe it had serious problems and was removed in between my yum-ing.

Anyway, most things seem to be working save for the dhclient oddity. I'll have to check bugzilla tomorrow.

[Thetargos]

Didn't you install kernel-devel for 2.6.24.2? That's what creates the build link in /lib/modules/<kernel_version>. I don't quite follow the mysterious disappearance of 2.6.24.2, you mean is not present in yum? Why don't you just download it from a mirror through ftp/http, and install manually?

[scottro]

Well, here's what happened. After the first round of updates, after installation, I installed kernel-development and it was for 2.6.24.2.
However, there was no /usr/src/kernel/2.6.24.2 there, only the 2.6.24-1 whatever.

So, that's when I uninstalled 2.4.24.2 figuring I'd reinstall it and see what happened.

However, after uninstalling it, yum update didn't offer it as an option.

So, (to answer your question) I didn't download an rpm of 2.6.24.2 because I was going to go to sleep. However, not being sleepy, I tried doing that.
Here it became interesting.
rpm -Uvh 2.6.24-2-whatever
to receive a message that 2.6.24-1.whatever is already installed and is newer than 2.4.24.2.

So, at that point, I gave it up for tonight. I'm not sure what gives with that one, it's a bit odd. I might try a fresh install from the LiveCD tomorrow to see if I can duplicate this.

[ryptyde]

Running F9 Alpha Live from usb stick on an Acer laptop, pleasantly surprised to have most fn keys working. Connected wireless via a belkin usb dongle, sound works too! :)

[scottro]

Ok, this was intriguing me so I reinstalled.
The live CD installs the 2.4.24-2 kernel
Doing yum update kernel, however, says it will update to the 2.6.24.1.26. The other one is 2.4.24-2. (Note one has a dash, the other a period.)
So, it seems my issue with that was caused by misreading.

Ok, one problem solved. :) It's a bit confusing, but I'm guessing that 24-2 is older than 24.1-whatever.

Therefore, when I installed kernel-devel, it installed sources for the later kernel, which was the 2.6.24.1.

[scottro]

Updates on this.
The installer doesn't work for me (Acer Aspire 4720z). With a GUI, though it shows a screen, it just has little blotches. In textmode, anaconda exited with a fatal error.

In an earlier post I said pulse-audio seemed to work this time. My hypothesis is that if you boot into Gnome, it probably does, though you will be asked for the root password the first time. Personally, I feel it's not the best design decision, but that's an opinion.

When using fluxbox, it didn't work. I tried running rhythmbox and got various error messages. At that point I did my usual, uninstalled alsa-pulseaudio. It's quite possible a little effort would get it to work, but I really have no patience with it--they broke sound last year in November (all versions) and when people complain call it a design decision and close bugs saying it's a configuration error. It used to work with no effort--now it doesn't.

Interestingly enough, on this second install, once again, ConsoleKit didn't create a script in /etc/init.d, and I got those errors on boot, about being unable to open various ConsoleKit related files. The only difference between this install and the previous one, which didn't have that issue, was that I never booted into Gnome on this install.
Both installs were done from the LiveGnomeCD.

Aside from that, no major changes good or bad. I updated the kernel, installed my madwifi drivers from that patched snapshot for the 5007 and wireless worked. I don't use Network Manager, I use wpa_supplicant and add an rc.local series of commands--it used to be sleep 1 and then dhclient however, this time, dhclient seemed to have difficulty. Changing the sleep 1 to sleep 3 fixed it. (I noticed this with the wired ethernet card as well--it would boot and have no address and I'd have to run dhclient.)

Unfortunately, I don't see any real increase in boot time. I'm not sure if that is connected to the fact that I manually eliminate many default services, as if I understand what I've read, one way it saves time is to not call various services until they're needed.

All in all, it seems nice enough. I haven't started really playing with it yet, so haven't come across any noticeable differences from F8.
Everything seems to work as well as it did in F8. Sound has been a problem, as I said, since the decision to tie it into ConsoleKit.

[bob]

OMG, Tonight's 95 updates took 49 minutes to download and ended with:

Transaction Check Error:
file /usr/share/doc/lcms-1.17/TUTORIAL.TXT from install of lcms-1.17-3.fc9.x86_64 conflicts with file from package lcms-1.17-2.fc8.i386

Fortunately, I'm still using 'yum.sh' for these moments. Perhaps by tomorrow morning, I'll have it updated....

[Seve]

Hello:

Bob
I always use yumex with the Beta/Alpha releases and just delete the offending package(s) from the queue.

The packages are for the most part, corrected within a day or so.

Just a thought :)

Seve

[bob]

Yes, that's a good option too. Guess I'm still partial to yum.sh . I also stop pup from loading on the boot. In this case, I'd have been waiting close to an hour just to find out that updates were available.

[RahulSundaram]

Hi,

Just a quick note: The latest yum package in rawhide offers a --skip-broken option which is quite handy. It is not perfect yet and still misses some particular kinds of dependency breakage. If it fails, file a bug report against yum as the developer (who is the guy behind yumex) is quite keen to fix any remaining issues.

[bob]

Rahul, I've got to mention that I've used skip-broken before and it missed badly back then. I'll have to give it another try as Mit has done some excellent work with yumex.

[scottro]

skip-broken never worked for me either. I guess it forgot to skip itself <snicker>.
Alpha is running well for me save for 2 peculiarities. One's a deal breaker, so I'm glad it's alpha (and that I put it on a separate partition.)
The first oddity is that music, whether mp3 or ogg, although totem, rhythm box or mplayer shows that it's going, doesn't become audible for the first 3-4 seconds. For instance, in Poison's Good Time I miss CC's opening chords. Each program will show the song playing, but nothing is audible for 3-4 seconds.

A cursory googling brought no answers, but I haven't yet really brought the power of my intellect to bear upon the problem yet. (He types modestly).

The other issue is another I haven't really begun to investigate either, but it would be a serious one if I didn't have my F8 on another partition. I use VirtualBox running Win2k to run a checkpoint VPN client to connect to my company from home. For whatever reason, on F9, it won't authenticate my password. Now, this might even be a VirtualBox/F9 issue. The rpm won't work because it's looking for libcrypto.so.6 which comes with F8's version of openssl. F9 uses a different version which uses libcrypto.so.7. So, I built from source, which means running their shell script, which went without problems. The connection, which makes use of parprouted, works without a problem. From the Windows VM, I can reach the Internet--I can even reach the VPN gateway, but it won't authenticate my password. I tried enough times to be certain that I wasn't mistyping it. It's not a firewall issue either--unfortunately, I haven't been able to make VirtualBox do bridged (so to speak--when using parprouted, you don't actually create a bridge, though you do create a tap0 interface) wireless networking without totally flushing my iptables rules. That's another problem to work on, and some have had success though their methods haven't worked for me, but the point is, that it's not iptables. I also have selinux disabled, so it's not that either.

At some point, I'll run tcpdump and see if I can figure it out, but at any rate, those two issues are the only problems for me--if it weren't for the latter issue, I'd probably upgrade the F8 to it.

[thedude165]

What I find with Fedora and most distros is the need for patience. When I installed Fedora 8 when it was first released, it was filled with stability issues. I have since reinstalled it and ever issue that I had with Fedora has now been solved through the updates. I will probably wait a while to upgrade to Fedora 9. It seems the longer you wait the more stable the system will be when you finally upgrade your system. I love Fedora 8.

[scottro]

I just did a fresh install to while away an afternoon. I still have an odd sound issue that I haven't seen anywhere else. If i try to play a song, the first few seconds don't play Then, if I stop the program, e.g., mplayer and start it again, or reload a youtube page, sound will start at the beginning, not losing those first few seconds.

No trouble with pulse-audio (that I know of). Permissions issues again, whether or not ConsoleKit is enabled (I see someone wants to reopen a bug that the developers have closed) but that's been around since the decision to tie sound to ConsoleKit and avahi broke sound for many people, especially non Gnome users, awhile ago.

It was a bit funny actually. If I do try booting into Gnome, and play a song, it would play. (With that same problem, losing the first few seconds till I tried a few times.)
If I played it in console, that is without X, it would play. It was only when I booted into fluxbox that it wouldn't play.

So, I fixed it the way I've been fixing it since November, editing /etc/security/console.perms.d/50-default-perms.

For the more normal usage of booting up into Gnome, it should work fine (save for that delay thing I'm experiencing, but that seems to be just me.<shrug>).

[Demz]

7.4 is currently under development, and is scheduled to be released in May 2008 will this setback Fedora 9's chances of getting Xserver1.5 aswell? http://xorg.freedesktop.org/wiki/Releases/7.4 .if F9 final is scheduled to be released in Late April surely this is gonna set back the inclusion of Xserver1.5 in F9 also or am i wrong?

[Thetargos]

Not necessarily, but we'll just see how it goes. Maybe F9 gets pushed back so to give time for Xorg to finalize 7.4 and 1.5 in "time" ;)

[Demz]

thats what i thought to but that would mean Fedora 10 would get pushed back for what date? possibly November final, though interesting i dont think Debain or Ubuntu Hardy is using the 1.4.99.1 by the looks of it there going with 1.4.1git

[Thetargos]

There is no reason why it cannot be the case. There's already been a highly delayed release of Fedora in the past (FC5) which caused Fedora Core 4 to live up to 9 months. The reasons were different back then and you can't suppose to do a vis-a-vis comparison if so would be the fate of Werewolf (poetically interesting, though). At any rate the schedules are not set in stone, and to Fedora it doesn't much matter what other distros are doing. It could very well be that Fedora will release with Xorg 7.4 pre and XServer 1.5 pre, updating them as they are made available. At this point, though, who knows?

[Demz]

true,, be good if they do, do that but the other decision is that, will/would nvidia release a driver or a workable driver for us?

[scottro]

Well, more fun with alpha. If any fluxbox users are playing with it, I'd be interested to see if you're running into the same oddities.

I have, in my ~/.fluxbox/keys several shortcuts requiring Mod4, the Windows key. Sometimes, though not always, when starting X, it doesn't get registered though it will show if I type xmodmap.

So, I have an .xmodmaprc that includes keycode 115 = Super_L. However, after the last round of updates, this didn't work. I opened up xev and behold, it had changed to keycode 133. Googling indicated that some people are running into this with the latest xorgs, but I'm not sure if it's a bug or a design decision.
So, I edited my .xmodmaprc file to use keycode 133 instead of 115.
However, when I log out of X, I see a bunch of console messages, from Fluxbox, I guess, saying that these were invalid key shortcuts. Everything works, but according to them, the things that worked are invalid.

Now, it gets even more peculiar. My .xinitrc calls .xmodmaprc before starting. Suddenly, this has stopped ctl and Shift from working. Ohhh.....kay. I comment out the line to call xmodmap and start X. Shift and Control are working again. However, my Mod4 isn't. So, just for fun, I then just run the command .xmodmap ~/.xmodmaprc. Ok, Mod4 is working, AND Control and Shift are still working. So, at present, it seems the thing for me to do is startx, without running xmodmap, then running it as soon as I boot.

I don't know enough about X, or indeed, about the proposed changes to have any idea what is causing this, but I assume some other hardy souls playing with Alpha run fluxbox. So, I'm curious if I'm just lucky, or has anyone else run into something like this.

Once I figured out my little workarounds, it's more funny than aggravating.

I guess I'm not going to upgrade my work workstation to Fedora 9 yet. :)

[ihavenoname]

Is it just me or does Fedora 9 have XFS filesystem support by default now? I just looked and XFS is listed, does it work with SELinux now? What are the benefits of XFS, I have heard little of it, all I know is that in general it has been disabled by default.

Note: I am using the Fedora 9 gnome live cd.

[Demz]

http://en.wikipedia.org/wiki/XFS http://tastic.brillig.org/~jwb/zfs-xfs-ext4.html might find some info on those pages

[ihavenoname]

http://en.wikipedia.org/wiki/XFS http://tastic.brillig.org/~jwb/zfs-xfs-ext4.html might find some info on those pages

ah thanks. Hmm, I think I'll stick with Ext (it seems like ext4 is comming soon so that should be good).

[rkmayer]

Hello all,

Don't know if this helps anyone. Latest upgrade today has firefox crashing when loading video sites. There was an old 'shockwave' flash plugin enabled, version 100 instead of 115, fixed it by deleting the flash file found in usr/lib/mozilla/plugins (maybe swf something, the rest are obvious, deleted it already: sorry), then installing latest shockwave flash yum from adobe and so on. I am running kde alpha, and loving it. Great work! A firefox problem, anyway. Latest beta came that way.

[Demz]

ah thanks. Hmm, I think I'll stick with Ext (it seems like ext4 is comming soon so that should be good).
i dunno how stable it is EXT4 but from what iv'e read it seems pretty good

[scottro]

rkmayer, thanks for the heads up. I have to laugh, as I said, every day something new is broken. I browsed through the test list, and I think it's as someone said--if they have to stop to check everything during a development cycle, nothing will get done. (In response to someone's bitter complaint about something having gotten broken that they felt should have been caught.)

As is often said on these forums, ya run it at your own risk, so don't cry when it breaks. Laugh, however, and the world laughs with you. Judging from how busy that testing mailing list is, I think that I've been relatively lucky.

[Demz]

April 25 is planned the final release of X Server 1.5 / X.Org 7.4. http://www.phoronix.com/scan.php?page=news_item&px=NjM2MA solves when that will be released