Fedora 11 Released

[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.

[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

[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.

[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!

[blindfrog]

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

[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 . Additionally, Kwin with effects appears uberslugish; Jaunty is snappy even from the LiveCD.

[Apopas]

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

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

[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...

[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.

[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.