Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
OS X Businesses Operating Systems Apple

Panther Will Not be a 64-bit OS 229

Posted by pudge from the call-your-senator dept.
rouge86 writes "The Register has an article on what Mac OS X 10.3 will be like. Mac OS X 10.3, aka Panther, will not be a 64-bit operating system, despite running on a 64-bit processor. Instead, the next major release of the Mac operating system will be a hybrid, much like version 10.2.7." You mean they didn't rewrite the entire operating system from the ground up? And that it will run on older, 32-bit, Macs? I am shocked!
This discussion has been archived. No new comments can be posted.

Panther Will Not be a 64-bit OS More

Panther Will Not be a 64-bit OS

Comments Filter:

  • Names... (Score:5, Funny)

    by kenthorvath ( 225950 ) on Tuesday July 08, 2003 @10:35AM (#6391961)
    Who wants to place bets on the name of the next hybrid OS? We've had Cheetah, Puma, Jaguar, Panther, and now I'm guessing they'll switch to a softer more feminine side of things, like Tigger, or Hello Kitty. Anyone with me on this?

  • You should not expect a 64bits OS yet (Score:5, Insightful)

    by Smartcowboy ( 679871 ) on Tuesday July 08, 2003 @10:38AM (#6391995)
    On the PC scene:

    First 32 bits CPU: 386, 1985
    First somewhat 32 bits OS: Windows 95, 1995

    Hopefuly, it won't take so long for 64bits

  • Therefore backwards compat is not an acceptable excuse.

  • It will be interesting (Score:5, Interesting)

    by serialdj ( 593159 ) on Tuesday July 08, 2003 @10:43AM (#6392078)
    At this moment I am awaiting Apple to ship the G5's, and when it does I'll be interested to see how this new architecture works, as compared to my current G4. What I'm awaiting is who will be the first to release the first 64-bit system for it. Does this remind anyone when Apple first released the first PowerPC, and only like 10% of the code was optimized for it.

    • Re:It will be interesting (Score:5, Insightful)

      by RevAaron ( 125240 ) <{moc.liamtoh} {ta} {noraaver}> on Tuesday July 08, 2003 @11:21AM (#6392496) Homepage
      Does this remind anyone when Apple first released the first PowerPC, and only like 10% of the code was optimized for it [?]

      Superficially it does. However, there are a lot of differences between the switch from 68k and PPC and that of PPC/32 to PPC/64. There isn't emulation required, nor is a bunch of code rewriting to get your app optimized for the G5. It's a matter of installing the dev tools update, and recompiling. Things weren't that easy in the 68k->PPC transition days...
      • Yeah for a while you were actually better off getting a Quadra or other 68k based computer than a PPC because the PPC was running most everything in emulation; I remember how slow I originally thought my 7100/66 was when I first got it.

      • Re:It will be interesting (Score:5, Insightful)

        by Steve Cowan ( 525271 ) on Tuesday July 08, 2003 @02:19PM (#6394364) Journal
        there are a lot of differences between the switch from 68k and PPC and that of PPC/32 to PPC/64. There isn't emulation required, nor is a bunch of code rewriting to get your app optimized for the G5. It's a matter of installing the dev tools update, and recompiling. Things weren't that easy in the 68k->PPC transition days...

        Agreed... a more accurate analogy might be waiting for AltiVec optimization. When the G4 was introduced, most software ran a bit faster on it, but certain apps saw incredible performance boosts when they were made AltiVec-aware.

  • What are you getting at, pudge? (Score:5, Interesting)

    by mackstann ( 586043 ) on Tuesday July 08, 2003 @10:47AM (#6392118) Homepage
    You mean they didn't rewrite the entire operating system from the ground up? And that it will run on older, 32-bit, Macs? I am shocked!

    All of the BSDs and Linux support 64-bit, and as far as I know, they weren't rewritten "from the ground up." They are all also compatible with both 32- and 64-bit machines, so I don't see legacy hardware compatability being a huge problem.

    • Re:What are you getting at, pudge? (Score:5, Informative)

      by pudge ( 3605 ) * <slashdot@@@pudge...net> on Tuesday July 08, 2003 @11:20AM (#6392488) Homepage Journal
      You are confusing 64-bit support with a 64-bit OS. You shouldn't. Panther does indeed have 64-bit support.
      • From what the article says, it has a few 64-bit-ish hacks to let 32bit apps take advantage of some 64-features, is that what you mean by "support?" A little more explanation would be nice.

      • You are confusing 64-bit support with a 64-bit OS. You shouldn't.

        Yeah, I guess I have been too. Care to go for a +5 Informative and school me on the difference?

      • Re:What are you getting at, pudge? (Score:5, Informative)

        by sergeantmudd ( 647674 ) on Tuesday July 08, 2003 @04:15PM (#6395565)
        On the PowerPC, you can run 32-bit programs and 64-bit programs at the same time. Apple has chosen to keep the bulk of the OS at 32-bits because there is no advantage in upgrading. Remember, 64-bits is only useless for large memory addresses or really really big integers. For example, iTunes does not need more than 4-GB of RAM, so it will probably say 32-bits. Panther will support running 64-bit binaries, so say Final Cut Pro can address a large amount of RAM, but the collection of programs that make up the OS will probably stay 32-bit.


        And I don't know why people are ripping on this strategy. This way Apple doesn't have to Ship 10.3 for the G5 and a seperate 10.3 for the G4. That just confuses customers and pisses off people who have a G4 and a G5. Now Apple can ship one version and only have small changes between the G4 and G5 versions, and let the installer make the appropiate changes. Also, Solaris did the same thing. Alot of there utilities were 32-bit for a long long time after 64-bit support came out, programs like top simply do not receive any advantages from being 64-bit.

      • Some benefits of 64-bit support (Score:5, Funny)

        by TomatoMan ( 93630 ) on Tuesday July 08, 2003 @07:36PM (#6396777) Homepage Journal
        Don't forget, slashdotters - programs run twice as fast in an OS with 64-bit support as in one with only 32-bit support. You can run two side-by-side 32-bit "shells" by only using half the bus for each, or you can just run one twice as fast. You also get twice the screen space, you can fit twice as much in RAM, and your Diablo II stash will be twice as big and you'll get twice as many skill points. That's the part I really can't wait for.

  • Re-write? (Score:5, Informative)

    by booch ( 4157 ) <slashdot2010@@@craigbuchek...com> on Tuesday July 08, 2003 @10:47AM (#6392127) Homepage
    You don't have to re-write code to make it 64-bit. You just have to re-compile it. Granted, you have to make sure it's 64-bit safe code, but there's not all that much effort involved in that. Basically, you just can't assume that you have 32-bit integers and pointers.

    For instance, the Linux kernel was made 64-bit safe in version 2.0, when they added support for the Alpha architecture. It's one code base that can be compiled for different architectures, some 32-bit, some 64-bit. There's not a whole lot of 64-bit specific code.

    Most Open Source programs are 64-bit clean now. I'd think Apple's programmers would have been working to make sure all the Mac OS X code is 64-bit clean.
    • I'm sure they have some processing sugar (like syntatical sugar) to make things easier or better for developers for the 64 bit world. Not stupid things like adding two floats, but taknig advangates of being able to do some "neat" stuff.

    • Re:Re-write? (Score:5, Informative)

      by RevAaron ( 125240 ) <{moc.liamtoh} {ta} {noraaver}> on Tuesday July 08, 2003 @11:14AM (#6392428) Homepage
      Read the article- the version of OS X they're talking about will be not just be the plain-old 32 bit version running on the G5, but a 64-bit aware OS that can take advantage of a number of the 64 bit features.

      Getting apps to take advantage of this is a matter of a recompile, and Apple released the tools at WWDC to get your apps to suppoer the 64 bit features. I imagine they binaries will ship in the same package- either the OS will discriminate, or there will be two binaries in the package.

      • Re:Re-write? (Score:5, Informative)

        by booch ( 4157 ) <slashdot2010@@@craigbuchek...com> on Tuesday July 08, 2003 @12:20PM (#6393085) Homepage
        Yes, the OS will be able to run 64-bit apps, but it sounds like not much of the OS itself will have even been re-compiled. And you're right that there are things you can do to optimize performance on 64-bit systems beyond just re-compiling and making sure things are 64-bit safe.

        As far as binaries containing 32-bit and 64-bit versions, NeXT has long had "fat binaries". (Not sure if MacOS had fat binaries in the transition from 68K to PowerPC.) The executable would have versions for multiple CPUs, and the OS would chose the right one. I suspect that's still easily supported in Mac OS X.

        As the article said though, often you'll have a 32-bit app with a few optionally-used 64-bit sections.

  • What's up with the news these days? (Score:5, Insightful)

    by Duke Thomas ( 684070 ) on Tuesday July 08, 2003 @10:58AM (#6392266)

    Instead, the next major release of the Mac operating system will be a hybrid, much like version 10.2.7

    So what? This is already known. We know the OS itself will be capable of addressing 8 GB, that is, more than 32 bits. We also already know it will run on 32 bit processors since Panther made its debut on a G4.

    I don't mean to be snarky, and I know that post keynote is always slow, but it seems the ./ Apple news moderation hasn't been up to task lately. Yesterday we had "news" because someone managed to compile a some open source software using the new QT libraries (and did nothing else, from the looks of it). When I manage to build ImageMagick's shared libs under OS X, I'll be counting on it being on the front page. :P

  • Er, uh, wha...? (Score:5, Interesting)

    by thatguywhoiam ( 524290 ) on Tuesday July 08, 2003 @10:59AM (#6392274)
    So, let me get this straight.

    According to El Reg, Panther is not a true 64-bit operating system. However, Panther can do 64-bit tricks. So many 64-bit tricks that it works and behaves as a 64-bit OS would, accessing more than 8 GB of RAM, and so forth, if asked... but its not 64-bit.

    I think I'll file under 'makes no difference to me'.

  • Uhm (Score:4, Interesting)

    by Leimy ( 6717 ) on Tuesday July 08, 2003 @11:00AM (#6392280)
    Smeagol is a 32-bit operating system, though certain libraries and other elements have been recoded to allow applications - and the OS itself - to make use of the 64-bit addressing and datapaths, sources close to Apple said. For example, that's how the Power Mac G5 is able to support at least 8GB of memory, double the 32-bit limit of 4GB. Panther will adopt the same approach, said the source.

    Don't Pentiums with PAE have this ability. 64 bit doesn't mean "double" the addressability. A fully 64bit address is 2^32 * 2*32 or roughly 4 billion SQUARED. Somone needs to learn binary :).

    The Opteron doens't have full 64bit addressing either... I think its like 42 or 48bits.

    • Re:Uhm (Score:2)

      by Leimy ( 6717 )
      actually I only accounted for the leftmost bit on an unsigned 64bit value I suppose :).

    • Re:Uhm (Score:3, Informative)

      by rsmith-mac ( 639075 )
      PAE isn't a "real" solution like going to 64bits is; the processor is still 32bits, so it's doing paging tricks to get past the 4GB barrier. Those tricks work, but it has a very noticable speed penelty for doing so. One other thing to keep in mind right now is that just because the chip arcitecture supports 4bil^2 worth of memory, doesn't mean that current devices are designed to use it. That much memory is overkill, and designing a chipset/CPU at this point that can use that much is just as much overkill.

    • Re:Uhm (Score:5, Funny)

      by dafz1 ( 604262 ) on Tuesday July 08, 2003 @11:40AM (#6392681)
      Is it just me, or is it a bad idea to name an OS update after Smeagol? He killed his brother, took the Ring(which corrupted him), lost the Ring, finds the boys and leads them to be eaten. Failing that, in his jubilation after biting off Frodo's finger, accidentally kills himself and destroys everything immediately around him. This sounds more like a Windows update to me.

      Maybe Samwise would have been more appropriate? Actually, why name it after LoTR characters at all considering everything was rendered on Dells? I would say name it after Nemo, but that movie was rendered on Intel processors too. Too bad the CEO of Pixar doesn't know anyone at Apple.

      • Re:Uhm (Score:5, Funny)

        by David Leppik ( 158017 ) on Tuesday July 08, 2003 @11:52AM (#6392809) Homepage
        Is it just me, or is it a bad idea to name an OS update after Smeagol? He killed his brother, took the Ring(which corrupted him), lost the Ring, finds the boys and leads them to be eaten. Failing that, in his jubilation after biting off Frodo's finger, accidentally kills himself and destroys everything immediately around him. This sounds more like a Windows update to me.
        Yeah, but it will have great Tolkien Ring support!

      • Re:Uhm (Score:3, Funny)

        by Anonymous Coward
        ...accidentally kills himself and destroys everything immediately around him.

        Well, thank you very much for ruining the plot of RoTK for me...next time preface your spoiler posts as such. I'm sure that there are a lot of /.ers who won't go see the movie now that it's ruined.

  • Amazing. (Score:5, Insightful)

    by Anonymous Coward on Tuesday July 08, 2003 @11:00AM (#6392291)
    It's truly astounding to see how many people purport to have an understanding of what "64-bit" means, but in fact do not.

    There are three criteria that define "64-bitness."

    One: can an application running on a given combination of hardware and software address up to 18 billion gigs of virtual memory?

    Two: can an application running on said hardware and software read from and write to files that are up to 9 billion gigs long?

    Three: can an application running on said hardware and software do arithmetic with 64-bit integers and doubles?

    Existing Macs running Mac OS X have two and three down. File offsets are signed long longs (up to 2^63, or 9 billion billion), and any application can manipulate long longs and doubles.

    G5's running Mac OS X 10.2.7 will have one taken care of. Now, in the current generation G5, memory is actually limited in hardware to four thousand gigabytes, and limited in practical terms to eight gigabytes. But applications can, nonetheless, allocate and address up to 18 billion gigs of virtual memory. The OS won't stop them from doing that. (Pointers under 10.2.7 with the 64-bit compiler settings are unsigned long longs, 2^64, or 18 billion billion.)

    So by any meaningful criteria, Mac OS X 10.2.7 running on G5 hardware will be a 64-bit OS. So will Panther.

    The guy who wrote the register article basically doesn't understand what "64-bit OS" means.

    • Re:Amazing. (Score:5, Informative)

      by ivan256 ( 17499 ) * on Tuesday July 08, 2003 @12:26PM (#6393133)
      Now, in the current generation G5, memory is actually limited in hardware to four thousand gigabytes, and limited in practical terms to eight gigabytes. But applications can, nonetheless, allocate and address up to 18 billion gigs of virtual memory. The OS won't stop them from doing that.

      The PPC 970 only implements 42 virtual address bits. Similarly, other current 64 bit microprocessors only implement a subset of the available 64 bits in their MMU. In short, an application running on a PPC 970 processor will only be able to address 2^42 bytes, or 4 terabytes of memory.
      • And 4 Terabytes should be enough for everybody!

        DJCC

      • Re:Amazing. (Score:3, Informative)

        by gbooker ( 60148 )
        Actually, it is 52 bit for the older PowerPC's: Page 7-35 [ibm.com] It is 64 or 80 for the 970: Page 258 [ibm.com].

        It is also important to note that these values are a per program basis if you are willing to change around some special registers in your context switches.
        • The PEM is an architecture specification that describes features for the entire processor family. Any individual processor in the family need not support all the features described in that document. In the 970 they chose to honor only 42 of the address bits. I suggest you check out the other documents on IBM's PPC 970 product page. In particular this one [ibm.com].

          Also, the 80 bit address is an intermediate value used in the hashed page table calculation and is not exposed to the user.
          • First of all, broken link. I assume you were refering to this. [ibm.com] Now, you first mentioned 42bit VIRTUAL ADDRESSES. There is a BIG DIFFERENCE between virtual and real addresses.

            There are three address types:
            Effective: This is the address that the program sees. This may (and often does) have very little to do with the real address
            Virtual: This is used only within the MMU and Page tables.
            Physical (Real): This is the actual address in the memory.

            Now, the link you provided states 42bits of real address.

    • Re:Amazing. (Score:3, Insightful)

      by esme ( 17526 )
      The criteria you lay out are fine and good, but leave out a crucial aspect: for a system to be 64-bit, it's assumed these tasks are done with minimal software intervention.

      So while the G5 can handle 64-bit math and memory/file addressing, it sounds like 10.2.7 and apps running on it aren't going to be using those. They're going to be using the existing emulations, and a few extra hacks bolted on a the last minute to get a few extra bits on the memory address space.

      IMHO, if it's still thunking 64-bit o

      • Re:Amazing. (Score:5, Informative)

        by Anonymous Coward on Tuesday July 08, 2003 @03:37PM (#6395229)
        So while the G5 can handle 64-bit math and memory/file addressing, it sounds like 10.2.7 and apps running on it aren't going to be using those.

        Wrong and right. Any program that runs on the G5 will get 64-bit math automatically. File addressing is already 64-bit. Memory addressing will continue to be 32-bit until you recompile with -mpowerpc64.

        They're going to be using the existing emulations, and a few extra hacks bolted on a the last minute to get a few extra bits on the memory address space.

        Wrong. The kernel will use full 64-bit addressing; it already does so in 10.2.7. No emulation will be necessary, at any level. Applications will have 32-bit pointers unless they're specifically compiled for 64-bit pointers. This is, incidentally, a good thing. Applications with 64-bit pointers do not use cache as efficiently as those with 32-bit pointers. Take the same application and compile it in 32- and 64-bit versions, and the 32-bit version will be measurably faster on the same hardware.

        IMHO, if it's still thunking 64-bit operations down to 32-bit operations in software, it's not really 64-bit.

        IMHO, if you don't know what "64-bit" actually means, you should probably think twice before posting in a thread like this. Just friendly advice.

        • Re:Amazing. (Score:4, Insightful)

          by inertia187 ( 156602 ) * on Tuesday July 08, 2003 @04:25PM (#6395644) Homepage Journal
          Applications with 64-bit pointers do not use cache as efficiently as those with 32-bit pointers. Take the same application and compile it in 32- and 64-bit versions, and the 32-bit version will be measurably faster on the same hardware.

          Umm...does that mean a 16-bit and 8-bit versions will be measurably faster on the same hardware too? Just checking...thanks.

          • Re:Amazing. (Score:5, Informative)

            by Anonymous Freak ( 16973 ) <.moc.duolci. .ta. .kaerfsuomynona.> on Wednesday July 09, 2003 @12:12AM (#6398211) Journal
            Yes. Assuming the data being processed is only 16-bits or 8-bits wide. For example, if you were to make a piece of photo editing software that could only do 8-bit grayscale images, it would be more efficient as an 8-bit program than as a 32-bit program. (Assuming that the host processor had an 8-bit instruction set that is the same as it's 32-bit instruction set.) Likewise, if you write it as a 16-bit program, and have a fully modern 16-bit OS to go with it, (say, ELKS, the 16-bit Linux derivative,) and run it on a Pentium 4, it would be faster than the same thing (again, processing 16-bit data) on a 32-bit version.

            In the case of the PowerPC 970, it is the exact same instruction set, in 32-bit or 64-bit modes. The only difference is the data being processed. If you don't *NEED* to use 64-bit data, then 32-bit mode will be faster, as you're not 'padding' the data with an extra 32-bits of unecessary info. The PowerPC architecture was designed from the get-go to be 64-bit, with 32-bit as a subset of it. Until now, there haven't been any PowerPC processors that have been capable of processing the full 64-bit width of data though. (Yes, the original PowerPC 601 could theoretically be redesigned to allow 64-bit data, and it wouldn't take too terribly much work.)

            It's not at all like the IA-32 (386-Pentium 4/Xeon/AthlonXP,) AMD-64 (Athlon64/Opteron,) or the IA-64 (Itanium) architectures.

            IA-32 was a kludge of the existing 16-bit instruction set. AMD-64 is a further extension of the old 16-bt set. IA-64 is an all-new instruction set, not at all compatible with the old IA-32. (The Itanium Processors have hardware IA-32 decoders in them, but the IA-64 spec doesn't call for it at all. Intel could make a later Itanium that cannot run existing 32-bit code at all, and it would be fully compliant with the IA-64 spec.)

    • Re:Amazing. (Score:3, Interesting)

      by prockcore ( 543967 )
      Following your criteria, you could say DOS was a 32 bit OS.

      This is really no different than using hacks like emm386
    • The Apple engineer I worked with in the G5 performance lab at WWDC told me that while the OS can address over 4 GB of memory using 64-bit addresses, each running process was limited to a 4 GB virtual address space.

      That sounds rather limited to me.

      • Re:I'm not so sure about that... (Score:2, Informative)

        by Anonymous Coward
        The Apple engineer I worked with in the G5 performance lab at WWDC told me that while the OS can address over 4 GB of memory using 64-bit addresses, each running process was limited to a 4 GB virtual address space.

        That's true, but only if you don't recompile your applications specifically for the G5. If you rebuild (or do a separate build) with the compiler option -mpowerpc64, you get LP64 (longs and pointers are 64-bit, in other words). When you do that, you can malloc to your heart's content, up to 18 b

  • It's the end of the Mac (Score:5, Funny)

    by chia_monkey ( 593501 ) on Tuesday July 08, 2003 @11:25AM (#6392536) Journal
    Mac OS X 10.3, aka Panther, will not be a 64-bit operating system, despite running on a 64-bit processor. Instead, the next major release of the Mac operating system will be a hybrid, much like version 10.2.7

    Well there ya go. Obvious testament that the beleaguered company is doomed to fail. The nerve!

    I wonder how long it will take for someone to be serious about how Apple is failing because of this. Bets anyone?

  • This is ignorance (Score:3, Insightful)

    by Ballresin ( 398599 ) on Tuesday July 08, 2003 @09:30PM (#6397373) Homepage Journal
    The OS was RECOMPILED to work with the 64 bit processor. This is stupid. Why are you saying it isn't a 64 bit OS. Because it doesn't have 64 bit code? So? It only matters that it can address the processor and make use of that ability.
    Dumb

  • Many answers for the 64bit question ! (Score:5, Informative)

    by The Ego ( 244645 ) on Tuesday July 08, 2003 @10:37PM (#6397717)
    There are many ways for an OS to be "a 64-bit OS". However programmers/users of existing 64bits OSes will typically check a single criterion, which is unlikely to be met by OS X 10.3 .

    1. An OS could be called "64bits OS" because it allows programs running on the computer to use 64bits-instructions, while leaving them with 32bits pointers. This is typically done by offering a 64bits datatype (int64_t/uint64_t in C99 compliant environments) and a compiler that will emit the right instruction sequences. It also requires that the underlying OS will be made somehow "64bits aware", ie that it will save/restore the full 64bits content of processor registers on context switches. My understanding is that Panther/10.3 will allow that, or at least most of that.

    2. An OS could be called "64bits OS" because parts of the kernel (VM / buffer cache, ...) can make use of memory beyond the 4GB limit by using specific APIs that work around the 32bits pointers limitation. I hope that Panther will allow that.

    3. An OS could be called "64bits OS" because it allows the usage of more than 4GB of memory by all userland processes, while any given process is still limited to 4GB (32 bits pointers). My understanding is that Panther will do that.

    4. An OS could be called "64bits OS" because the kernel code is compiled to follow a 64bits ABI (Application Binary Interface). In such an ABI, pointers are 64bits entities and some integer types are also 64bits. While an ABI covers _a lot more_ ground than just the size of the common C types, those sizes are often used to characterize the ABI. The most common 64bits ABI is known as LP64 (aka I32LP64) where "int" remain 32bits, while "long" and "void*" are 64bits. By comparison the most common 32bits ABI is known as ILP32 (int, long, void* are all 32 bits). I don't think any "common" OS offered a ILP64 model (Cray maybe?). Windows64 is a different beast, being LLP64 (aka IL32 LLP64), where int and long are 32bits, while "long long" and pointers are 64bits. My understanding is that this will _not_ be the case for Panther, the kernel code will be compiled with a ILP32 ABI.

    5. An OS could be called "64bits OS" because it offers a 64bits ABI to userland applications compiled in "64bit mode". My understanding is that this will _not_ be the case for Panther, all code will be compiled with the traditional ILP32 ABI.

    My "belief"/"understanding" of the Panther situation comes from reading the WWDC reports, rumours reports and also the Darwin development mailing list where one Apple employee said that OS X won't offer an LP64 ABI until much later (not in Panther, at _least_ not in 10.3.0 and I doubt any 10.3.x release).

    Most current users of 64bits systems will only use criterion 5, but I expect Apple PR to try to muddle the issue. And I won't blame them much, the issue is not as clear cut as some users think.

    Some tidbits related to 64bits platforms:
    - HP-UX 11.00 shipped as two different kernels, one 32bits kernel and one 64bits kernel. 64bits machines could run either of them, while 32bits machines were restricted to the 32bits kernel.
    On the 64bits kernel a user could run 32 and/or 64bits processes, while the 32bit kernel could only run 32bits processes.
    It sometimes made sense for the owner of a 64bits machine to only install the 32bits kernel, if they didn't intend to run any 64bits application and didn't have more than 4GB of ram (rare then). Running the 64bits kernel typically consumed a bit more memory and consumed a bit more memory bandwidth.

    - Linux on 64bits machines is "pure" 64bits (today, this may change due to ISV pressure). It doesn't run anything but programs compiled with the 64bits ABI (I32LP64). A special case is Linux IPF (IA64) which also runs 32bits apps, but those aren't "native" applications using the Itanium ISA but x86 binaries running using the hardware (now) or software (future) emulation. Another special case will be Linux on x86-64 which also has to run "emulat

  • About 64/32 bit compat... (Score:2, Informative)

    by Anonymous Coward
    From Apple's site:

    Native compatibility with 32-bit application code

    For PC users, going from 32-bit to 64-bit computing requires migrating to a 64-bit operating system (and purchasing the 64-bit applications that will work on it) or running a 32-bit operating system in slow-as-molasses emulation mode. The PowerPC G5, however, offers a seamless transition to 64-bit performance: Current 32-bit code -- such as Mac OS X, the Mac OS 9 Classic environment and existing applications -- runs natively at processor s

Slashdot Top Deals

Hold on to the root.

Close