I apologize if this question has been asked before. I have a new Thinkpad T61 in scheduled to arrive sometime next week. I want to install Fedora 9 on it. Being as it has a Core 2 Duo processor, I assume I can install the 64 bit version of Fedora 9. My question is what are the pros and cons that I need to consider when choosing 32 or 64 bit version of Fedora 9? I am currently using a Thinkpad T42 running Fedora Core 7, so I have no experience with 64 bit linux or associated issues.
Thanks in advance for any and all advice.
Charlie
Charlie McVeigh wrote:
I apologize if this question has been asked before. I have a new Thinkpad T61 in scheduled to arrive sometime next week. I want to install Fedora 9 on it. Being as it has a Core 2 Duo processor, I assume I can install the 64 bit version of Fedora 9. My question is what are the pros and cons that I need to consider when choosing 32 or 64 bit version of Fedora 9? I am currently using a Thinkpad T42 running Fedora Core 7, so I have no experience with 64 bit linux or associated issues.
Thanks in advance for any and all advice.
Charlie
64 bit is a minor hassle - flash for instance, and screwing around with multilibs. OTOH, if you want to use more than 4gb mem - or have an application where it really makes a difference it's not too bad.
When I looked, I couldn't find any app I used where 64bit was useful, even ffmpeg. At the time, though, I could find very little data on this.
IOW, stick with 32bit unless you've got some real 64bit benefit.
sean
sean darcy <seandarcy2 <at> gmail.com> writes:
64 bit is a minor hassle - flash for instance,
It's what nspluginwrapper is for. Or you could use gnash or swfdec instead, or just not use Flash at all. But even the proprietary crap just works if you install nspluginwrapper.i386.
and screwing around with multilibs.
Only if you need to run legacy 32-bit-only crap. I have F9 x86_64 running with no 32-bit multilibs at all on my laptop, works just fine! But "yum install packagename.i386" isn't exactly hard either.
When I looked, I couldn't find any app I used where 64bit was useful, even ffmpeg.
You just haven't noticed the speed difference.
At the time, though, I could find very little data on this.
On all the benchmarks I've seen, 64-bit is clearly faster.
IOW, stick with 32bit unless you've got some real 64bit benefit.
"IOW, stick with horse carts unless you've got some real car benefit." :-D
Kevin Kofler
Kevin Kofler wrote:
sean darcy <seandarcy2 <at> gmail.com> writes:
64 bit is a minor hassle - flash for instance,
It's what nspluginwrapper is for. Or you could use gnash or swfdec instead, or just not use Flash at all. But even the proprietary crap just works if you install nspluginwrapper.i386.
and screwing around with multilibs.
Only if you need to run legacy 32-bit-only crap. I have F9 x86_64 running with no 32-bit multilibs at all on my laptop, works just fine! But "yum install packagename.i386" isn't exactly hard either.
When I looked, I couldn't find any app I used where 64bit was useful, even ffmpeg.
You just haven't noticed the speed difference.
At the time, though, I could find very little data on this.
On all the benchmarks I've seen, 64-bit is clearly faster.
I looked at this about a year ago. I found very few real benchmarks. Are there some now? Any links you'd suggest?
sean
Charlie McVeigh <cbmcveigh <at> gmail.com> writes:
I apologize if this question has been asked before. I have a new Thinkpad T61 in scheduled to arrive sometime next week. I want to install Fedora 9 on it. Being as it has a Core 2 Duo processor, I assume I can install the 64 bit version of Fedora 9. My question is what are the pros and cons that I need to consider when choosing 32 or 64 bit version of Fedora 9?
64-bit is faster (mainly because x86_64 has more registers to use) and it can run everything 32-bit can (almost all the packages in Fedora are available in 64-bit versions and there are multilibs to run 3rd-party 32-bit-only binary-only junk), so really there's no good reason to use the obsolete 32-bit version.
IMHO, it makes no sense to run a 32-bit OS on a 64-bit-capable CPU, especially for x86 (x86_64 is really a huge improvement).
Kevin Kofler
Kevin Kofler wrote:
Charlie McVeigh <cbmcveigh <at> gmail.com> writes:
I apologize if this question has been asked before. I have a new Thinkpad T61 in scheduled to arrive sometime next week. I want to install Fedora 9 on it. Being as it has a Core 2 Duo processor, I assume I can install the 64 bit version of Fedora 9. My question is what are the pros and cons that I need to consider when choosing 32 or 64 bit version of Fedora 9?
64-bit is faster (mainly because x86_64 has more registers to use) and it can run everything 32-bit can (almost all the packages in Fedora are available in 64-bit versions and there are multilibs to run 3rd-party 32-bit-only binary-only junk), so really there's no good reason to use the obsolete 32-bit version.
IMHO, it makes no sense to run a 32-bit OS on a 64-bit-capable CPU, especially for x86 (x86_64 is really a huge improvement).
Let me offer one, 32 bit applications are smaller and nicer to cache. Depending on the application that can make a difference. Also minute gains in load speed, memory using, probably too small to measure.
I'm going to skip some of the dialog, but Linux has been 64-bit since 1994. Just a couple of things I did not see mentioned. In x86 memory is segmented, in x86_64 memory is linear. I think that you'll find that graphics tend to render better in a 64-bit system .
There are some applications that do perform better in 32-bit.
Charlie McVeigh wrote:
I apologize if this question has been asked before. I have a new Thinkpad T61 in scheduled to arrive sometime next week. I want to install Fedora 9 on it. Being as it has a Core 2 Duo processor, I assume I can install the 64 bit version of Fedora 9. My question is what are the pros and cons that I need to consider when choosing 32 or 64 bit version of Fedora 9? I am currently using a Thinkpad T42 running Fedora Core 7, so I have no experience with 64 bit linux or associated issues.
Thanks in advance for any and all advice.
At the moment, unless you have really large application which benefit from > 4G memory, the hassle of 64 bit is more than some benefit, and it appears that 32 bit application may be nicer to cache and therefore somewhat faster. You can use more than 4G of memory in the kernel, to be used to run smaller applications, although Alan Cox indicates using a PAE kernel is slower. I haven't seen that, so I suspect it's one of those "in some cases" things.
Bill Davidsen <davidsen <at> tmr.com> writes:
At the moment, unless you have really large application which benefit from 4G memory, the hassle of 64 bit is more than some benefit,
There's no hassle. It just works.
and it appears that 32 bit application may be nicer to cache and therefore somewhat faster.
Where are your numbers?
On all the benchmarks I've seen, 64-bit clearly wins, and there are several explanations for that, in particular: * x86_64 has more registers to use. * SSE can be used by default on x86_64 because all x86_64 CPUs support it.
Please show your numbers or I'll have to dismiss your remark as nonsense.
You can use more than 4G of memory in the kernel, to be used to run smaller applications, although Alan Cox indicates using a PAE kernel is slower. I haven't seen that, so I suspect it's one of those "in some cases" things.
PAE is obviously slower, for all apps (it slows down all the memory accesses), it's just a hack to keep 32-bit viable for a longer time, 64-bit is the real solution.
Kevin Kofler
Kevin Kofler wrote:
On all the benchmarks I've seen, 64-bit clearly wins, and there are several explanations for that, in particular:
I like how you keep saying "all the benchmarks" and keep not linking to a single one.
For the average desktop user, 64-bit has little or no benefit and is not worth the hassles of dealing with incompatible proprietary code (and yes, there is a hassle). See for instance http://www.phoronix.com/scan.php?page=article&item=616&num=2, where most benchmarks showed a small (probably not statistically signficant) increase, with one equally small decrease.
Matt Flaschen
Matthew Flaschen wrote:
Kevin Kofler wrote:
For the average desktop user, 64-bit has little or no benefit and is not worth the hassles of dealing with incompatible proprietary code (and yes, there is a hassle).
I concur.
Not only is it an unnecessary hassle, 1 GB of memory on 32 machine ends up requiring at least 3 GB of memory on a 64 bit machine.
On Sun, Oct 26, 2008 at 7:51 PM, Agile Aspect agile.aspect@gmail.comwrote:
Matthew Flaschen wrote:
Kevin Kofler wrote:
For the average desktop user, 64-bit has little or no benefit and is not worth the hassles of dealing with incompatible proprietary code (and yes, there is a hassle).
I concur.
Not only is it an unnecessary hassle, 1 GB of memory on 32 machine ends up requiring at least 3 GB of memory on a 64 bit machine.
Ok, maybe I slept through a few math classes in high school, but how does 1GB on a 32bit system go to 3 on a 64bit system? I have run 64bit since FC6 on my old(ish) Athlon 3000+ and 1GB of memory. I don't use it has a major server but I use it as a home file/print server and with Gnome and Firefox running I'm idling at 27% memory usage. I even occasionally boot an XP virtual machine with virtualbox (although I've used vmware as well) with adequate performance for my needs.
In fact, I have a total of 4 Fedora installations (two F8, two F9) all 64bit ranging from 1 to 2GB memory and other than having to install nspluginwrapper.i386 for flash, I've had very few issues.
Richard Richard
Not only is it an unnecessary hassle, 1 GB of memory on 32 machine ends up requiring at least 3 GB of memory on a 64 bit machine.
Code density for x86 and the extra CPU registers mean 64bit is usually faster and the code density is pretty much the same (unlike say Sparc64 where 64bit userspace apps are generally not useful). Data pointers expand a little but not much, and your 1 to 3GB is a totally bogus claim.
The moment you have more than about 900MB of RAM there are big advantages to running a 64bit kernel as it can keep all of physical and virtual space mapped at the same time, which is a big performance win.
Alan
Alan Cox wrote:
The moment you have more than about 900MB of RAM there are big advantages to running a 64bit kernel as it can keep all of physical and virtual space mapped at the same time, which is a big performance win.
Alan
Can you point to any benchmarks showing a significant performance gain for a 1 GB desktop user?
Matt Flaschen
On Mon, 27 Oct 2008 11:54:47 -0400 Matthew Flaschen matthew.flaschen@gatech.edu wrote:
Alan Cox wrote:
The moment you have more than about 900MB of RAM there are big advantages to running a 64bit kernel as it can keep all of physical and virtual space mapped at the same time, which is a big performance win.
Alan
Can you point to any benchmarks showing a significant performance gain for a 1 GB desktop user?
I'm not aware of anyone having sat down and run formal benchmarks on the Fedora desktop. One of the problems with that is that you need a reproducable representative benchmark typically scripting all the mouse clicks and keypresses, using identical data sets and so on. They are hard to produce and I'm not aware of any Linux ones that don't involve payment of large sums of money to third party who runs their own closed secret test and produces a number you can stick up in lights. So let me turn the question around - given that the evidence from microbenchmarks and CPU architects is that 64bit is the better choice can you show any good quality benchmarks showing it isn't a win ?
There are real benchmark numbers for CPU performance, relative code density and the like and you can generate mapping cost benchmarks. AMD and Intel have published various studies on the former two. There are lots of benchmarks for server performance because there is money in that market so people actually TPC and other things to sell enterprise product.
However if you cared about performance you wouldn't be running Gnome or Kde ;)
Alan
Alan Cox wrote:
On Mon, 27 Oct 2008 11:54:47 -0400 Matthew Flaschen matthew.flaschen@gatech.edu wrote:
Alan Cox wrote:
The moment you have more than about 900MB of RAM there are big advantages to running a 64bit kernel as it can keep all of physical and virtual space mapped at the same time, which is a big performance win.
Alan
Wouldn't you need twice as much memory to have the same memory for applications if you are using double the word size?
Or does the OS somehow take that into account and split the 64 bit words into their components to get most efficient use out of them?
To clarify, I have 2 GBytes of memory in a 32 bit OS. If I use a 64 bit OS, isn't that memory now effectively halved? The same as if I use 16 bits to store a character instead of 8 bits. It is my understanding that UTF-8 only uses the second 8 bits if it needs it. So that is like my second question, making sure that there isn't lots of empty memory.
Thanks for any clarification you can offer.
stan wrote:
Alan Cox wrote:
On Mon, 27 Oct 2008 11:54:47 -0400 Matthew Flaschen matthew.flaschen@gatech.edu wrote:
Alan Cox wrote:
The moment you have more than about 900MB of RAM there are big advantages to running a 64bit kernel as it can keep all of physical and virtual space mapped at the same time, which is a big performance win.
Alan
Wouldn't you need twice as much memory to have the same memory for applications if you are using double the word size?
This is incorrect in general. GNU/Linux 32-bit uses ILP32, meaning integers, longs, and pointers all have 32 bits. GNU/Linux 64 uses LP64, which means longs and pointers have 64 bits. Integers remain 32 bits, and ASCII chars are still 8 bits (this is true of ILP64, another model, as well). Please read http://www.unix.org/whitepapers/64bit.html.
Or does the OS somehow take that into account and split the 64 bit words into their components to get most efficient use out of them?
There is no need to "split" anything. The base unit is still the byte. All 64-bit systems have 64 bit pointers, but there are no hard rules for the other types.
To clarify, I have 2 GBytes of memory in a 32 bit OS. If I use a 64 bit OS, isn't that memory now effectively halved?
No.
The same as if I use 16 bits to store a character instead of 8 bits. It is my understanding that UTF-8 only uses the second 8 bits if it needs it.
There is no "second" 8 bits. UTF-8 can use up to 4 bytes, but ASCII will use only 1 for any (sane) 64-bit implementation of UTF-8.
Matt Flaschen
Matthew Flaschen wrote:
stan wrote:
Alan Cox wrote:
On Mon, 27 Oct 2008 11:54:47 -0400 Matthew Flaschen matthew.flaschen@gatech.edu wrote:
Alan Cox wrote:
The moment you have more than about 900MB of RAM there are big advantages to running a 64bit kernel as it can keep all of physical and virtual space mapped at the same time, which is a big performance win.
Alan
Wouldn't you need twice as much memory to have the same memory for applications if you are using double the word size?
This is incorrect in general. GNU/Linux 32-bit uses ILP32, meaning integers, longs, and pointers all have 32 bits. GNU/Linux 64 uses LP64, which means longs and pointers have 64 bits. Integers remain 32 bits, and ASCII chars are still 8 bits (this is true of ILP64, another model, as well). Please read http://www.unix.org/whitepapers/64bit.html.
Thank you for the response and the link.
Wouldn't you need twice as much memory to have the same memory for applications if you are using double the word size?
Pointers get larger but other values don't. Fortunately most programs are not made up mostly of pointers.
8 bits. It is my understanding that UTF-8 only uses the second 8 bits if it needs it. So that is like my second question, making sure that there isn't lots of empty memory.
Floating point values are the same size, strings are the same size, code is about the same size including most inline constants within the code. Integers likewise.
The amount of size difference varies by application and usage but it is usually low. Most big objects in programs (graphics, icons, bitmaps, big tables) don't get any bigger.
There are one or two obscure cases where some things really do double in size due to the way they are written - some lisp interpreters for example, but they are obscure corner cases.
Alan
On Mon, 2008-10-27 at 16:14 +0000, Alan Cox wrote:
On Mon, 27 Oct 2008 11:54:47 -0400 Matthew Flaschen matthew.flaschen@gatech.edu wrote:
Alan Cox wrote:
The moment you have more than about 900MB of RAM there are big advantages to running a 64bit kernel as it can keep all of physical and virtual space mapped at the same time, which is a big performance win.
Alan
Can you point to any benchmarks showing a significant performance gain for a 1 GB desktop user?
I'm not aware of anyone having sat down and run formal benchmarks on the Fedora desktop. One of the problems with that is that you need a reproducable representative benchmark typically scripting all the mouse clicks and keypresses, using identical data sets and so on. They are hard to produce and I'm not aware of any Linux ones that don't involve payment of large sums of money to third party who runs their own closed secret test and produces a number you can stick up in lights. So let me turn the question around - given that the evidence from microbenchmarks and CPU architects is that 64bit is the better choice can you show any good quality benchmarks showing it isn't a win ?
There are real benchmark numbers for CPU performance, relative code density and the like and you can generate mapping cost benchmarks. AMD and Intel have published various studies on the former two. There are lots of benchmarks for server performance because there is money in that market so people actually TPC and other things to sell enterprise product.
However if you cared about performance you wouldn't be running Gnome or Kde ;)
Alan
I understand the point but Linux benchmarks exist such as the ones below: http://lbs.sourceforge.net/ -- ======================================================================= Sometimes I wonder if I'm in my right mind. Then it passes off and I'm as intelligent as ever. -- Samuel Beckett, "Endgame" ======================================================================= Aaron Konstam telephone: (210) 656-0355 e-mail: akonstam@sbcglobal.net
I understand the point but Linux benchmarks exist such as the ones below: http://lbs.sourceforge.net/
None of which are desktop benchmarks. Most are server benchmarks, some are specific application tests, others are essentially torture testers.
Alan
Alan Cox wrote: ...
None of which are desktop benchmarks.
...
What's the use of a desktop benchmark?
If I press X on the keyboard I really don't care if it takes a microsecond or a millisecond to show up on the screen.
Mogens
On Tue, 28 Oct 2008 07:52:03 +0100 Mogens Kjaer mk@crc.dk wrote:
Alan Cox wrote: ...
None of which are desktop benchmarks.
...
What's the use of a desktop benchmark?
If I press X on the keyboard I really don't care if it takes a microsecond or a millisecond to show up on the screen.
Desktop benchmarks measure things like opening a word processor making a long series of edits statistically matched to those commonly used, scrolling through documents, saving them. Similar things for web page viewing, email processing and the like.
That does make them useful.
Alan
Alan Cox wrote:
I'm not aware of anyone having sat down and run formal benchmarks on the Fedora desktop. One of the problems with that is that you need a reproducable representative benchmark typically scripting all the mouse clicks and keypresses, using identical data sets and so on. They are hard to produce and I'm not aware of any Linux ones that don't involve payment of large sums of money to third party who runs their own closed secret test and produces a number you can stick up in lights. So let me turn the question around - given that the evidence from microbenchmarks and CPU architects is that 64bit is the better choice can you show any good quality benchmarks showing it isn't a win ?
I agree getting formal, almost perfectly fair benchmarks is infeasible. But I haven't seen any informal benchmarks that come close to showing a significant performance gain. I've already pointed to such an informal benchmark showing negligible difference.
However if you cared about performance you wouldn't be running Gnome or Kde ;)
I don't particularly care about small differences in performance, and I do like running a highly featured desktop. But the real question is whether any performance advantage of desktop 64-bit for < 4 GB is worth the hassle. As to that, I'm still very unconvinced.
Matt Flaschen
I don't particularly care about small differences in performance, and I do like running a highly featured desktop. But the real question is whether any performance advantage of desktop 64-bit for < 4 GB is worth the hassle. As to that, I'm still very unconvinced.
What hassle ?
My desktop is FC9 x86-64 and all the crud like flash just works with the plugin stuff as shipped in FC9. Older FC there were some fun problems with plugins but I've not seen any evidence of them for F9 or any other hassles.
Alan
Alan Cox wrote:
I don't particularly care about small differences in performance, and I do like running a highly featured desktop. But the real question is whether any performance advantage of desktop 64-bit for < 4 GB is worth the hassle. As to that, I'm still very unconvinced.
What hassle ?
My desktop is FC9 x86-64 and all the crud like flash just works with the plugin stuff as shipped in FC9. Older FC there were some fun problems with plugins but I've not seen any evidence of them for F9 or any other hassles.
I think I see the reason this 32 vs 64 doesn't get resolved, the people who say "what hassles" or "it just works" are all either genuine experts such as you, people who do system administration "as a job" rather than "so they can do their job," and a few people who present themselves as experts and expect others to take opinion as gospel, actual expertise unknown. Based on notes about having to hand install both 32 bit and 64 bit versions of libraries and a few other minor diddles, which are not worth noticing to the experts, but confusing and worrisome for the users who are either just running applications or developing desktop applications.
I think those of us using a mix of 32 bit and 64 bit CPUs would have to see an easily measured performance gain to go 64 bit on the machines which can do so, because the hassle factor of supporting multiple versions of the rest of the system is measurable.
I think the answer is that many more people are running 32 bit systems, and unless you have some need to run very large applications, or a large server, or large memory, you will be using more widely tested compilations of the software, and will have a larger group of experienced users to answer questions. That's the best reason to stay 32 bit now, lacking a benefit from 64 bit.
Bill Davidsen <davidsen <at> tmr.com> writes:
I think I see the reason this 32 vs 64 doesn't get resolved, the people who say "what hassles" or "it just works" are all either genuine experts such as you, people who do system administration "as a job" rather than "so they can do their job," and a few people who present themselves as experts and expect others to take opinion as gospel, actual expertise unknown.
Or maybe they just don't use proprietary software?
Based on notes about having to hand install both 32 bit and 64 bit versions of libraries and a few other minor diddles, which are not worth noticing to the experts, but confusing and worrisome for the users who are either just running applications or developing desktop applications.
The Free (as in speech) Software included in Fedora works just fine without "having to hand install both 32 bit and 64 bit versions of libraries". It's all natively 64-bit, with very few exceptions (the most high-profile one being WINE, whose primary use is to run proprietary software, once again), and even for those exceptions, yum will automatically install the required 32-bit multilibs.
Only third-party proprietary software which isn't even properly packaged (i.e. in an RPM with proper dependencies, not in a tarball or in some cross-distro RPM (a concept broken by design) which is missing all its dependencies like the Flash one) is the one causing problems. If you use unpackaged (or incorrectly packaged) third-party software, you have to expect to have to run some commands by hand. I wouldn't qualify a single line of yum as a real hassle. Especially as it's a one-time thing.
Kevin Kofler
On 10/29/2008 07:50 PM, Bill Davidsen wrote:
I think I see the reason this 32 vs 64 doesn't get resolved, the people who say "what hassles" or "it just works" are all either genuine experts such as you, people who do system administration "as a job" rather than "so they can do their job," and a few people who present themselves as experts and expect others to take opinion as gospel, actual expertise unknown. Based on notes about having to hand install both 32 bit and 64 bit versions of libraries and a few other minor diddles, which are not worth noticing to the experts, but confusing and worrisome for the users who are either just running applications or developing desktop applications.
I think those of us using a mix of 32 bit and 64 bit CPUs would have to see an easily measured performance gain to go 64 bit on the machines which can do so, because the hassle factor of supporting multiple versions of the rest of the system is measurable.
I think the answer is that many more people are running 32 bit systems, and unless you have some need to run very large applications, or a large server, or large memory, you will be using more widely tested compilations of the software, and will have a larger group of experienced users to answer questions. That's the best reason to stay 32 bit now, lacking a benefit from 64 bit.
The reason for some of the hassles is that some developers are just too lazy to fix their applications, or that some 32-bit applications are very poorly written, It's just that simple. From a developer standpoint, developing a portable application, eg. one that can be compiled for 32-bit or 64-bit and work out of the box is relatively simple if you follow some rules. The newer C and C++ language standards also have specific 32-bit and 64-bit integers, so you don't have to use "long" which can be 32-bits or 64-bits. I remember the same issue with 16-bit and 32-bit. In the past, I worked on a reasonably complex application that had to work on Linux (debian 32-bit, Solaris x86 32-bit, and Solaris SPARC. And, my development system at home was a Digital Alpha running Linux 64-bit. The only problem we had was that the data base code used an algorithm where pointers would be stored with the keys, and could be on a non-natural boundary causing an exception on the SPARC. There were zero 32-bit to 64-bit issues. I've seen other code that it will take several man-years to get it to run properly on 64-bits.
The bottom line is that nearly every new laptop and desktop system being produced today uses 64-bit hardware, and Vista is very memory hungry to where you probably won't be able to get a 32-bit Windows platform. <note - I am bias toward 64-bits since I have been working in 64-bit land since at least 1994, and with 64-bit Linux roughly in the same time frame. I forget exactly when Linus actually had a 64-bit kernel for the Alpha, but it was 94 or 95.
Jerry Feldman wrote:
very poorly written, It's just that simple. From a developer standpoint, developing a portable application, eg. one that can be compiled for 32-bit or 64-bit and work out of the box is relatively simple if you follow some rules. The newer C and C++ language standards also have specific 32-bit and 64-bit integers, so you don't have to use "long" which can be 32-bits or 64-bits. I remember the same issue with 16-bit
Would you be willing to point to those 'relatively simple' techniques with a link?
Thanks.
stan wrote:
Jerry Feldman wrote:
very poorly written, It's just that simple. From a developer standpoint, developing a portable application, eg. one that can be compiled for 32-bit or 64-bit and work out of the box is relatively simple if you follow some rules. The newer C and C++ language standards also have specific 32-bit and 64-bit integers, so you don't have to use "long" which can be 32-bits or 64-bits. I remember the same issue with 16-bit
Would you be willing to point to those 'relatively simple' techniques with a link?
No link needed. Just don't make baseless assumptions about sizes of data types. Don't assume that a pointer is the same size as an int for example, or that the number 5000000000 will fit in a long int. Use uint32_t if you need a 32-bit number and so on. It's just that simple.
Even better, avoid C and use a better designed language with a good type system.
Björn Persson
On 10/31/2008 06:09 PM, Björn Persson wrote:
stan wrote:
Jerry Feldman wrote:
very poorly written, It's just that simple. From a developer standpoint, developing a portable application, eg. one that can be compiled for 32-bit or 64-bit and work out of the box is relatively simple if you follow some rules. The newer C and C++ language standards also have specific 32-bit and 64-bit integers, so you don't have to use "long" which can be 32-bits or 64-bits. I remember the same issue with 16-bit
Would you be willing to point to those 'relatively simple' techniques with a link?
No link needed. Just don't make baseless assumptions about sizes of data types. Don't assume that a pointer is the same size as an int for example, or that the number 5000000000 will fit in a long int. Use uint32_t if you need a 32-bit number and so on. It's just that simple.
Even better, avoid C and use a better designed language with a good type system.
Many times we don't have a choice. IMHO, C and C++ are still very good programming languages, and all programming languages have thier string and weak points. There used to be an excellent white paper on the HP DSPP site, but I am unable to locate it. (I was the author :-). Here are some suggestions: 1. avoid using int, long and longlong. Use int32_t, uint32_t when you specifically want 32-bit and int64_t and utint64_t when you want 64-bits. 2. Use size_t and ssize_t when you are using sizes. These will be the proper width on the platform. remember that the argument to malloc() is size_t, and size_t is returned from strlen() etc. The sizeof is also a size_t. 3. Be very careful of structs: Struct { int foo; long fubar; }; In the above struct, foo will always line up on a natural boundary (64-bit or 32-bit). On a 64-bit system, there will be a 32-bit filler between foo and fubar because fubar must line up on a natural boundary (32-bits for a 32-bit system, 64-bits for a 64-bit system). This almost bit me in the ass when I redesigned /etc/utmp for Tru64 Unix so we could use the same physical structure for utmp and utmpx. Fortunately we caught it in time. 4. Time. Historically, time_t in Unix was a signed 32-bit int representing the number of seconds from midnight 1/1/70. It goes negative in 2038. Some systems have converted to 64-bit time_t. Linux was able to adopt the 64-bit time_t quickly, but some commercial Unix systems still support 32-bit time_t. 5. Shifting and shift expressions. I'm going to avoid details here, but in the expression x << y, the expression takes on the type of x, not y. 6. There are some very pathological issues you can get into by combining signed and unsigned: #include <stdio.h> int main() { long res; int a = -2; unsigned b = 1; res = a * b; printf("Result is %ld\n", res); return 0; } The above C code will erroneously return 4294967294 rather than -2. The reason is that the expression (a * b) is an unsigned expression according to the rules in the C language standard, so that when the result is assigned to res, no sign extension occurs. One solution is to cast the expression as an int, then the sign extension occurs "(int)(a * b)".
Unfortunately, my white paper is no longer accessible on the HP site, but parts of it are in various porting guides. IBM also has some good documents.
On 11/01/2008 11:37 AM, Jerry Feldman wrote:
On 10/31/2008 06:09 PM, Björn Persson wrote:
stan wrote:
Jerry Feldman wrote:
very poorly written, It's just that simple. From a developer standpoint, developing a portable application, eg. one that can be compiled for 32-bit or 64-bit and work out of the box is relatively simple if you follow some rules. The newer C and C++ language standards also have specific 32-bit and 64-bit integers, so you don't have to use "long" which can be 32-bits or 64-bits. I remember the same issue with 16-bit
Would you be willing to point to those 'relatively simple' techniques with a link?
No link needed. Just don't make baseless assumptions about sizes of data types. Don't assume that a pointer is the same size as an int for example, or that the number 5000000000 will fit in a long int. Use uint32_t if you need a 32-bit number and so on. It's just that simple.
Even better, avoid C and use a better designed language with a good type system.
Many times we don't have a choice. IMHO, C and C++ are still very good programming languages, and all programming languages have thier string and weak points. There used to be an excellent white paper on the HP DSPP site, but I am unable to locate it. (I was the author :-). Here are some suggestions:
- avoid using int, long and longlong. Use int32_t, uint32_t when you
specifically want 32-bit and int64_t and utint64_t when you want 64-bits. 2. Use size_t and ssize_t when you are using sizes. These will be the proper width on the platform. remember that the argument to malloc() is size_t, and size_t is returned from strlen() etc. The sizeof is also a size_t. 3. Be very careful of structs: Struct { int foo; long fubar; }; In the above struct, foo will always line up on a natural boundary (64-bit or 32-bit). On a 64-bit system, there will be a 32-bit filler between foo and fubar because fubar must line up on a natural boundary (32-bits for a 32-bit system, 64-bits for a 64-bit system). This almost bit me in the ass when I redesigned /etc/utmp for Tru64 Unix so we could use the same physical structure for utmp and utmpx. Fortunately we caught it in time. 4. Time. Historically, time_t in Unix was a signed 32-bit int representing the number of seconds from midnight 1/1/70. It goes negative in 2038. Some systems have converted to 64-bit time_t. Linux was able to adopt the 64-bit time_t quickly, but some commercial Unix systems still support 32-bit time_t. 5. Shifting and shift expressions. I'm going to avoid details here, but in the expression x << y, the expression takes on the type of x, not y. 6. There are some very pathological issues you can get into by combining signed and unsigned: #include <stdio.h> int main() { long res; int a = -2; unsigned b = 1; res = a * b; printf("Result is %ld\n", res); return 0; } The above C code will erroneously return 4294967294 rather than -2. The reason is that the expression (a * b) is an unsigned expression according to the rules in the C language standard, so that when the result is assigned to res, no sign extension occurs. One solution is to cast the expression as an int, then the sign extension occurs "(int)(a * b)".
Unfortunately, my white paper is no longer accessible on the HP site, but parts of it are in various porting guides. IBM also has some good documents.
Forgot on other thing: When using manifest constants, such as "#define 5000000000" use the L or U suffix. And don't use something like: #define 0x80000000 to refer to the high order bit as it will only work in 32-bits, and possibly cause problems if used in a context of sign extension.
Jerry Feldman wrote: [snip]
Thanks for all the good tips. When I install F10, I'll go 64 bit and then will be able to use them. And check that everything works in both 32 bit and 64 bit systems.
On 11/01/2008 12:19 PM, stan wrote:
Jerry Feldman wrote: [snip]
Thanks for all the good tips. When I install F10, I'll go 64 bit and then will be able to use them. And check that everything works in both 32 bit and 64 bit systems.
I've been using 64-bits on my laptop for years, and the only issue is with some Firefox plugins, but they have all been resolved. It would be nice if Adobe would port flash to 64-bits and Sun would issue a 64-bit java plugin, but since the hardware world is moving to 64-bits, I'm sure that these will be resolved in near term.
On Mon, 27 Oct 2008 16:14:18 +0000, Alan Cox wrote: [snipperoo]
However if you cared about performance you wouldn't be running Gnome or Kde ;)
Some of my half-dozen machines are 64-bit and some not; so I do care about seeing this thread reach a resolution or consensus, if it can.
But your jest gives me a sneakin' hunch that "performance" has some technical meaning. Izzat so??
I had a machine once, running some early FC release, with some problems that I don't remember having understood, as a result of which it would throw itself at times into what I believe was a particular one of the super-lightweight window managers. I couldn't manage to do diddly- squat with it -- maybe, at best, get it to shut down in an orderly way, and try again whenever I got my nerve or my temper back.
I speak to the point, not to re-ignite ancient religious wars (and you may notice I have mentioned only Gnome <he wrote, ducking fast>), but merely to point out that to some of us, Gnome is a precondition of getting any performance at all -- at least, any of what I'd call performance. Alpha Plus Technoids' mileage may vary, of course, as usual. Which camp the OP belongs in, I have no clue. As for me, I vote three hearty cheers for the Gnome folks!
Am Sonntag, den 26.10.2008, 17:51 -0700 schrieb Agile Aspect:
Matthew Flaschen wrote:
Kevin Kofler wrote:
For the average desktop user, 64-bit has little or no benefit and is not worth the hassles of dealing with incompatible proprietary code (and yes, there is a hassle).
I concur.
Wondering about the "hassle", even with proprietary code.
Hassle used to show up, if you try to combine 32 bit and 64 bit code as running java (Sun's version) oder flash in a 64 bit firefox. Easiest solution is to use 32 bit firefox, if you really need that stuff. The Java problem is gone in FC9, if I remember correctly, and there are alternatives to Adobe's flash plugin (although they may not work with any web site).
I don't know of any 32 bit application, with can not be used in a 64 bit Fedora.
The 32 bit and the 64 version of a program have roughly the same memory footprint (most of the data types use the same amount of bytes, with the big exception of address pointers, of course)
Peter
Peter Boy <pboy <at> barkhof.uni-bremen.de> writes:
Matthew Flaschen wrote:
Kevin Kofler wrote:
For the average desktop user, 64-bit has little or no benefit and is not worth the hassles of dealing with incompatible proprietary code (and yes, there is a hassle).
I did not write that. Matthew Flaschen did.
There is no hassle. Everything just works.
Kevin Kofler
Matthew Flaschen <matthew.flaschen <at> gatech.edu> writes:
I like how you keep saying "all the benchmarks" and keep not linking to a single one.
Sorry, but I read them some time ago, so I remember the results, but not the URLs.
For the average desktop user, 64-bit has little or no benefit and is not worth the hassles of dealing with incompatible proprietary code (and yes, there is a hassle).
There is no hassle. Everything just works. For "incompatible proprietary code", there are 32-bit multilibs. (Not that you should use proprietary crap in the first place, but it _does_ work on 64-bit just as well as on 32-bit. If it is not compatible with the current Fedora, it won't run on the 32-bit edition either.)
Kevin Kofler
On Sat, Oct 25, 2008 at 03:28:30PM -0400, Charlie McVeigh wrote:
I apologize if this question has been asked before. I have a new Thinkpad T61 in scheduled to arrive sometime next week. I want to install Fedora 9 on it. Being as it has a Core 2 Duo processor, I assume I can install the 64 bit version of Fedora 9. My question is what are the pros and cons that I need to consider when choosing 32 or 64 bit version of Fedora 9? I am currently using a Thinkpad T42 running Fedora Core 7, so I have no experience with 64 bit linux or associated issues.
If you have to ask the answer is 32bit.
Two things: wireless and firefox plugins work smoother on 32 bit for me.
If your laptop disk is not massive, pairs of 32 and 64 bit libs could add up and prove problematic for disk space. Also since this is a laptop it is possible that the low power cpu, small processor cache, memory and disk subsystems would limit any performance improvement that 64bit objects might gain.
Having said this I have two 64 bit laptops. The older one running F8/32bit and the newer running F9/64bit. I found that Fedora 8 was just too early for 64 bit. I like F9 but it still has some issues to be addressed. Not so many that I felt a need to back off and reinstall the way I did on F8.
When F10 is out I plan to revisit 32 .vs. 64 bit on the older laptop then update the older laptop to match once I re-decide. I have found that I do most of my "64bit work" on a desk side running in the corner on my wireless net and the laptop can be running anything.
Of interest you might try some of the livecd images and test drive the two.
Summary: IMO, If you have to ask, the answer for a laptop is 32bit.
Nifty Fedora Mitch <niftyfedora <at> niftyegg.com> writes:
Two things: wireless and firefox plugins work smoother on 32 bit for me.
I don't see how wireless would be relates to 32-bit vs. 64-bit at all. As for browser plugins, that's what nspluginwrapper is for.
If your laptop disk is not massive, pairs of 32 and 64 bit libs could add up and prove problematic for disk space.
That's why Fedora does not install 32-bit multilibs by default now, so you can install only those you actually need (e.g. yum install nspluginwrapper.i386 if you want to use 32-bit browser plugins).
Also since this is a laptop it is possible that the low power cpu, small processor cache, memory and disk subsystems would limit any performance improvement that 64bit objects might gain.
F9 x86_64 works just fine on my laptop. Laptops these days have just as much RAM as desktops (usually between 1 and 4 GB). Also because Vi$ta is really memory-hungry and modern laptops are designed to run it.
Kevin Kofler
Charlie McVeigh wrote:
I apologize if this question has been asked before. I have a new Thinkpad T61 in scheduled to arrive sometime next week. I want to install Fedora 9 on it. Being as it has a Core 2 Duo processor, I assume I can install the 64 bit version of Fedora 9. My question is what are the pros and cons that I need to consider when choosing 32 or 64 bit version of Fedora 9? I am currently using a Thinkpad T42 running Fedora Core 7, so I have no experience with 64 bit linux or associated issues.
Thanks in advance for any and all advice.
Well, this has been answered very well previous to my reply, but let me add my experience to the mix.
If you are willing to deal with the issues, then x86_64 is for you. If not, then stick with the i386 stuff.
I upgraded a working FC6.i386 installation on my laptop to F9.x86_64. (Intel Core Duo T7200 @ 2GHz)
While the upgrade was not without problems, it went pretty smoothly once I forced it (ie, many "yum update" commands by hand, and reading the F9 release notes)! At the end I had a working F9.x86_64 system with the following "issues":
1) My lappie has an ATI Mobile Radeon X1600 video system. It worked on FC6 using the fglrx driver from livna. F9 upgraded Xorg to a version that fglrx does not yet support. OK, so its back to using the radeon driver under F9. It mostly works (I can still watch videos), but I can't help but feel that fglrx will give me better performance than I am currently getting. I tried the radeonhd driver and couldn't get it to work for me.
2) Many firefox plugins require nspluginwrapper because there are no x86_64 versions for them (Adobe Flash, Adobe Reader). Getting it to work correctly is straightforward and the Fedora Project Documentation is correct if you follow it. Sometimes Flash just doesn't work until I restart firefox. And the Acrobat embedded reader can bring the laptop to its knees with some sort of memory leak. Its also not as fast going through the nspluginwrapper. I sometimes have to wait 4-5 minutes for the embedded page to actually display (and sometimes it comes up right away). npviewer.bin is the application that sometimes runs wild. Especially if I am viewing a number of different PDFs sequentially and using the browser's BACK button between them. Some people have configured their browsers to run acroread as an external application directly (instead of the embedded reader) to get around this.
3) Sometimes sound gets screwed up in the browser (firefox). Even when using gecko-mediaplayer. Restarting the browser, or sometimes restarting the X session is necessary.
4) If you want to run vmware-server you might want to upgrade to the version 2.0 BETA which has an X86_64 RPM. (the version 1 version is i386 only). I had no trouble running the .i386 version of vmware-server with the appropriate compatibility libraries. Now I'm running the x86_64 BETA and it runs my 32-bit virtual machine just fine. You *MAY* need to find the latest version of vmware-anyanyupdate (or you may not) for vmware-server version 1.
5) Finding x86_64 versions of Firefox and Thunderbird ADDONs can be an adventure. So can finding addons that support firefox 3.0 in some cases.
6) WINE is i386 only. I tried to get sound working in WINE and discovered that it wanted to drag in lots of i386 libraries, not all of which were compatible with all of the x86_64 versions I have installed (some from livna, some from atrpms, some from fedora). I gave up on the conflicts and continue to run wine without support for sound.
7) FC6 used cubbi-suspend2 kernels in order to suspend and hiberate correctly. I was unable to make the tuxonice kernels work for me on F9, but the stock kernel support works fine with F9. (It may not be as fast as tuxonice, but it does suspend/hibernate and restore without any major problems.)
8) My wireless is now much more reliable with F9, but that could be the new iwl3945 driver and not the old ipw3945 driver.
YMMV
Charlie
Kevin J. Cummings <cummings <at> kjchome.homeip.net> writes:
If you are willing to deal with the issues, then x86_64 is for you. If not, then stick with the i386 stuff.
What issues?
- My lappie has an ATI Mobile Radeon X1600 video system. It worked on
FC6 using the fglrx driver from livna. F9 upgraded Xorg to a version that fglrx does not yet support.
This has nothing whatsoever to do with x86_64, it's exactly the same on F9 i386.
- Many firefox plugins require nspluginwrapper because there are no
x86_64 versions for them (Adobe Flash, Adobe Reader). Getting it to work correctly is straightforward and the Fedora Project Documentation is correct if you follow it.
So what's the problem there?
Sometimes Flash just doesn't work until I restart firefox. And the Acrobat embedded reader can bring the laptop to its knees with some sort of memory leak. Its also not as fast going through the nspluginwrapper.
But nspluginwrapper is used by default even on 32-bit installations for security reasons (because running the plugin in a separate process allows confining it with SELinux).
Some people have configured their browsers to run acroread as an external application directly (instead of the embedded reader) to get around this.
Or just don't use acroread at all, that's what Okular and Evince are for.
Konqueror can even embed Okular as a KPart if that's important to you.
- Sometimes sound gets screwed up in the browser (firefox). Even when
using gecko-mediaplayer. Restarting the browser, or sometimes restarting the X session is necessary.
I don't think this is related to 64-bit either.
- If you want to run vmware-server you might want to upgrade to the
version 2.0 BETA which has an X86_64 RPM. (the version 1 version is i386 only). I had no trouble running the .i386 version of vmware-server with the appropriate compatibility libraries. Now I'm running the x86_64 BETA and it runs my 32-bit virtual machine just fine. You *MAY* need to find the latest version of vmware-anyanyupdate (or you may not) for vmware-server version 1.
So where's the problem?
- Finding x86_64 versions of Firefox and Thunderbird ADDONs can be an
adventure.
OK, this is one valid argument. But the addons most people actually use should be available for x86_64.
So can finding addons that support firefox 3.0 in some cases.
This has nothing whatsoever to do with x86_64, it's exactly the same on F9 i386.
- WINE is i386 only. I tried to get sound working in WINE and
discovered that it wanted to drag in lots of i386 libraries, not all of which were compatible with all of the x86_64 versions I have installed (some from livna, some from atrpms, some from fedora). I gave up on the conflicts and continue to run wine without support for sound.
I don't know how you ended up with all those conflicts. You should not need anything not in Fedora to get sound in WINE working. "yum install alsa-plugins-pulseaudio.i386" should be enough, and that drags in only stuff from Fedora.
- FC6 used cubbi-suspend2 kernels in order to suspend and hiberate
correctly. I was unable to make the tuxonice kernels work for me on F9, but the stock kernel support works fine with F9. (It may not be as fast as tuxonice, but it does suspend/hibernate and restore without any major problems.)
This has nothing whatsoever to do with x86_64, it's exactly the same on F9 i386.
- My wireless is now much more reliable with F9, but that could be the
new iwl3945 driver and not the old ipw3945 driver.
This is actually a good thing, not a problem. :-) In any case, it's not x86_64-specific either.
Kevin Kofler
Kevin Kofler wrote:
Kevin J. Cummings <cummings <at> kjchome.homeip.net> writes:
If you are willing to deal with the issues, then x86_64 is for you. If not, then stick with the i386 stuff.
What issues?
Issues, hassles, basically the same. The things that have to be worked around.
- My lappie has an ATI Mobile Radeon X1600 video system. It worked on
FC6 using the fglrx driver from livna. F9 upgraded Xorg to a version that fglrx does not yet support.
This has nothing whatsoever to do with x86_64, it's exactly the same on F9 i386.
It wasn't when I first upgraded. The first problem was that the API changed and i386 worked and x86_64 didn't. Over time, ATI fixed that problem (took a couple of months), but not the Xorg version problem.
- Many firefox plugins require nspluginwrapper because there are no
x86_64 versions for them (Adobe Flash, Adobe Reader). Getting it to work correctly is straightforward and the Fedora Project Documentation is correct if you follow it.
So what's the problem there?
Maybe not a problem, but a big hassle. And, it didn't use to be that way on i386.
Sometimes Flash just doesn't work until I restart firefox. And the Acrobat embedded reader can bring the laptop to its knees with some sort of memory leak. Its also not as fast going through the nspluginwrapper.
But nspluginwrapper is used by default even on 32-bit installations for security reasons (because running the plugin in a separate process allows confining it with SELinux).
Again, it didn't use to be that way. Its a hassle.
Some people have configured their browsers to run acroread as an external application directly (instead of the embedded reader) to get around this.
Or just don't use acroread at all, that's what Okular and Evince are for.
When you say "don't use X" and "X" is written by the people who defined it, you are basically saying that the standard definers don't know what they are doing.... Seems very strange. None of the replacements ever work as well as the original. At least for me. Its a hassle.
Konqueror can even embed Okular as a KPart if that's important to you.
I don't use Konqueror.
- Sometimes sound gets screwed up in the browser (firefox). Even when
using gecko-mediaplayer. Restarting the browser, or sometimes restarting the X session is necessary.
I don't think this is related to 64-bit either.
Maybe not, but I never noticed it until I upgraded to x86_64.
- If you want to run vmware-server you might want to upgrade to the
version 2.0 BETA which has an X86_64 RPM. (the version 1 version is i386 only). I had no trouble running the .i386 version of vmware-server with the appropriate compatibility libraries. Now I'm running the x86_64 BETA and it runs my 32-bit virtual machine just fine. You *MAY* need to find the latest version of vmware-anyanyupdate (or you may not) for vmware-server version 1.
So where's the problem?
Hassle! Please stop changing the intent of my words!
- Finding x86_64 versions of Firefox and Thunderbird ADDONs can be an
adventure.
OK, this is one valid argument. But the addons most people actually use should be available for x86_64.
OK, so you're telling me I'm using the wrong addons? B^)
So can finding addons that support firefox 3.0 in some cases.
This has nothing whatsoever to do with x86_64, it's exactly the same on F9 i386.
Maybe so, but its a hassle.
- WINE is i386 only. I tried to get sound working in WINE and
discovered that it wanted to drag in lots of i386 libraries, not all of which were compatible with all of the x86_64 versions I have installed (some from livna, some from atrpms, some from fedora). I gave up on the conflicts and continue to run wine without support for sound.
I don't know how you ended up with all those conflicts. You should not need anything not in Fedora to get sound in WINE working. "yum install alsa-plugins-pulseaudio.i386" should be enough, and that drags in only stuff from Fedora.
The problem is not with alsa-plugins-pulseaudio, its with jack-audio-connection-kit, needed by wine-jack.
- FC6 used cubbi-suspend2 kernels in order to suspend and hiberate
correctly. I was unable to make the tuxonice kernels work for me on F9, but the stock kernel support works fine with F9. (It may not be as fast as tuxonice, but it does suspend/hibernate and restore without any major problems.)
This has nothing whatsoever to do with x86_64, it's exactly the same on F9 i386.
Maybe so, bu I ran into it after I upgraded to x86_64.
- My wireless is now much more reliable with F9, but that could be the
new iwl3945 driver and not the old ipw3945 driver.
This is actually a good thing, not a problem. :-) In any case, it's not x86_64-specific either.
Kevin Kofler
Kevin J. Cummings <cummings <at> kjchome.homeip.net> writes:
What issues?
Issues, hassles, basically the same. The things that have to be worked around.
My question was: can you please list the actual issues, hassles or however you want to call them? Because most of what you listed is either: * no hassle at all (like a single yum install line will solve your problem) or * not an issue with x86_64: you upgraded from FC6 to F9 at the same time as your 32->64-bit migration. That's a big upgrade, skipping 2 releases even. So saying "this worked better on my old FC6 i386" is completely irrelevant for the question which started this thread, which is "should I go with F9 i386 or F9 x86_64?".
This has nothing whatsoever to do with x86_64, it's exactly the same on F9 i386.
It wasn't when I first upgraded. The first problem was that the API changed and i386 worked and x86_64 didn't. Over time, ATI fixed that problem (took a couple of months), but not the Xorg version problem.
Fglrx just plain didn't work on F9, be it 32-bit or 64-bit. They now have a beta out which should work, it's up at RPM Fusion for both i?86 and x86_64.
- Many firefox plugins require nspluginwrapper because there are no
x86_64 versions for them (Adobe Flash, Adobe Reader). Getting it to work correctly is straightforward and the Fedora Project Documentation is correct if you follow it.
So what's the problem there?
Maybe not a problem, but a big hassle. And, it didn't use to be that way on i386.
How is "yum install nspluginwrapper.i386" a hassle? It's one line!
But nspluginwrapper is used by default even on 32-bit installations for security reasons (because running the plugin in a separate process allows confining it with SELinux).
Again, it didn't use to be that way. Its a hassle.
But that's a change in Fedora 9 (actually it was in Fedora 7 or 8 already, but in any case it's like that in F9).
Or just don't use acroread at all, that's what Okular and Evince are for.
When you say "don't use X" and "X" is written by the people who defined it, you are basically saying that the standard definers don't know what they are doing.... Seems very strange. None of the replacements ever work as well as the original. At least for me. Its a hassle.
The original is not Free Software, so of course it will cause more problems than the replacements which are.
And if you believe the best software is always made by the people who defined a standard, stop using Firefox and use Amaya instead, it's from the W3C. :-D (FYI, don't bother, it's essentially useless as a browser. It may arguably have some use as a website editor, but even there there are better alternatives.)
Konqueror can even embed Okular as a KPart if that's important to you.
I don't use Konqueror.
Your loss. ;-)
- Sometimes sound gets screwed up in the browser (firefox). Even when
using gecko-mediaplayer. Restarting the browser, or sometimes restarting the X session is necessary.
I don't think this is related to 64-bit either.
Maybe not, but I never noticed it until I upgraded to x86_64.
But that doesn't mean it is relevant for the i386 vs. x86_64 discussion.
- If you want to run vmware-server you might want to upgrade to the
version 2.0 BETA which has an X86_64 RPM. (the version 1 version is i386 only). I had no trouble running the .i386 version of vmware-server with the appropriate compatibility libraries. Now I'm running the x86_64 BETA and it runs my 32-bit virtual machine just fine. You *MAY* need to find the latest version of vmware-anyanyupdate (or you may not) for vmware-server version 1.
So where's the problem?
Hassle! Please stop changing the intent of my words!
How's running the latest version of your software a hassle?
OK, this is one valid argument. But the addons most people actually use should be available for x86_64.
OK, so you're telling me I'm using the wrong addons? B^)
^^
So can finding addons that support firefox 3.0 in some cases.
This has nothing whatsoever to do with x86_64, it's exactly the same on F9 i386.
Maybe so, but its a hassle.
But that doesn't mean it is relevant for the i386 vs. x86_64 discussion.
The problem is not with alsa-plugins-pulseaudio, its with jack-audio-connection-kit, needed by wine-jack.
You don't need wine-jack to get sound in WINE. JACK is not the default sound server in Fedora, PulseAudio is.
- FC6 used cubbi-suspend2 kernels in order to suspend and hiberate
correctly. I was unable to make the tuxonice kernels work for me on F9, but the stock kernel support works fine with F9. (It may not be as fast as tuxonice, but it does suspend/hibernate and restore without any major problems.)
This has nothing whatsoever to do with x86_64, it's exactly the same on F9 i386.
Maybe so, bu I ran into it after I upgraded to x86_64.
But that doesn't mean it is relevant for the i386 vs. x86_64 discussion. The fact that you happened to upgrade from FC6 to F9 at the same time is completely irrelevant here.
Kevin Kofler
Kevin Kofler wrote:
Kevin J. Cummings <cummings <at> kjchome.homeip.net> writes:
What issues?
Issues, hassles, basically the same. The things that have to be worked around.
My question was: can you please list the actual issues, hassles or however you want to call them? Because most of what you listed is either:
- no hassle at all (like a single yum install line will solve your problem) or
- not an issue with x86_64: you upgraded from FC6 to F9 at the same time as
your 32->64-bit migration. That's a big upgrade, skipping 2 releases even. So saying "this worked better on my old FC6 i386" is completely irrelevant for the question which started this thread, which is "should I go with F9 i386 or F9 x86_64?".
The OP asked for "any and all advice". Please don't change the subject.
This has nothing whatsoever to do with x86_64, it's exactly the same on F9 i386.
It wasn't when I first upgraded. The first problem was that the API changed and i386 worked and x86_64 didn't. Over time, ATI fixed that problem (took a couple of months), but not the Xorg version problem.
Fglrx just plain didn't work on F9, be it 32-bit or 64-bit. They now have a beta out which should work, it's up at RPM Fusion for both i?86 and x86_64.
No, actually, there were 2 different problems. The first was an x86_64 only problem as a symbol was no longer exported by the x86_64 kernel that fglrx relied upon, but was still present in the i386 kernel.
The second problem was common to both i386 and x86_64.
Having 2 problems on x86_64 made it more difficult to diagnose and track down.
- Many firefox plugins require nspluginwrapper because there are no
x86_64 versions for them (Adobe Flash, Adobe Reader). Getting it to work correctly is straightforward and the Fedora Project Documentation is correct if you follow it.
So what's the problem there?
Maybe not a problem, but a big hassle. And, it didn't use to be that way on i386.
How is "yum install nspluginwrapper.i386" a hassle? It's one line!
Not for me, but just look at all of the question in this list alone for people asking why it doesn't work for them.
But nspluginwrapper is used by default even on 32-bit installations for security reasons (because running the plugin in a separate process allows confining it with SELinux).
Again, it didn't use to be that way. Its a hassle.
But that's a change in Fedora 9 (actually it was in Fedora 7 or 8 already, but in any case it's like that in F9).
The OP was talking about a change from FC6 to F9, just like I had done.
Or just don't use acroread at all, that's what Okular and Evince are for.
When you say "don't use X" and "X" is written by the people who defined it, you are basically saying that the standard definers don't know what they are doing.... Seems very strange. None of the replacements ever work as well as the original. At least for me. Its a hassle.
The original is not Free Software, so of course it will cause more problems than the replacements which are.
Actually, the original reader is available for free download. Don't cloud the issue.
And if you believe the best software is always made by the people who defined a standard, stop using Firefox and use Amaya instead, it's from the W3C. :-D (FYI, don't bother, it's essentially useless as a browser. It may arguably have some use as a website editor, but even there there are better alternatives.)
PDF was designed (and released) by Adobe. Its their reader that doesn't have an x86_64 release, and therefore is the problem causing us to have to use nspluginwrapper. And the fact that you have to install *BOTH* versions of nspluginwrapper (.i386 and .x86_64) makes it even more confusing.
Konqueror can even embed Okular as a KPart if that's important to you.
I don't use Konqueror.
Your loss. ;-)
B^)
- Sometimes sound gets screwed up in the browser (firefox). Even when
using gecko-mediaplayer. Restarting the browser, or sometimes restarting the X session is necessary.
I don't think this is related to 64-bit either.
Maybe not, but I never noticed it until I upgraded to x86_64.
But that doesn't mean it is relevant for the i386 vs. x86_64 discussion.
Back to what the OP wanted, "any and all advice".
- If you want to run vmware-server you might want to upgrade to the
version 2.0 BETA which has an X86_64 RPM. (the version 1 version is i386 only). I had no trouble running the .i386 version of vmware-server with the appropriate compatibility libraries. Now I'm running the x86_64 BETA and it runs my 32-bit virtual machine just fine. You *MAY* need to find the latest version of vmware-anyanyupdate (or you may not) for vmware-server version 1.
So where's the problem?
Hassle! Please stop changing the intent of my words!
How's running the latest version of your software a hassle?
Lack of available x86_64 is a hassle in my book. The latest copy is still a BETA (or was when I last downloaded it). Not everyone *wants* to run BETA software.
OK, this is one valid argument. But the addons most people actually use should be available for x86_64.
OK, so you're telling me I'm using the wrong addons? B^)
^^
So can finding addons that support firefox 3.0 in some cases.
This has nothing whatsoever to do with x86_64, it's exactly the same on F9 i386.
Maybe so, but its a hassle.
But that doesn't mean it is relevant for the i386 vs. x86_64 discussion.
Back to the OP's original request again....
The problem is not with alsa-plugins-pulseaudio, its with jack-audio-connection-kit, needed by wine-jack.
You don't need wine-jack to get sound in WINE. JACK is not the default sound server in Fedora, PulseAudio is.
Because of the way I upgraded from FC6, I'm not running PulseAudio.... Perhaps that *my* problem. I like to think that's Fedora's lack of proper upgrade path problem.
- FC6 used cubbi-suspend2 kernels in order to suspend and hiberate
correctly. I was unable to make the tuxonice kernels work for me on F9, but the stock kernel support works fine with F9. (It may not be as fast as tuxonice, but it does suspend/hibernate and restore without any major problems.)
This has nothing whatsoever to do with x86_64, it's exactly the same on F9 i386.
Maybe so, bu I ran into it after I upgraded to x86_64.
But that doesn't mean it is relevant for the i386 vs. x86_64 discussion. The fact that you happened to upgrade from FC6 to F9 at the same time is completely irrelevant here.
But, its what the OP wants to do.... So please explain why it is irrelevant?
Kevin Kofler
Do you just like to argue? This is getting quite pointless now. If you wish, you can have the last word.
Kevin J. Cummings <cummings <at> kjchome.homeip.net> writes:
The OP asked for "any and all advice". Please don't change the subject.
Are you going to give out fishing or gardening advice next? How about cooking? Of course he meant "any and all advice" relevant to his question...
No, actually, there were 2 different problems. The first was an x86_64 only problem as a symbol was no longer exported by the x86_64 kernel that fglrx relied upon, but was still present in the i386 kernel.
The second problem was common to both i386 and x86_64.
But as fglrx was useless on F9 either way, the x86_64 issue didn't make it any worse.
Having 2 problems on x86_64 made it more difficult to diagnose and track down.
It was well documented that fglrx was not updated for the new X11 in F9, please read the release notes and the list of known issues next time, then you don't waste your time "diagnosing" well-known issues.
Not for me, but just look at all of the question in this list alone for people asking why it doesn't work for them.
If it can wean those people off their dependency on proprietary plugins, that's a good thing. :-p
But seriously, having to run one single line when installing third-party stuff which is NOT part of Fedora is not quite a "hassle". And there's also other stuff you have to install by hand for various proprietary stuff, for example libflashsupport.i386 which is not installed by default even on i386 and which is needed to get working sound with PulseAudio in Flash 9 (Flash 10 has finally be fixed to use ALSA properly so it works with the PulseAudio ALSA plugin, as usual, proprietary software lags behind).
The OP was talking about a change from FC6 to F9, just like I had done.
He's actually running F7, not FC6. And he was asking about the choice between F9 i386 and F9 x86_64.
The original is not Free Software, so of course it will cause more problems than the replacements which are.
Actually, the original reader is available for free download. Don't cloud the issue.
I said Free Software, not freeware. Free Software is about freedom, not price. http://www.gnu.org/philosophy/free-sw.html (And the opposite is "proprietary software", which includes proprietary freeware like the stuff Adobe releases for no cost.) You are the one clouding the issue.
PDF was designed (and released) by Adobe.
That doesn't mean their reader is the best one. It's actually ugly, slow, proprietary and not well-integrated into the distro.
Fedora is a Free Software (and as above, I mean "free" as in "free speech" there, not as in "free beer"!) distribution, of course Free Software (as in "speech") will be better supported than proprietary software. So you should not be surprised that you get asked why you don't just use one of the Free Software alternatives which are included in Fedora and work perfectly fine when you complain about issues with the proprietary Adobe Reader.
Its their reader that doesn't have an x86_64 release,
And that's one of the issues with it, but...
and therefore is the problem causing us to have to use nspluginwrapper.
... you don't have to use it as a browser plugin, you can just run it as an external process.
And the fact that you have to install *BOTH* versions of nspluginwrapper (.i386 and .x86_64) makes it even more confusing.
Of course you do, you need the x86_64 version to actually plug into the browser and the i386 version to actually run the plugin. It's the whole principle of how nspluginwrapper works.
But as far as I know, nspluginwrapper.x86_64 is actually installed by default for Firefox users these days.
Lack of available x86_64 is a hassle in my book. The latest copy is still a BETA (or was when I last downloaded it). Not everyone *wants* to run BETA software.
If the beta is the only version that actually works, why not?
Proprietary software will always lag behind, and they'll always label their much needed updates as "beta" because they're paranoid about supporting new features. You'll have to get used to use betas if you want to run proprietary software on a fast-moving GNU/Linux distribution such as Fedora. And it's not just x86_64, for example the only version of fglrx supporting F9 at all (even i386) is a beta.
Because of the way I upgraded from FC6, I'm not running PulseAudio.... Perhaps that *my* problem. I like to think that's Fedora's lack of proper upgrade path problem.
Easy to fix again (and not a 64-bit issue, but an upgrade issue, still it's relevant for the OP who's upgrading for F7): If you run GNOME: yum groupinstall sound-and-video gnome-desktop If you run KDE, this should be enough: yum install kde-settings-pulseaudio but you can also use: yum groupinstall sound-and-video kde-desktop to get the other new stuff in those groups.
See also https://fedoraproject.org/wiki/YumUpgradeFaq (some of the information in which can be helpful even if you upgrade the official way, through Anaconda).
Kevin Kofler
Kevin J. Cummings wrote:
Kevin Kofler wrote:
Kevin J. Cummings <cummings <at> kjchome.homeip.net> writes:
What issues?
Issues, hassles, basically the same. The things that have to be worked around.
My question was: can you please list the actual issues, hassles or however you want to call them? Because most of what you listed is either:
- no hassle at all (like a single yum install line will solve your
problem) or
- not an issue with x86_64: you upgraded from FC6 to F9 at the same
time as your 32->64-bit migration. That's a big upgrade, skipping 2 releases even. So saying "this worked better on my old FC6 i386" is completely irrelevant for the question which started this thread, which is "should I go with F9 i386 or F9 x86_64?".
The OP asked for "any and all advice". Please don't change the subject.
Whoa! This is getting personal, gang. Back to your respective corners.
What the op SHOULD have said was "I'm upgrading from F7 to F9. Should I go with the 32- or 64-bit version of F9?" That's really two questions. An upgrade from F7 to F9 is going to be one hell of a gear change in and of itself. I would have warned him of that first off. Things are different in F9 land.
Once that's been dispatched, what KK said about the differences between 32- and 64-bit F9 is pretty much true. 90% of the issues the OP had weren't 32- vs. 64-bit, but rather F7 vs. F9. I think this all got rather muddled in the subsequent discussions.
While I tend to agree with KK regarding proprietary vs. free (speech) software, there are times where you're just farking stuck using the proprietary stuff. When there is a choice and the functionality I need is available in the the free (speech or beer) version, that's what I use.
Ok, bowing out. Wait for the bell, touch gloves and swing away.
DING! (running for cover) ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer ricks@nerd.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - What is a "free" gift? Aren't all gifts free? - ----------------------------------------------------------------------
Charlie McVeigh wrote:
I apologize if this question has been asked before. I have a new Thinkpad T61 in scheduled to arrive sometime next week. I want to install Fedora 9 on it. Being as it has a Core 2 Duo processor, I assume I can install the 64 bit version of Fedora 9. My question is what are the pros and cons that I need to consider when choosing 32 or 64 bit version of Fedora 9? I am currently using a Thinkpad T42 running Fedora Core 7, so I have no experience with 64 bit linux or associated issues.
Thanks in advance for any and all advice.
Charlie
FWIW - I run 64bit FC7 and FC8 on my laptops without issue. ON FC7 I installed a 32 bit version of firefox to save on plugin issues (just don't use Acrobat reader it's crap).
I use my laptop for development with 4g memory, run's like a charm. Installing Fedora 8 from scratch worked fine, but I had to install the nvidia drivers to get the best performance.
Cheers, Peter.
On Sun, 26 Oct 2008 15:20:40 +1100 Peter McNeil peter@mcneils.net wrote:
(just don't use Acrobat reader it's crap).
Unfortunately, acroread is the only pdf reader that is capable of displaying some files. Certain items (mostly graphics) disappear from some pages or come out as black boxes using evince, kpdf or xpdf.
I would love to use one of those instead of acroread, but my attempts to do so have been failures so far. I create pdf files using Scribus which get transferred to plates for printing on presses and acroread is equivalent to nuking the site from orbit. ("It's the only way to be sure.")
https://bugzilla.redhat.com/show_bug.cgi?id=220983
-
Aaron Konstam -
Agile Aspect -
Alan Cox -
Beartooth -
Bill Davidsen -
Björn Persson -
Charlie McVeigh -
Frank Cox -
Jerry Feldman -
Kevin Cummings -
Kevin Kofler -
Matthew Flaschen -
Mogens Kjaer -
Nifty Fedora Mitch -
Peter Boy -
Peter McNeil -
Richard Shaw -
Rick Stevens -
sean darcy -
stan