Fedora 11 Released

[phoronix]

Phoronix: Fedora 11 Released

After getting hit by a two last minute delays, the final release of Fedora 11 (codenamed Leonidas) is now available. Red Hat's Paul Frields who leads the Fedora Project has announced its release in the usual creative release announcement. The Fedora 11 release notes are available at FedoraProject.org...

http://www.phoronix.com/vr.php?view=NzMxNA

[Louise]

How is it running a 64bit version compared to a 32bit?

I remember in the beginning there were a lot of bugs in the 64bit versions.

Have things changed, or they are equally stable?

[hdas]

Well, I don't use Fedora since a long time (last was FC-1 :o), mostly Gentoo these days and Ubuntu soemtimes. However, everytime a Fedora is released, I feel excited and want to dance joyously on the streets :D. (Nope, not the case when a new Debian or OpenSuSe is released.) Perhaps every Fedora (especially the recent ones) are way more bleeding edge and/or innovative than contemporary distros and can be truly said as 'new'.

Congratulations to Fedora :). Meanwhile, if I get some time, I'll download and test the Nouveau driver on one of my Nvidia machines.

[hdas]

... 64bit version compared to a 32bit?

Of course they are equally stable.

Bugs if any are due to 3rd party closed source 32-bit apps. Right now, there are only two of them on my machine - Adobe acrobat reader (acroread) and Skype. However, Skype is rock stable, and Adobe reader is mostly stable.

A small note of caution. In my opinion, it is better to have at least 1GB of RAM and preferably greater than 2GB for running 64-bit Linux. 64-bit apps seem to take roughly double the amount of RAM than their 32-bit counterparts. Also, my general opinion is that 64-bit seems slightly more heavy than 32-bit (may be just a placebo), but on modern machines, it is all fluid. (I have a desktop with Athlon64 X2 3800+ with 1GB of RAM and it sometimes runs out of RAM during intensive tasks or multitasking with 64-bit. It was something rare in 32-bit. But in general, performance is awesome. But the remaining ones - my notebooks with Core2 T5270 and P8700 and desktops with Core2 E8400 and Phenom X3 8500 are all awesome.)

[curaga]

Never cared much about Fedora, but I have to lift my red hat in honour to mr. Frields' astounding presentation. Cheers!

[Louise]

Of course they are equally stable.

It is not "of course". If you look in the WINE bugzilla, you will find bugs, that only is present on 64bit systems.

Other programs have suffered, so I am interested in hearing from people that have tried the early 64 bit distributions, and how they compare with todays.


A small note of caution. In my opinion, it is better to have at least 1GB of RAM and preferably greater than 2GB for running 64-bit Linux. 64-bit apps seem to take roughly double the amount of RAM than their 32-bit counterparts.

That most be your imagination. That is not my experience with 64bit RHEL5.3 for server use.

64bit might take up a little bit more memory, because some of the instructions now are longer.

If you at Fedora 10 x86 vs A64, the 32bit version DVD iso is 3.4GB and the A64 is 3.9GB.

I would expect the ratio would be somewhat the same for memory usage.


Also, my general opinion is that 64-bit seems slightly more heavy than 32-bit (may be just a placebo), but on modern machines, it is all fluid. (I have a desktop with Athlon64 X2 3800+ with 1GB of RAM and it sometimes runs out of RAM during intensive tasks or multitasking with 64-bit. It was something rare in 32-bit. But in general, performance is awesome. But the remaining ones - my notebooks with Core2 T5270 and P8700 and desktops with Core2 E8400 and Phenom X3 8500 are all awesome.)

64bit should only be faster, when you do float point calculations, on almost other cases, it should actually be a little slower, as you also have experienced.

[NSLW]

I failed to install Fedora 11. It does unhandled exception after choosing keyboard layout so in moment of finding storage devices :mad:
I bet this is stupid bug but i cannot do nothing. I don't use any raid or such stuff. F10 installed flawlessly.

[Apopas]

Try to rewrite it in a new disk. It happened me once something similar with openSUSE and was fixed in that way.

[DanL]

64bit should only be faster, when you do float point calculations..
Don't you mean large integers?

[fart_flower]

One thing that has always bothered me about recent desktop Linux flavours is the slow Firefox rendering. If there is a static background, scrolling grinds to a halt. Switching tabs is positively glacial. When I try and increase font size, which takes a split second on Windows, it can literally take up to half a minute in Linux. (Especially some fancier/text-heavy Japanese sites.) I surf at 1920x1200, so increasing font sizes is common practice.

I am currently running Fedora 11 off the live CD and have to say all these problems are fixed in Firefox 3.5. Yay! Okay, not really Fedora specific, but this is the first modern distro in recent history that didn't have a Firefox that felt ten times -- or more -- slower than the same version of Firefox running under WinXP.

Unfortunately, I'm still having the same sound issues (snap, crackle, hiccup) that have been plaguing me since introduction of Pulseaudio. Yeah...

[Melcar]

The Firefox issues I think are more of the program's own problems than of Linux; Linux Firefox is much slower than Windows Firefox.
I never had any serious issue with PA. The times I did have problems, they were easily resolved by either editing /etc/pulse/daemon.conf or installing pavucontrol and related applets. Hell, on my laptop running KDE4 sound would always crash until dared to configure PA and use it as default.

[KDesk]

Unfortunately, I'm still having the same sound issues (snap, crackle, hiccup) that have been plaguing me since introduction of Pulseaudio. Yeah...

Maybe your sound card driver is buggy, and doesn't work right with PA glitch-free, you can try to disable it by adding tsched=0 next to load-module module-hal-detect in your default.pa file. This would look like this:

load-module module-hal-detect tsched=0

And restart PA daemon. Take a look to this page http://www.pulseaudio.org/wiki/BrokenSoundDrivers


You can also try to change the resample method in file daemon.conf. From highest to lowest quality and cpu usage:

src-sinc-best-quality, src-sinc-medium-quality, src-sinc-fastest, speex-float-{10-0}, speex-fixed-{10-0}, ffmpeg, src-zero-order-hold, src-linear, trivial

More details: http://ubuntuforums.org/showthread.php?t=789578

[fart_flower]

I never had any serious issue with PA. The times I did have problems, they were easily resolved by either editing /etc/pulse/daemon.conf

Having to manually edit a configuration file isn't a serious issue? Try telling that to Mac or Win users -- they will laugh themselves silly.

[KDesk]

Having to manually edit a configuration file isn't a serious issue? Try telling that to Mac or Win users -- they will laugh themselves silly.

Maybe that is because in windows you can't edit more than a couple of files?
And Apple writes there OS for there Hardware, if something doesn't work, that would be stupid.

[Melcar]

Having to manually edit a configuration file isn't a serious issue? Try telling that to Mac or Win users -- they will laugh themselves silly.


Sometimes you have to change certain settings under Windows so your sound card works as it should. I guess if the PA guys provided us with more fancy GUIs people wouldn't complain as much.

[fart_flower]

Maybe your sound card driver is buggy, and doesn't work right with PA glitch-free, you can try to disable it by adding tsched=0 next to load-module module-hal-detect in your default.pa file. This would look like this:

load-module module-hal-detect tsched=0

And restart PA daemon. Take a look to this page http://www.pulseaudio.org/wiki/BrokenSoundDrivers


You can also try to change the resample method in file daemon.conf. From highest to lowest quality and cpu usage:

src-sinc-best-quality, src-sinc-medium-quality, src-sinc-fastest, speex-float-{10-0}, speex-fixed-{10-0}, ffmpeg, src-zero-order-hold, src-linear, trivial

More details: http://ubuntuforums.org/showthread.php?t=789578

Sorry, but I've been through all that and am still bombarded with annoying digital farting noises.

[fart_flower]

And Apple writes there OS for there Hardware, if something doesn't work, that would be stupid.

My brother-in-law's hackintosh has sound working just fine.

[NSLW]

Try to rewrite it in a new disk. It happened me once something similar with openSUSE and was fixed in that way.

Thanks but DVD is good because i checked installation on VirtualBox.

[deanjo]

It is not "of course". If you look in the WINE bugzilla, you will find bugs, that only is present on 64bit systems.

Other programs have suffered, so I am interested in hearing from people that have tried the early 64 bit distributions, and how they compare with todays.


Having used 64-bit since 2003, it has some a long long long long way. Don't miss 32-bit at all. The two big holdouts were flash and java 64-bit plugins, but even those are in 64-bit flavor now.


If you at Fedora 10 x86 vs A64, the 32bit version DVD iso is 3.4GB and the A64 is 3.9GB.

I would expect the ratio would be somewhat the same for memory usage.


Can't judge by iso size at all. 64-bit releases typically have 32-bit compatibility libraries also on the iso which adds to it's size. As far as memory usage goes 1 - 1 1/2 gig seems just as zippy as it does on 32-bit (talking about desktop usage here).


64bit should only be faster, when you do float point calculations, on almost other cases, it should actually be a little slower, as you also have experienced.

Well when we are talking about prepackaged distro's this isn't always the case. There are many more variables to consider such as to maintain compatibility often packages are not compiled with the additional instruction sets that are only found on 64-bit procs. An distro that is compiled for i586 for example defaults to not even utilizing MMX. A 64 bit distro on the other hand is going to have all the instuction sets such as MMX and SSE at least enabled. Other applications that can greatly benefit are items such as dbases and of course apps that can use large amounts of addressable ram (pae works for some things in 32-bit but not all, one maya model I have gobbles up 5GB as it is).

Overall compatibility is great, I bet most of the wine issues you saw were actuall wine64 (running 64-bit window apps in wine) issues and not running wine32 in a 64-bit distro with the compatibility libraries installed. The benifits greatly out weigh the few items where it maybe extremely marginally slower (and I do mean extremely marginal). As a rule of thumb, performance wise a 64-bit os will run at least as fast as a 32-bit and in some cases can yield big gains for the little extra cost of memory.

[Dragoran]

It is not "of course". If you look in the WINE bugzilla, you will find bugs, that only is present on 64bit systems.

Other programs have suffered, so I am interested in hearing from people that have tried the early 64 bit distributions, and how they compare with todays.



That most be your imagination. That is not my experience with 64bit RHEL5.3 for server use.

64bit might take up a little bit more memory, because some of the instructions now are longer.

If you at Fedora 10 x86 vs A64, the 32bit version DVD iso is 3.4GB and the A64 is 3.9GB.

I would expect the ratio would be somewhat the same for memory usage.



64bit should only be faster, when you do float point calculations, on almost other cases, it should actually be a little slower, as you also have experienced.

The higher memory usage is mainly because of 64 bit pointers.
They are needed for supporting/addressing more than 4GB of memory.

As for the speed, the x86_64 architecture has more registers than the traditional x86 architecture which can result in significant performance gains depending on the application.

Further SSE2 is part of the standard x86_64 ABI, this means every app can make use of SSE2 without having to do run time checking or being incompatible with some cpus.

x86_64 also removes the need for using HIGHMEM which is required on x86 for systems with > 1GB of ram. This adds an overhead that is not only measurable but in some workloads also very noticeable.

As for slowdowns x86_64 has a higher memory footprint (as I already said above), thus it can result into more cache misses which reduces performance.

But the advantages outweigh the disadvantages so if you have a x86_64 capable CPU and 1GB-2GB+ RAM you should use x86_64 (there is no reason not to do so).

x86_64 is fully backwards compatible so you can run 32bit apps just fine.

[kraftman]

One thing that has always bothered me about recent desktop Linux flavours is the slow Firefox rendering. If there is a static background, scrolling grinds to a halt. Switching tabs is positively glacial. When I try and increase font size, which takes a split second on Windows, it can literally take up to half a minute in Linux. (Especially some fancier/text-heavy Japanese sites.) I surf at 1920x1200, so increasing font sizes is common practice.

I am currently running Fedora 11 off the live CD and have to say all these problems are fixed in Firefox 3.5. Yay! Okay, not really Fedora specific, but this is the first modern distro in recent history that didn't have a Firefox that felt ten times -- or more -- slower than the same version of Firefox running under WinXP.

Unfortunately, I'm still having the same sound issues (snap, crackle, hiccup) that have been plaguing me since introduction of Pulseaudio. Yeah...

Use Firefox under Wine and it should be much faster then native! That's just parody, but when you use such slow garbage like xul or its mix with gtk or whatever such things happen... Pulse audio consumes your CPU as a bonus and someone give me a reason why such idiocy have place? Another thing is gstreamer... Rather then focusing on better toolkits or solutions many people base on stupid stereotypes. Some lobby makes Linux squeals on desktop in some things...

[Apopas]

My brother-in-law's hackintosh has sound working just fine.
Just one example isn't sufficient, don't you think?

[Melcar]

I'm trying out the KDE LiveCD on my laptop. Every time I enable Kwin effects with Opengl, the desktop freaks out and once it settles I can only see window outlines and shadows (the window content itself appears garbled or is just missing). The laptop has a 200M, so the driver should be providing proper 3D. Kubuntu Jaunty works, for example, and I think both Jaunty and F11 use the same driver version. Xrender works, but who wants to use that :p. Additionally, Kwin with effects appears uberslugish; Jaunty is snappy even from the LiveCD.

[blindfrog]

Have to wait the upgrade from F10 till the catalyst 9.6 arrives with 2.6.29 support :P

[fart_flower]

Just one example isn't sufficient, don't you think?

He only has one computer, so from his perspective it's more than sufficient. I also only have one computer, and from my perspective, Pulseaudio is a steaming pile.

For the one-and-a-half people who are semi-interested, once I installed the proprietary nVidia drivers, Firefox performance dropped considerably. Fortunately it only affects scrolling with fixed backgrounds -- changing font sizes still remains much quicker than in previous versions. (But still noticeably slower than WinXP.)

Now to test this new-fangled Japanese input iBus rewrite thingy... Whee!!!

In other news, although the liveCD gave me crackly sound, the install gives me NO sound whatsoever. Hurrah!

[Louise]

Having used 64-bit since 2003, it has some a long long long long way. Don't miss 32-bit at all. The two big holdouts were flash and java 64-bit plugins, but even those are in 64-bit flavor now.

That is very compelling, that it just works.

[Louise]

The higher memory usage is mainly because of 64 bit pointers.
They are needed for supporting/addressing more than 4GB of memory.

As for the speed, the x86_64 architecture has more registers than the traditional x86 architecture which can result in significant performance gains depending on the application.

Further SSE2 is part of the standard x86_64 ABI, this means every app can make use of SSE2 without having to do run time checking or being incompatible with some cpus.

x86_64 also removes the need for using HIGHMEM which is required on x86 for systems with > 1GB of ram. This adds an overhead that is not only measurable but in some workloads also very noticeable.

As for slowdowns x86_64 has a higher memory footprint (as I already said above), thus it can result into more cache misses which reduces performance.

But the advantages outweigh the disadvantages so if you have a x86_64 capable CPU and 1GB-2GB+ RAM you should use x86_64 (there is no reason not to do so).

x86_64 is fully backwards compatible so you can run 32bit apps just fine.

What a great break down. :)

I'll be running F11 64bit soon then ;)

[kraftman]

He only has one computer, so from his perspective it's more than sufficient. I also only have one computer, and from my perspective, Pulseaudio is a steaming pile.

For the one-and-a-half people who are semi-interested, once I installed the proprietary nVidia drivers, Firefox performance dropped considerably. Fortunately it only affects scrolling with fixed backgrounds -- changing font sizes still remains much quicker than in previous versions. (But still noticeably slower than WinXP.)

Now to test this new-fangled Japanese input iBus rewrite thingy... Whee!!!

In other news, although the liveCD gave me crackly sound, the install gives me NO sound whatsoever. Hurrah!

Some time ago when I had nvidia card using Firefox was just pain. I don't know who to blame? Probably both. With open source radeon driver Firefox is far more responsive, but still it's dog slow. Nvidia has wonderful QT3 support, so you may try Opera if you don't mind it's closed source. If you want to get rid of pulse audio choose KDE (however, nvidia had problems with QT4, but maybe they fixed it).

My brother-in-law's hackintosh has sound working just fine.

And what? Works for him, doesn't work for others... I don't have a single problem with sound under Linux.

[susikala]

One thing that has always bothered me about recent desktop Linux flavours is the slow Firefox rendering. If there is a static background, scrolling grinds to a halt. Switching tabs is positively glacial. When I try and increase font size, which takes a split second on Windows, it can literally take up to half a minute in Linux. (Especially some fancier/text-heavy Japanese sites.) I surf at 1920x1200, so increasing font sizes is common practice.

I am currently running Fedora 11 off the live CD and have to say all these problems are fixed in Firefox 3.5. Yay! Okay, not really Fedora specific, but this is the first modern distro in recent history that didn't have a Firefox that felt ten times -- or more -- slower than the same version of Firefox running under WinXP.

I really don't have the slightest clue what you're talking about. I'm using Xubuntu Jaunty, that is Firefox 3.0.10 on an ATI igp with radeon-git. Scrolling is smooth as it gets, switching tabs is instantaneous, increasing font size occurs immediately, even on text-heavy sites.

I don't think those issues have anything to do with Firefox on Linux or even with your distro. The implementation is just fine, works as well as on Windows or even better. Probably a graphics card issue.

[fart_flower]

Ha ha ha! I love Linux people. Always the same:

Newbee: "I'm having an issue with so-and-so, any help?"

Crustee: "Works fine here."

Newbee: "Um, that's great, but it doesn't work here. Any help?"

Crustee: "You don't know what you're talking about. It works fine here."

Newbee: "Gosh, thanks..." (Goes back to WinXP.)


In contrast, the LKML is all about: "We've gotta problem." "We have a regression." "This code sucks." "Must fix this buggy crap." Etc.

At least the people behind the wheel are paying some attention. Nyuk, nyuk...

[fart_flower]

Probably a graphics card issue.

More likely it's a combo issue. I've seen the same slow scrolling on my previous ATI card, and on a friend's Intel IGP.

Combo one-two-punch... Knock-out! Great fighting, you're an up-and-coming scrolling bug!

[kraftman]

Ha ha ha! I love Linux people. Always the same:

Newbee: "I'm having an issue with so-and-so, any help?"

Crustee: "Works fine here."

Newbee: "Um, that's great, but it doesn't work here. Any help?"

Crustee: "You don't know what you're talking about. It works fine here."

Newbee: "Gosh, thanks..." (Goes back to WinXP.)


In contrast, the LKML is all about: "We've gotta problem." "We have a regression." "This code sucks." "Must fix this buggy crap." Etc.

At least the people behind the wheel are paying some attention. Nyuk, nyuk...

What do you expect? You should be thankful, because some people replied you. This thread is not about solving your problems. I love Windows people:

scream and demand that some users not affected by their problems will help them. Go to mozilla or nvidia forum and write about this issue or even post bug report. You sound like one troll from the other thread now.

[Apopas]

You sound like one troll from the other thread now.
Hahaha I wonder which thread :)

[kraftman]

Hahaha I wonder which thread :)

You should know ;)

[fart_flower]

What do you expect? You should be thankful, because some people replied you. This thread is not about solving your problems.

True enough, but I never asked for help in this thread -- I merely pointed out my Fedora 11 experiences thus far. (The topic is, after all, Fedora 11.) Some people were kind enough to volunteer some thoughts on my issues, but I never actually asked for them. I do that on the Fedora Forum, where it belongs:
http://forums.fedoraforum.org/showthread.php?t=223400

Anyway, whatever. It's nice and sunny outside -- I'm going to work on my melanoma.

Yours sincerely,
Farty McTroll.

[Zhick]

I'm trying out the KDE LiveCD on my laptop. Every time I enable Kwin effects with Opengl, the desktop freaks out and once it settles I can only see window outlines and shadows (the window content itself appears garbled or is just missing). The laptop has a 200M, so the driver should be providing proper 3D. Kubuntu Jaunty works, for example, and I think both Jaunty and F11 use the same driver version. Xrender works, but who wants to use that :p. Additionally, Kwin with effects appears uberslugish; Jaunty is snappy even from the LiveCD.
Yeah, that's a bug with the new kms/dri2 code (F11 uses bleeding edge stuff in contrast to Jaunty) in connection to kwin. It's already reported here (http://bugs.freedesktop.org/show_bug.cgi?id=21469). The second comment there is from me...
According to #radeon this should be fixed in X Server git, but the last time I tried it wasn't. Maybe you can try running a more recent X Server and report the results to that bug as well? I guess it would help to bring it to the devs attention.
I'll also give the KDE liveCD a try tommorow, but I guess now I already know what to expect. :)

[kraftman]

True enough, but I never asked for help in this thread -- I merely pointed out my Fedora 11 experiences thus far. (The topic is, after all, Fedora 11.) Some people were kind enough to volunteer some thoughts on my issues, but I never actually asked for them. I do that on the Fedora Forum, where it belongs:
http://forums.fedoraforum.org/showthread.php?t=223400

Anyway, whatever. It's nice and sunny outside -- I'm going to work on my melanoma.

Yours sincerely,
Farty McTroll.

I wonder if those people can help you. Linux Firefox uses slow garbage called xul. However, there are some threads on unofficial nvidia forum which may be helpful (ya' know, those ugly hacks which only Linux geeks use ;)). Fedora people can't do anything with nvidia binary blobs and they rather won't rewrite Firefox using something better then xul.

[Xeno]

Yeah, that's a bug with the new kms/dri2 code (F11 uses bleeding edge stuff in contrast to Jaunty) in connection to kwin. It's already reported here (http://bugs.freedesktop.org/show_bug.cgi?id=21469). The second comment there is from me...
According to #radeon this should be fixed in X Server git, but the last time I tried it wasn't. Maybe you can try running a more recent X Server and report the results to that bug as well? I guess it would help to bring it to the devs attention.
I'll also give the KDE liveCD a try tommorow, but I guess now I already know what to expect. :)

Latest MESA (7.6) fixed this one for me. KWin composite works just fine now. Also some OGL apps like Glaxium, GL-117 stopped complaining about falling to SW rendering and runs with usable fps.
The performance with KMS is still far cry from the Fedora9 (MESA 7.1 and xorg-x11-drv-ati 6.8 IIRC) and F10 w/o KMS but better with F10/KMS.