" Less capable on the server end perhaps, but you're dreaming if you think Mac OS X is less capable as a desktop workstation than Linux, of all things. The server market is Linux's strength, and frankly, I think it's a waste of time to try and make it a desktop operating system. The desktop market requires consistency and attention to UI detail. Entrusting these things to freelance geeks coding in their spare time and expecting results on par with those of multibillion-dollar corporations is unrealistic. "
Meh. Capability can be defined many ways.
MacOS X is more capable assuming the users need a system that's easy to use. I agree that that is usually the case, but it simply doesn't apply if a user is willing to deal with the command line.
Linux is more capable for those users partly because they get more machine for their money. For example, I need dual displays and the cheapest desktop Mac that can do it is a $2000 PowerMac. Tweaked to meet my needs (2 gigs memory), more like $2500 not including displays. I don't get much utility out of a second CPU, I just don't do stuff that requires it, so I'd prefer not to spend money to get it. Even the single-CPU PowerMacs were too expensive for what they had. The Mac that meets my needs is much more expensive than the PC that meets my needs.
Linux is more capable for those users partly because a lot of software that doesn't have a GUI never got ported to OS X. It could probably be ported, but no one has. Also, there is binary-only software for Linux. A lot of this is command line stuff that Mac users just aren't interested in, and that will never get a GUI but is useful despite that.
Linux is more capable for those users partly because it's more customizable, performs better, and is more up to date (Java etc).
I don't advocate Linux as a desktop for most people, but people that are willing and able to use it can usually get more out of it. They may have to resort to the command line, but when they want capabilities that don't have a GUI anywhere they're not at a disadvantage.
"What if you just have some random garbage on your drive? (output from "cat/dev/random" as I often use for testing things) That would not be readable and might be considered "encrypted". How can they tell?"
The same thought occured to me.
Indeed, if I lived there I would consider preparing several such files and stating publically and in advance that that's exactly what I was doing. They're not encrypted, so it is impossible to provide the key. Assuming it's impossible to distinguish between an encrypted file and a random file, they can't prove that the crime of withholding a key was comitted.
Simply state publically that you're going to be placing large files of random bits on your hard drive. They're not encrypted. Ideally, you can't tell an encrypted file from a random one.
"So wait. You think of OS X has a stepping stone to Linux?"
You can learn the basics of how to use Linux, and once you're conversant on the shell Linux much easier to learn.
"Seriously, I think OS X is way less daunting than Linux."
It's also way less capable.
Linux will do almost anything but lacks polish in some areas. MacOS X is very polished but lacks capabilities. They are not interchangable, but they are also not mutually exclusive.
That doesn't help on laptops. Sure I can use a mouse when I have plenty of space to myself, but sometimes there just isn't room or I need to be ready to pack up quickly. Also, the lack of a scroll wheel is particularly annoying.
"Very true. But as long as Apple keeps some G5 chips in the product line, they can always make the claim (more or less) that the Ghz factor different is superficial due to the processor architecture differences. What hurts their credibility on this is the reports that the developer Intel based Macs are running universal binaries faster than the existing PowerMac G5 line."
Indeed. And the professional types buying PowerMacs and PowerBooks are in general more capable of objectively assessing the performance (PowerPC zealots notwithstanding). I'm sure there will be readily available benchmarks. If a Pentium M iBook is faster and someone buys it when they would have been willing to pay for a PowerBook, Apple misses out on a fair amount of money.
"The other problem is that there are plenty of other Joe Consumer off-the-shelf apps that haven't been converted either so Joe Consumer might buy a Mac Mini or an iBook and encounter software that won't run (or run decently) on their new Intel based Macs."
I think Joe Consumer doesn't have much software that won't run under emulation. The heavily optimized, CPU-bound stuff is generally professional territory, and the G4s in PowerBooks are slow enough that it may not matter. The people that need to watch out are the ones running optimized software on a G5.
"The other issue is stepping back from 64-bit back down to 32-bit. While I could see that for the portable line (since they were only G4s) and the Mac Mini, I can't see Apple doing that for the PowerMacs. Me thinks Apple won't switch those until there's a non-*Itanic*II 64-bit offering from Intel."
I agree, but Intel has x86-64 Pentiums. The portable chips aren't there yet, but in 2006-2007 Intel will be transitioning the Pentium M to their desktop and server lines and adding 64-bit support. There are even rumors that Pentium M 64-bit support will be available in the first half of 2006. I imagine Apple will transition PowerMacs when Pentium M based Xeons with 64-bit support are available since they need dual processors.
As you say it's not an issue on PowerBooks, and I wouldn't be surprised if Apple were willing to put a 32-bit chip in iMacs. That being said, it'll really be a shame if isn't fully 64-bit from day 1. Transitioning like this is an opportunity to ditch a lot of legacy stuff. If they're not 64-bit, they'll need all new drivers when they do end up switching and getting 3rd party drivers for OS X is like pulling teeth as it is.
"Perhaps Apple/Motorola should have stripped the 68040 emulation from the PowerPC chip and simply bundled the 68060 in addition, but that wouldn't have weeded off a lot of the developers from that chip"
It makes sense for Apple to do the same thing on PowerPC. They need people to switch quickly.
"From all indications, Apple already designed PowerBooks that used G5 chips long before IBM finally made the low power/low heat chip available. Thus the (over) engineering has already been paid for so they might as well capture some of that expense back through new sales...."
You make an interesting point. I hadn't considered that.
"Bringing out Pentium-based PowerBooks wouldn't be very wise since the ProApps (which is what most PowerBook users use if you believe Apple) have not been compiled over to Intel based builds yet, from all that has been mentioned online so far."
That's another good point, but I remain skeptical.
Consider:
Apple prefers to keep a performance advantage on premium lines.
Current Pentium Ms have a performance advantage over G5s at the same clock speed, and they go a lot higher than 1.6 ghz. The Yonah core will widen the gap in performance per mhz and number of mhz, particularly in floating point performance where Pentium Ms are currently weak.
Therefore it will be difficult for Apple to put Pentium Ms in iBooks before PowerBooks. Apple is unlikely to ship an iBook with decreased clock speed over the current versions, and at 1.4 ghz a Pentium M still does well against a 1.6 ghz G5.
The new Yonah core will have dual-core versions, and even under emulation a dual-core 2 ghz Pentium M will have acceptable performance compared to a 1.6 ghz G5. It may not be faster, but it's not going to be that much slower.
Apple never shipped a computer with a 68060 chip, despite the fact that they were much faster than 68040s. PowerPC emulating 68k was faster than a 68040 natively but not faster than a 68060.
It's possible Apple will ship a G5 PowerBook, but it would put them in a pretty awkward position.
No. The MPC8641D is not socket-compatible with current G4s. A compatible version could probably be produced, but it would be stuck with the MPX bus that has left G4s castrated for so long. It slows down G4s now and if there were two cores on the same bus it would be even worse. An incompatible version will not be used because the costs associated with a new chipset and new motherboard design would be wasted when they'll be selling the things for less than a year.
I think it's pretty likely that PowerBooks will get dual-core Pentium Ms though.
Not a chance. If anything gets them, it'll be PowerBooks, and I doubt even that much. They won't be selling them for long enough to justify the expense and Pentium Ms are so much faster than 1.6 ghz G5s that it would be pointless.
"So yeah, some of us actually HAVE been exposed to, and DO care, about these sorts of things."
The question is: why should anyone with a compiler care? How often does desktop software need assembly programming?
"If all I have realisticly available to me is crappy-ass broken-by-design, unreliable, wintel trash; I may as well have CHEAP, crappy-ass, broken-by-design, unreliable, wintel trash."
Apple PowerPC hardware was slower in addition to being overpriced. At least now it's just overpriced.
I'd rather get another hour out of my batteries than get a processor that works in network byte order. And I'm a developer.
"Why, o why do they always make changing the C++ ABI such an effort? It takes some credibility out of C++ as a stable lower-level programming target if such a relatively frequently occuring change in the core obsoletes so much essential packages."
The GCC people are the ones changing the ABI, and they're the ones losing credibility.
"pages load so fast for me on my dual g5 that it's like switching channels on my TV."
Congratulations. Your $3000 computer is fast. Firefox on my iBook (700 mhz G3 384 mb) is many times slower than Firefox on my OpenBSD machine (400 mhz Pentium II 256).
G3s aren't slower than Pentium IIs. MacOS X isn't slower than OpenBSD. Mac software doesn't have to be slow. The Firefox port just happens to be really, really bad.
"From a user perspective, its unacceptible that the new systems can't emulate support for our software. I understand from a developer perspective."
Apparently I'm wrong about altivec emulation being slower than an equivilant scalar code path. Whether or not that's so, I've given up speculating. If you have trouble whenever Apple does something that doesn't make sense, you're in for a lot of trouble.
"Look at it this way, if apple's claims that Intel chips are truely superior in every way are true, then PPC G4 emulation should be trivial."
They never claimed that. The only specific performance claim I've seen from Apple is that they're better at integer performance per watt.
Interestingly, I've been hearing rumors about oil companies looking at building nuclear reactors in Alberta to generate hydrogen for the tar sands. The hydrocarbons are too big to be useful in the state they're in naturally, so additional hydrogen is needed to produce useful oil.
Natural gas production in North America has peaked, so the current source of hydrogen will get expensive soon.
Some of the benchmarks don't rely on the OS. For example, memory latency doesn't change from one OS to the next.
However, OS X was beaten pretty badly by Linux on benchmarks that do depend on the OS so testing it on the same hardware may be a negative. Some difference could be accounted for by the hardware, but not the factor of 2-5 that OS X lost by...
"If Apple used hand coded assembly they never would have been able to go from PPC to x86. Why do you think they would start now?"
It's common for developers concerned with performance to profile an application and hand-tune a few hotspots. Only a tiny amount of assembly needs to be written.
It's not portable, but OTOH it's not that much code to re-write.
There's no reason in principal that Altivec couldn't be emulated, but I strongly suspect it's not supported because because emulating it would be slower than forcing applications to use alternate code paths that don't require altivec.
Not all applications can do that, so it's a problem, but it's not like Apple to make things complicated by adding extra options.
"Aren't these Mac's using a 32-bit Intel proc? Does Apple really intend to replace a 64-bit machine with a 32-bit one?"
The chip in the dev boxes is 64-bit, but Apple doesn't support it with the OS.
"What does this comparison really say? Will it be faster at even the Altivec/dual proc enhanced apps (like filters filters for photoshop, rendering video, etc...)"
As always, it depends on what you're doing, but Altivec apps can become SSE apps, and it's likely Apple will offer dual-processor Intel machines.
Slashdot Mirror
I have mod points but I've commented.
" Less capable on the server end perhaps, but you're dreaming if you think Mac OS X is less capable as a desktop workstation than Linux, of all things. The server market is Linux's strength, and frankly, I think it's a waste of time to try and make it a desktop operating system. The desktop market requires consistency and attention to UI detail. Entrusting these things to freelance geeks coding in their spare time and expecting results on par with those of multibillion-dollar corporations is unrealistic. "
Meh. Capability can be defined many ways.
MacOS X is more capable assuming the users need a system that's easy to use. I agree that that is usually the case, but it simply doesn't apply if a user is willing to deal with the command line.
Linux is more capable for those users partly because they get more machine for their money. For example, I need dual displays and the cheapest desktop Mac that can do it is a $2000 PowerMac. Tweaked to meet my needs (2 gigs memory), more like $2500 not including displays. I don't get much utility out of a second CPU, I just don't do stuff that requires it, so I'd prefer not to spend money to get it. Even the single-CPU PowerMacs were too expensive for what they had. The Mac that meets my needs is much more expensive than the PC that meets my needs.
Linux is more capable for those users partly because a lot of software that doesn't have a GUI never got ported to OS X. It could probably be ported, but no one has. Also, there is binary-only software for Linux. A lot of this is command line stuff that Mac users just aren't interested in, and that will never get a GUI but is useful despite that.
Linux is more capable for those users partly because it's more customizable, performs better, and is more up to date (Java etc).
I don't advocate Linux as a desktop for most people, but people that are willing and able to use it can usually get more out of it. They may have to resort to the command line, but when they want capabilities that don't have a GUI anywhere they're not at a disadvantage.
"What if you just have some random garbage on your drive? (output from "cat /dev/random" as I often use for testing things) That would not be readable and might be considered "encrypted". How can they tell?"
The same thought occured to me.
Indeed, if I lived there I would consider preparing several such files and stating publically and in advance that that's exactly what I was doing. They're not encrypted, so it is impossible to provide the key. Assuming it's impossible to distinguish between an encrypted file and a random file, they can't prove that the crime of withholding a key was comitted.
Simply state publically that you're going to be placing large files of random bits on your hard drive. They're not encrypted. Ideally, you can't tell an encrypted file from a random one.
"So wait. You think of OS X has a stepping stone to Linux?"
You can learn the basics of how to use Linux, and once you're conversant on the shell Linux much easier to learn.
"Seriously, I think OS X is way less daunting than Linux."
It's also way less capable.
Linux will do almost anything but lacks polish in some areas. MacOS X is very polished but lacks capabilities. They are not interchangable, but they are also not mutually exclusive.
That doesn't help on laptops. Sure I can use a mouse when I have plenty of space to myself, but sometimes there just isn't room or I need to be ready to pack up quickly. Also, the lack of a scroll wheel is particularly annoying.
"Very true. But as long as Apple keeps some G5 chips in the product line, they can always make the claim (more or less) that the Ghz factor different is superficial due to the processor architecture differences. What hurts their credibility on this is the reports that the developer Intel based Macs are running universal binaries faster than the existing PowerMac G5 line."
Indeed. And the professional types buying PowerMacs and PowerBooks are in general more capable of objectively assessing the performance (PowerPC zealots notwithstanding). I'm sure there will be readily available benchmarks. If a Pentium M iBook is faster and someone buys it when they would have been willing to pay for a PowerBook, Apple misses out on a fair amount of money.
"The other problem is that there are plenty of other Joe Consumer off-the-shelf apps that haven't been converted either so Joe Consumer might buy a Mac Mini or an iBook and encounter software that won't run (or run decently) on their new Intel based Macs."
I think Joe Consumer doesn't have much software that won't run under emulation. The heavily optimized, CPU-bound stuff is generally professional territory, and the G4s in PowerBooks are slow enough that it may not matter. The people that need to watch out are the ones running optimized software on a G5.
"The other issue is stepping back from 64-bit back down to 32-bit. While I could see that for the portable line (since they were only G4s) and the Mac Mini, I can't see Apple doing that for the PowerMacs. Me thinks Apple won't switch those until there's a non-*Itanic*II 64-bit offering from Intel."
I agree, but Intel has x86-64 Pentiums. The portable chips aren't there yet, but in 2006-2007 Intel will be transitioning the Pentium M to their desktop and server lines and adding 64-bit support. There are even rumors that Pentium M 64-bit support will be available in the first half of 2006. I imagine Apple will transition PowerMacs when Pentium M based Xeons with 64-bit support are available since they need dual processors.
As you say it's not an issue on PowerBooks, and I wouldn't be surprised if Apple were willing to put a 32-bit chip in iMacs. That being said, it'll really be a shame if isn't fully 64-bit from day 1. Transitioning like this is an opportunity to ditch a lot of legacy stuff. If they're not 64-bit, they'll need all new drivers when they do end up switching and getting 3rd party drivers for OS X is like pulling teeth as it is.
"Perhaps Apple/Motorola should have stripped the 68040 emulation from the PowerPC chip and simply bundled the 68060 in addition, but that wouldn't have weeded off a lot of the developers from that chip"
It makes sense for Apple to do the same thing on PowerPC. They need people to switch quickly.
You make an interesting point. I hadn't considered that.
"Bringing out Pentium-based PowerBooks wouldn't be very wise since the ProApps (which is what most PowerBook users use if you believe Apple) have not been compiled over to Intel based builds yet, from all that has been mentioned online so far."
That's another good point, but I remain skeptical.
Consider:
- Apple prefers to keep a performance advantage on premium lines.
- Current Pentium Ms have a performance advantage over G5s at the same clock speed, and they go a lot higher than 1.6 ghz. The Yonah core will widen the gap in performance per mhz and number of mhz, particularly in floating point performance where Pentium Ms are currently weak.
- Therefore it will be difficult for Apple to put Pentium Ms in iBooks before PowerBooks. Apple is unlikely to ship an iBook with decreased clock speed over the current versions, and at 1.4 ghz a Pentium M still does well against a 1.6 ghz G5.
- The new Yonah core will have dual-core versions, and even under emulation a dual-core 2 ghz Pentium M will have acceptable performance compared to a 1.6 ghz G5. It may not be faster, but it's not going to be that much slower.
- Apple never shipped a computer with a 68060 chip, despite the fact that they were much faster than 68040s. PowerPC emulating 68k was faster than a 68040 natively but not faster than a 68060.
It's possible Apple will ship a G5 PowerBook, but it would put them in a pretty awkward position.No. The MPC8641D is not socket-compatible with current G4s. A compatible version could probably be produced, but it would be stuck with the MPX bus that has left G4s castrated for so long. It slows down G4s now and if there were two cores on the same bus it would be even worse. An incompatible version will not be used because the costs associated with a new chipset and new motherboard design would be wasted when they'll be selling the things for less than a year.
I think it's pretty likely that PowerBooks will get dual-core Pentium Ms though.
Not a chance. If anything gets them, it'll be PowerBooks, and I doubt even that much. They won't be selling them for long enough to justify the expense and Pentium Ms are so much faster than 1.6 ghz G5s that it would be pointless.
"So yeah, some of us actually HAVE been exposed to, and DO care, about these sorts of things."
The question is: why should anyone with a compiler care? How often does desktop software need assembly programming?
"If all I have realisticly available to me is crappy-ass broken-by-design, unreliable, wintel trash; I may as well have CHEAP, crappy-ass, broken-by-design, unreliable, wintel trash."
Apple PowerPC hardware was slower in addition to being overpriced. At least now it's just overpriced.
I'd rather get another hour out of my batteries than get a processor that works in network byte order. And I'm a developer.
"The GCC people are changing the API as the enormously complex C++ standard changes beneath them."
ABI != API
The ABI doesn't need to change to track API changes.
"Why, o why do they always make changing the C++ ABI such an effort? It takes some credibility out of C++ as a stable lower-level programming target if such a relatively frequently occuring change in the core obsoletes so much essential packages."
The GCC people are the ones changing the ABI, and they're the ones losing credibility.
Send cargo on the slow boat, then send people in a faster craft when everything they need has arrived.
It's not being shown in Calgary yet. We still haven't had the first season of Atlantis. Without BitTorrent...
"pages load so fast for me on my dual g5 that it's like switching channels on my TV."
Congratulations. Your $3000 computer is fast. Firefox on my iBook (700 mhz G3 384 mb) is many times slower than Firefox on my OpenBSD machine (400 mhz Pentium II 256).
G3s aren't slower than Pentium IIs. MacOS X isn't slower than OpenBSD. Mac software doesn't have to be slow. The Firefox port just happens to be really, really bad.
"From a user perspective, its unacceptible that the new systems can't emulate support for our software. I understand from a developer perspective."
Apparently I'm wrong about altivec emulation being slower than an equivilant scalar code path. Whether or not that's so, I've given up speculating. If you have trouble whenever Apple does something that doesn't make sense, you're in for a lot of trouble.
"Look at it this way, if apple's claims that Intel chips are truely superior in every way are true, then PPC G4 emulation should be trivial."
They never claimed that. The only specific performance claim I've seen from Apple is that they're better at integer performance per watt.
"Sulfuric acid, which I believe is a byproduct of paper manufacturing (could be wrong), is one of the cheapest chemicals you can buy because of this."
A lot of sulfur also comes from sour natural gas wells.
Interestingly, I've been hearing rumors about oil companies looking at building nuclear reactors in Alberta to generate hydrogen for the tar sands. The hydrocarbons are too big to be useful in the state they're in naturally, so additional hydrogen is needed to produce useful oil.
Natural gas production in North America has peaked, so the current source of hydrogen will get expensive soon.
Some of the benchmarks don't rely on the OS. For example, memory latency doesn't change from one OS to the next.
However, OS X was beaten pretty badly by Linux on benchmarks that do depend on the OS so testing it on the same hardware may be a negative. Some difference could be accounted for by the hardware, but not the factor of 2-5 that OS X lost by...
"Keep it in context: this is an anecdotal comment from a single person comparing a bleeding edge 2005 pre-release Mac with their old 2003 retail Mac."
You mean if we have objective tests we can admit the Intel chips are faster?
Sweet.
"If Apple used hand coded assembly they never would have been able to go from PPC to x86. Why do you think they would start now?"
It's common for developers concerned with performance to profile an application and hand-tune a few hotspots. Only a tiny amount of assembly needs to be written.
It's not portable, but OTOH it's not that much code to re-write.
There's no reason in principal that Altivec couldn't be emulated, but I strongly suspect it's not supported because because emulating it would be slower than forcing applications to use alternate code paths that don't require altivec.
Not all applications can do that, so it's a problem, but it's not like Apple to make things complicated by adding extra options.
" PowerPC CPUs are generally 25-30% faster than Intel x86 CPU of the same clockrate."
Even that isn't necessarily true. A Pentium M at 2 ghz outperforms a G5 at 2 ghz by about 90% on integer code.
"Aren't these Mac's using a 32-bit Intel proc? Does Apple really intend to replace a 64-bit machine with a 32-bit one?"
The chip in the dev boxes is 64-bit, but Apple doesn't support it with the OS.
"What does this comparison really say? Will it be faster at even the Altivec/dual proc enhanced apps (like filters filters for photoshop, rendering video, etc...)"
As always, it depends on what you're doing, but Altivec apps can become SSE apps, and it's likely Apple will offer dual-processor Intel machines.