rendezvouscp said:
I can't understand how people keep getting this wrong.
G1=PPC 601 series [IBM/Motorola]
G2=PPC 603/603e and 604/604e series [IBM/Motorola]
G3=PPC 75x series [IBM]
G4=PPC 7xxx series [Motorla/Freescale]
G5=PPC 970 series [IBM]
ACK!
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
OS X x86 FAQ
- Thread starter slb
- Start date
- Sort by reaction score
I can't understand how people keep getting this wrong.
G1=PPC 601 series [IBM/Motorola]
G2=PPC 603/603e and 604/604e series [IBM/Motorola]
G3=PPC 75x series [IBM]
G4=PPC 7xxx series [Motorla/Freescale]
G5=PPC 970 series [IBM]
ACK!
Diatribe said:
Yeah, I watched it a little after I posted that (the stream wasn't available at the time). Knowing that Mac OS X will be around longer is nice, but another chip-switch doesn't sound so merry.
primalman said:
The 6000 series wasn't PPC, right? I thought that chips in the G1 and G2 era were 6000 and not 600, hence the confusion. Thanks.
Seems like I'm a bit dull, eh Baron58 (btw, I like your nick)? I've one more thing to worry about. I remember reading articles about pipelines and all that jazz, and that Intel processors had more pipelines than PPC processors, which attributed to system slowdowns. Has Intel done something about this, or does it really matter?
-Chase
bit density said:
Apple has already stated they will be locking Leopard to the new Macs. See post # 17 in this thread.
The advantage is in maintaining control of the number of hardware device conflicts presented by cheap knockoff components. A secondary advantage is to limit the number of DIY "Build-then-pirate" users out there.
This is neither supposition nor xenophobia but the stated and published direction Apple is taking. Whining and trolling about wanting Leopard for your Wintel box doesn't make it real.
Building a version for the open x86 market would require Apple to build as bloated and backward compatible an OS as MS and present similar goofiness as a result. Do you really want a Mac OS that's constantly asking you for permission to install a new driver and then not booting successfully because of some conflict between cheapass components?
If building an Universal version of the OS was wise I'm sure it would have been done first... But realize that building an universally installable OS (though it sounds cool) would kill Apple's hardware business almost overnight.
stcanard said:
Per this page (http://developer.apple.com/transitionkit.html ) OS X will actually be pre-installed on the kit. I take this to mean it will be installed on the HDD, no CD. I guess you could call that a disk, but I'd like to clarify it.
Assumption: It will be Intel hardware in a Powermac case, probably with a special motherboard.
stcanard said:Ahh, so that's how they are planning to avoid the inevitable bittorrent leak. Don't give anyone an installable image
Makes sense actually.
I guess if you screw up your OS then its $1000 down the drain then?
Unless you make a backup.
Then compress the backup and store it in a bittorrent for safe keeping.
Kidding, of course.
so, would there be anything to stop me from buying a power mac and replacing the intel chip with an AMD?
admanimal said:
IF its CMOS/BIOS I think I'll start polishing my G5 everyday so it'll last the next half century. BIOS in PCs cause soo many problems! First of all we may have to have the hole 1980s looking startup screen! ARGH.
SpaceMagic said:
No they don't.
As for the startup screen, can you not read earlier posts in this thread? Try Post 39.
bentley said:
This is likely going to happen and it might be good for the consumer. The only thing bad I can see is when it comes to software developing. If they know you can run Windows on a Macintel just as fast as a PC, what is to say they will just drop development on a Mac version. What is the point to having a Mac and Windows version of the same software if the x86 Mac will run both equally?
bentley said:
Abercrombieboy said:
OS X being on Intel will NOT make Windows -> Mac ports easier.
I know other people have stated this, but I'll repeat it: Windows and Mac use completely different programming interfaces, which means that a lot of code needs to be rewritten in order to move an app from Windows -> Mac. This code has nothing to do with the CPU architecture.
If it does in fact become common practice for people to run OS X and Windows on a Mac either by dual booting or using a Virtual PC like program, then maybe we will have the issue that Abercrombieboy mentions. I don't necessarily see this happening, but that's just my speculative opinion.
Here's my theory on what's going to happen with the names of the PB and PM.
The term "power" is the the names of PB and PM because they are Apple's higher-end models of computers and laptops. People who use these machines are called "Power users" by Apple. Do people have PowerPC processors in them? Obviously not. So, "power" is used by Apple as a term to describe the hard drive capacity, processor speed, etc. The names will stay the same.
The term "power" is the the names of PB and PM because they are Apple's higher-end models of computers and laptops. People who use these machines are called "Power users" by Apple. Do people have PowerPC processors in them? Obviously not. So, "power" is used by Apple as a term to describe the hard drive capacity, processor speed, etc. The names will stay the same.
Abercrombieboy said:
We can only assume that Apple is looking to reduce the number of hurdles between them and game developers. Part of this strategy is providing excellent tools like xCode. It's likely that Apple is looking to the Longhorn conversion as a potential differentiation point for developers. IE: If Apple can make Leopard easier to develop games for than Windows it may pull development onto the platform. It also helps that Apple has experience writing for current and future Windows via iTunes. Building their software standards to ease conversion along with building more conversion scripts into xCode could do the trick nicely.
My question is; will this switch open up hardware updates to mac users, like ATI and NVidia graphic cards, which are often available to the PC market and generally cheaper then the Apple equivalent. Will these suddenly be a viable and useable alternative on the x86 Mac?
rickvanr said:
Perhaps a bit cheaper but don't go looking to plug in any of the cheapass generic cards sporting ATI and Nvidia chipsets. There's likely to be some driver issues still, though the differences on the board should be reduced to near zero so it's quite possible that a broader variety of actual ATI and nVidia hardware will ship as "Mac Compatible" for less $$ than the current crop.
I'm curious about the use of a Pheonix BIOS. This seems like a major step back from OpenFirmware. I'm curious what will change between now and next year. Apple has already stated that people should look at Intel's roadmap for next year to see exactly which Intel chips will be shipping in Mac computers, so obviously the dev machine is not a determinant of what Intel Macs will be like.
slb said:
That is correct: We don't know what will be used.
What we do know is that usually Steve will say what he means if it's within current scope.
My guess is that since the statement to developers was simply "It won't be open firmware" and not "We'll be using x or y BIOS" the Mobo will be a typically Apple custom job with an entirely new firmware setup. Likely Apple will take this as an oppertunity to build something as clean as Open Firmware but designed for a customized Intel-built Mobo.
This is an excellent oppertunity for Stevo to come out on stage and say: "Open firmware was getting long in the tooth, BIOS has always been cumbersome so we built something new that outperforms both." Most likely it'll be technology (yet again) from NeXt.
Tealeaf said:
That looks likely. It even provides a nice, tidy way to customize the chipset, firmware and drivers such that OS X would still remain platform-specific. It would make installing Window$ on a Mac more of a challenge too...
Dig into Intel's technical briefs on that one and you'll find that it isn't one standard firmware implementation but a standard way of implementing custom firmware.