A month later, when the work is finished and the contractor asks for payment - the company whips out a different document, with completely different requirements, that appears completely legitimate and matches the contractor's digital signature. The company claims the work wasn't done correctly, and uses it as an excuse to not pay.
The problem with doing this is there's a huge risk: the very first time someone calls in an expert who can analyse the document and figure out what actually happened that would be totally compelling evidence of intent to defraud. Not only do you lose the civil suit, but you're the defendant in a criminal case as well. And any other contracts you've signed are in doubt as well.
That's the real reason that people are willing to accept such easily forged documents as signed faxes as binding contracts, because you really can't get away with forging them on a alrge enough scale to make it worthwhile.
Oh, I'm sure there's a few situations where this might be usable as part of a scam that's big enough to justify the risk, but I can't think of any where more conventional forms of deception aren't both easier and safer.
Oh god, the people who flamed about contextual menus because "Fitt's Law" said that the top of the screen was the best place to put the "infinitely tall" menus... when Fitt's law said the five best places for targets were... the corners of the screen and near the mouse.
Why use the app dir when you could simply offer two downloads, one for OS X (a Mach-O Universal binary), and a PEF executable if you're still trying to target old OS 9 users?
Well, sure, but that won't "automatically run on OS 9 and OS X any more". Which is what I was getting at.
A Carbon app will work perfectly fine as a Universal Binary without writing a "Cocoa shell".
You're right. I was mixing up Carbon vs. Cocoa with CEF vs. Mach-O. So I owe you an apology after all.
The 3-core 3.2 GHz part you speak of is not a G5. It is a 64-bit PowerPC core, true, but it lacks things like out-of-order execution.
Do you have a URL for that? Because I had originally assumed that both of these chips were crippled versions of the 970 core and that accounted for the high clock speed... but when I suggested that in another discussion I wasn't able to find a reference.
Cite? I see that no where in Apple's Universal Binary Programming Guide, so post a link or quit making shit up.
Next's fat binaries are Mach executables. That is, they're Mach-O files. Mach-O executables don't run under OS 9. So you'll have to have a CEF version of the program that'll run under OS 9 or OS X PPC, and a Mach-O version that'll run under OS X PPC and OS X x86 (or two separate Mach-O versions, or a Mach-O version of x86 and use the CEF version under PPC, whatever Xcode 2 creates for OS X by default). You can wrap them all in a Cocoa bundle (appdir), and create an alias for the CEF version in the root of the bundle so under OS 9 it'll show up as Whatever.app : Whatever pointing to Contents : MacOS : Whatever.
I suppose it's possible that there's some flag that'll perform all those shenanigans under Xcode 2. Or that OS X x86 will happily pull x86 code segments out of a PPC CEF file. But I certainly wouldn't expect either.
If you've got Xcode 2 and can try it, and it does work automatically, well, hell, I'm sorry: I got it completely wrong.
I wrote: "G4 core has always been close to twice as fast clock-for-clock than the Pentium 4"
But do you remember how [the G4] took a year to scale from 450 to 500 MHz?
Don't try and snow me, man, I'm not making a dramatic or surprising announcement here, this is a totally conservative prediction.
It's shipping at 1.67 now. That would already be faster than a 3 GHz P4 except for the damn 166 MHz bus. There is absolutely no risk in predicting better performance from an e600 than from a 3 GHz P4, because Freescale doesn't have to do anything extraordinary to make that happen.
The M is 70% faster per clock than the P4. That still means it's slower per clock than the e600. And the e600 will run existing Mac OS code native, not under emulation.
Remember, we're talking about what use Apple can make of the Pentium M or the MPC8461. Not what the Pentium M can do in a laptop that already exists running software that's already compiled for it and optimised for it, because that's not what Apple has.
Maybe this is their last gasp. Maybe they'll process-shrink it to 2 GHz by this time next year, I don't know, but when someone starts talking about the "G5 Laptop" as if that or the Pentium M are the only options... well, hell man, that's just not the case and you know it.
Mot/Freescale has, since 2000, shown the classic symptoms of a company trying to compete in a capital- and R&D-intensive industry without sufficient resources.
And yet despite that they've managed to keep clocking up the short-pipeline G4 and keeping the core within spitting distance of Intel's MUCH more expensive effort. And what's been holding them back? A frigging socket!
Now they've come up with a damn good solution to that, Apple pulls out. And you're telling me that's their fault?
Intel has been plowing along with a variety of architectures, one of which was bound to not suck.
Intel has precisely two architectures right now. The P4 core, and the old P6 core. Everything they're shipping is a variant of one or the other of these. Whether they call it Celeron or Pentium 4 or Pentium Mobile, it's one or the other of these two designs.
That's one more core than either IBM or Motorola/Freescale, yes, but despite having all the resources and all the time and all the talent of two major former competitors in hand... they're still barely ahead. And they've screwed up badly before... they got the StongArm from DEC and developed a successor that was barely faster at twice the clock rate.
Yes, the odds favor them. But the odds have favored them for years and they haven't managed a clear victory... ever. They've marketed and made deals and bluffed their way out every time. That's how they beat Alpha, that's how they beat MIPS, that's how they beat PA/RISC. They convinced people they were unbeatable, like they've convinced you they were unbeatable, and when they've shown their hands it's been a pair of Itanics.
For better or worse, Intel is the only major supplier of PC CPUs in the world
As of Monday, yes, that's absolutely true.
But that would have been try no matter when Apple pulled the plug. They would have done it in 1997 if they thought they could get away with it: that's when Rhapsody was announced as the Macified version of NeXTSTeP. They would have done it in 2000 or 2001 if they'd been able to swing people over to the original plan for Rhapsody, instead of having to come up with Carbon as a stopgap to keep the ISVs from revolting. None of what you're saying now was any less true back then.
All I'm saying is that there's no other reason to do this NOW, rather than in 2001, or 2003, or 2007, other than Apple's got enough market share and cash to risk it now, and they've got enough developers on the NeXTstep-derived API that they can risk losing a few of the ones still coding to MacOS-derived Carbon for whom conversion is too much of a hurdle.
The enviro that will stop working with Rosetta is Classic.
I'm not talking about Rosetta, or "Classic". I'm talking about the universal binaries. Those are the fat binaries from NeXT. To get a Carbon app to work as a universal binary you'll have to wrap it inside at least a minimal Cocoa shell, so you can't make an app that'll just automatically run on OS 9 and OS X any more.
I am quite confident that nobody* has been developing for Classic since 'round 2001.
For one well-known example: iCab runs on everything from 8.5 to Tiger. The only reason it doesn't run on 8.1 and earlier is that it needs Apple's Unicode support.
You mean this? Rumors and some game developer comments (on the record and off the record) have Xenon's performance on branch-intensive game control, AI, and physics code as ranging from mediocre to downright bad? That's kind of a characteristic of long-pipeline cores in general.
They've only been holding back since, oh, 2000 or so to enhance the dramatic effect.
Um, the G4 core has always been close to twice as fast clock-for-clock than the Pentium 4. The problem with the G4 has been the slow I/O bus... and changing the I/O bus on the Powermac G4 was kind of hard to get Apple to go along with, thanks to their "ZIF" design. You wouldn't put a highly integrated G4 in a 166 MHz socket.
So if they had something like the e600 in 2000... would Apple have used it?
Anyone who was honestly waiting for a Powerbook G5 isn't qualified to comment on processor technology.
The G5 is the high-power PPC, like the Pentium 4.
The Pentium-M equivalent of the PPC line is the Freescale MPC8641. It's running a bit later, but a dual-core G4 with two 667 MHz memory busses is a lot more exciting to me than a Pentium III core with a single 533 MHz FSB, even if the Pentium is running 25% faster.
optical mice, self-illuminating and adjusting keyboards
Um, I'm pretty sure Microsoft were the ones who came out with the first modern optical mice. The puck mice Apple was using in 1999 sure weren't optical.
And those keyboards are nowhere near as good as the ones the IBM Thinkpad was already using... and the LED at the top of the Thinkpad's screen does a MUCH better job of letting you work in the dark.
Perhaps if IBM had shown us a portable G5 or a 3+GHz system... I would be morning their absence.
IBM is showing you a 3-core 3.2 GHz "G5" and a "G5" with 8 integrated DSPs, either of which could have been used in a Powermac if Apple was actually interested in them.
Freescale is showing you a G4 that'll run as fast as a 3 GHz Pentium 4 and cooler than a Pentium M and its bridge chips... because it's an integrated CPU with multiple independent memory and I/O ports.
From microkernel to something less taxing in IPC department.
What microkernel? Mach isn't a microkernel. Fast IPC is one of the features of a microkernel... fast enough IPC to make all the extra context switches affordable. Mach doesn't give you this, or any of the other advantages of a microkernel, which is why Mac OS X is a single-server design that only really uses Mach for the relatively clean kernel module mechanism... like just about every other practical Mach-based operating system, ever.
They'll replace Mach messages with faster mechanisms... they've been doing that for a while.
From 32 bit to 64 bit for UI apps.
That's easy to do, it's just a performance hit - we've been doing 64-bit on the Alpha for 10 years now, and there's damn few apps that really need that kind of address space. I don't anticipate this happening until they've moved more of the UI into the GPU so the bigger structures and pointers aren't relevant. After all, most of the apps that will benefit from 64 bit are server apps, with no GUI.
The point is that the World isn't going to jump aboard this Rhapsody [i.e. Mac OS X] ship any time soon. Elitism, attitude and bragadaccio [sic] about Rhapsody's 10 year heritage aside, there first needs to be a warm, fuzzy community. -- The BOZO Bit
Well, now it's got a warm, fuzzy community.
And, look, Mac OS just went down the drain... there's no new Macs that'll boot OS 9 now, and after 2007 there won't be any new Macs that'll even run OS 9 apps.
It's all NeXTSTeP... I mean Rhapsody... I mean OS X from now on. Mac OS is dead, long live Mac OS X.
Steve's been trying to kill Classic Mac OS for longer than that.
Steve to developers in 1997: Rhapsody will only run OS 8 apps in an emulator, start using "Yellow Box" now. Steve to developers in 1998: If you port to Carbon, you'll be able to run on Rhapsody and OS 8/9. Steve to developers in 1997: If you develop for Carbon, you'll be able to run on OS X and OS 8/9. Steve to developers in 2000: If you develop for Carbon, you can run on OS X, but Cocoa is really the way forward. Steve to developers in 2001: We really have OS X working properly now, switch to Cocoa. Steve to developers in 2002: OS 9 is dead, stop developing for it. Steve in 2003: You should all be developing for OS X now, OS 9 is dead. Steve in 2004: Develop under OS X Xcode, OS 9 is long dead Steve in 2005: It'll be much easier to port Cocoa apps to OS X Intel, and did you notice we don't sell OS 9 bootable Macs any more? Steve in 2006: It's much easier to port Cocoa apps to OS X Intel, you don't need to keep OS 9 compatibility, honest! Steve in 2007: WTF is wrong with you people, stop developing for OS 9 already.
Clever, but it means the attack is not a general way to forge an MD5-signed document... you couldn't use this (for example) to seed a P2P network with malicious files that look like safe ones. It only works if you generate both documents, and it can only be used maliciously if it's never examined by an expert: the signer can't retain a copy of the signed document or obtain a copy through discovery.
Remember that NeXT already had a CPU- and OS- independent API long before Microsoft.
All MS needs to do is push.net hard for MacOS X86, and...... Apple to resurrect and push Openstep/Cocoa on Windows, and all of a sudden the race is on again. And I sure as hell would rather develop for *step than.NET.
If offered both here is what would happen. I would order the computer with OSX and when it arrived, I would then set it to dual boot with my current copy of Win2k.
Why would you order it with OS X, then? I gave up on dual-booting my computer long ago. It's just too bloody disruptive to stop EVERYTHING I'm doing and reboot it to run an application.
In practice, dual-boot machines are either run by hardcore hobbyists, or they hardly ever get booted into one of the operating systems.
So:
Windows Only Machines: 60% OSX + Windows Machines: 40%
An since people who buy Mac buy more software, and hard-core hobbyists buy hardly anything but games, from the software developer's point of view this reduces to sales that look like this:
Windows-only: 60% times a "buying factor" of 0.8 = 48% Dual-boot hobbyists: 10% times a "buying factor" of 0.2 = 2% Dual-boot Windows-only: 10% times a "buying factor" of 1.0 = 10% Mac-only: 20% times a "buying factor" of 2.0 = 40%
Interesting. That's more likely than any of the other "IBM is the problem" theories I've seen. I'll have to think on that one, because IBM hasn't been really misbehaving in public, other than the way they seem to have run into the same clock-speed wall as everyone else.
Slashdot Mirror
We'll fix the Finder in OS X will that make you guys happy then?
That's crazy talk, crazy talk!
A month later, when the work is finished and the contractor asks for payment - the company whips out a different document, with completely different requirements, that appears completely legitimate and matches the contractor's digital signature. The company claims the work wasn't done correctly, and uses it as an excuse to not pay.
The problem with doing this is there's a huge risk: the very first time someone calls in an expert who can analyse the document and figure out what actually happened that would be totally compelling evidence of intent to defraud. Not only do you lose the civil suit, but you're the defendant in a criminal case as well. And any other contracts you've signed are in doubt as well.
That's the real reason that people are willing to accept such easily forged documents as signed faxes as binding contracts, because you really can't get away with forging them on a alrge enough scale to make it worthwhile.
Oh, I'm sure there's a few situations where this might be usable as part of a scam that's big enough to justify the risk, but I can't think of any where more conventional forms of deception aren't both easier and safer.
Oh god, the people who flamed about contextual menus because "Fitt's Law" said that the top of the screen was the best place to put the "infinitely tall" menus... when Fitt's law said the five best places for targets were... the corners of the screen and near the mouse.
Why use the app dir when you could simply offer two downloads, one for OS X (a Mach-O Universal binary), and a PEF executable if you're still trying to target old OS 9 users?
Well, sure, but that won't "automatically run on OS 9 and OS X any more". Which is what I was getting at.
A Carbon app will work perfectly fine as a Universal Binary without writing a "Cocoa shell".
You're right. I was mixing up Carbon vs. Cocoa with CEF vs. Mach-O. So I owe you an apology after all.
Sorry about messing up that detail in the punchline of a joke.
The 3-core 3.2 GHz part you speak of is not a G5. It is a 64-bit PowerPC core, true, but it lacks things like out-of-order execution.
Do you have a URL for that? Because I had originally assumed that both of these chips were crippled versions of the 970 core and that accounted for the high clock speed... but when I suggested that in another discussion I wasn't able to find a reference.
You mean the LED that casts NO LIGHT at all?
No, that must be some other LED. The one on my Thinkpad is perfect for working in the dark without disturbing people sleeping in the same bed.
Cite? I see that no where in Apple's Universal Binary Programming Guide, so post a link or quit making shit up.
Next's fat binaries are Mach executables. That is, they're Mach-O files. Mach-O executables don't run under OS 9. So you'll have to have a CEF version of the program that'll run under OS 9 or OS X PPC, and a Mach-O version that'll run under OS X PPC and OS X x86 (or two separate Mach-O versions, or a Mach-O version of x86 and use the CEF version under PPC, whatever Xcode 2 creates for OS X by default). You can wrap them all in a Cocoa bundle (appdir), and create an alias for the CEF version in the root of the bundle so under OS 9 it'll show up as Whatever.app : Whatever pointing to Contents : MacOS : Whatever.
I suppose it's possible that there's some flag that'll perform all those shenanigans under Xcode 2. Or that OS X x86 will happily pull x86 code segments out of a PPC CEF file. But I certainly wouldn't expect either.
If you've got Xcode 2 and can try it, and it does work automatically, well, hell, I'm sorry: I got it completely wrong.
I wrote: "G4 core has always been close to twice as fast clock-for-clock than the Pentium 4"
But do you remember how [the G4] took a year to scale from 450 to 500 MHz?
Don't try and snow me, man, I'm not making a dramatic or surprising announcement here, this is a totally conservative prediction.
It's shipping at 1.67 now. That would already be faster than a 3 GHz P4 except for the damn 166 MHz bus. There is absolutely no risk in predicting better performance from an e600 than from a 3 GHz P4, because Freescale doesn't have to do anything extraordinary to make that happen.
The M is 70% faster per clock than the P4. That still means it's slower per clock than the e600. And the e600 will run existing Mac OS code native, not under emulation.
Remember, we're talking about what use Apple can make of the Pentium M or the MPC8461. Not what the Pentium M can do in a laptop that already exists running software that's already compiled for it and optimised for it, because that's not what Apple has.
Maybe this is their last gasp. Maybe they'll process-shrink it to 2 GHz by this time next year, I don't know, but when someone starts talking about the "G5 Laptop" as if that or the Pentium M are the only options... well, hell man, that's just not the case and you know it.
Mot/Freescale has, since 2000, shown the classic symptoms of a company trying to compete in a capital- and R&D-intensive industry without sufficient resources.
And yet despite that they've managed to keep clocking up the short-pipeline G4 and keeping the core within spitting distance of Intel's MUCH more expensive effort. And what's been holding them back? A frigging socket!
Now they've come up with a damn good solution to that, Apple pulls out. And you're telling me that's their fault?
Intel has been plowing along with a variety of architectures, one of which was bound to not suck.
Intel has precisely two architectures right now. The P4 core, and the old P6 core. Everything they're shipping is a variant of one or the other of these. Whether they call it Celeron or Pentium 4 or Pentium Mobile, it's one or the other of these two designs.
That's one more core than either IBM or Motorola/Freescale, yes, but despite having all the resources and all the time and all the talent of two major former competitors in hand... they're still barely ahead. And they've screwed up badly before... they got the StongArm from DEC and developed a successor that was barely faster at twice the clock rate.
Yes, the odds favor them. But the odds have favored them for years and they haven't managed a clear victory... ever. They've marketed and made deals and bluffed their way out every time. That's how they beat Alpha, that's how they beat MIPS, that's how they beat PA/RISC. They convinced people they were unbeatable, like they've convinced you they were unbeatable, and when they've shown their hands it's been a pair of Itanics.
For better or worse, Intel is the only major supplier of PC CPUs in the world
As of Monday, yes, that's absolutely true.
But that would have been try no matter when Apple pulled the plug. They would have done it in 1997 if they thought they could get away with it: that's when Rhapsody was announced as the Macified version of NeXTSTeP. They would have done it in 2000 or 2001 if they'd been able to swing people over to the original plan for Rhapsody, instead of having to come up with Carbon as a stopgap to keep the ISVs from revolting. None of what you're saying now was any less true back then.
All I'm saying is that there's no other reason to do this NOW, rather than in 2001, or 2003, or 2007, other than Apple's got enough market share and cash to risk it now, and they've got enough developers on the NeXTstep-derived API that they can risk losing a few of the ones still coding to MacOS-derived Carbon for whom conversion is too much of a hurdle.
The enviro that will stop working with Rosetta is Classic.
I'm not talking about Rosetta, or "Classic". I'm talking about the universal binaries. Those are the fat binaries from NeXT. To get a Carbon app to work as a universal binary you'll have to wrap it inside at least a minimal Cocoa shell, so you can't make an app that'll just automatically run on OS 9 and OS X any more.
I am quite confident that nobody* has been developing for Classic since 'round 2001.
For one well-known example: iCab runs on everything from 8.5 to Tiger. The only reason it doesn't run on 8.1 and earlier is that it needs Apple's Unicode support.
You mean this? Rumors and some game developer comments (on the record and off the record) have Xenon's performance on branch-intensive game control, AI, and physics code as ranging from mediocre to downright bad? That's kind of a characteristic of long-pipeline cores in general.
They've only been holding back since, oh, 2000 or so to enhance the dramatic effect.
Um, the G4 core has always been close to twice as fast clock-for-clock than the Pentium 4. The problem with the G4 has been the slow I/O bus... and changing the I/O bus on the Powermac G4 was kind of hard to get Apple to go along with, thanks to their "ZIF" design. You wouldn't put a highly integrated G4 in a 166 MHz socket.
So if they had something like the e600 in 2000... would Apple have used it?
But does Apple really want to be making PPC and Intel versions of their product for a long time?
Probably not. But they do have that option.
I have to expect Freescale and IBM just said "we're more interested in these other, more profitable chip areas, Steve, sorry"
IBM has announced a dual-core G5, and Freescale this nice new laptop-friendly chip. These don't seem like the old cold shoulder to me.
I think NOT offering an Intel platform i[s] the first mistake.
Rhapsody on Intel. He *did* try. The reality distortion field wasn't quite strong enough to pull it off back in 1997.
Hey, guess what? They are not the same people saying this.
Some of them are. Really. It's weird.
how long have we been waiting for a PowerBook G5?
Anyone who was honestly waiting for a Powerbook G5 isn't qualified to comment on processor technology.
The G5 is the high-power PPC, like the Pentium 4.
The Pentium-M equivalent of the PPC line is the Freescale MPC8641. It's running a bit later, but a dual-core G4 with two 667 MHz memory busses is a lot more exciting to me than a Pentium III core with a single 533 MHz FSB, even if the Pentium is running 25% faster.
optical mice, self-illuminating and adjusting keyboards
Um, I'm pretty sure Microsoft were the ones who came out with the first modern optical mice. The puck mice Apple was using in 1999 sure weren't optical.
And those keyboards are nowhere near as good as the ones the IBM Thinkpad was already using... and the LED at the top of the Thinkpad's screen does a MUCH better job of letting you work in the dark.
Perhaps if IBM had shown us a portable G5 or a 3+GHz system... I would be morning their absence.
IBM is showing you a 3-core 3.2 GHz "G5" and a "G5" with 8 integrated DSPs, either of which could have been used in a Powermac if Apple was actually interested in them.
Freescale is showing you a G4 that'll run as fast as a 3 GHz Pentium 4 and cooler than a Pentium M and its bridge chips... because it's an integrated CPU with multiple independent memory and I/O ports.
Mourn that.
Funny, that's what Compaq did to the Alpha.
From microkernel to something less taxing in IPC department.
What microkernel? Mach isn't a microkernel. Fast IPC is one of the features of a microkernel... fast enough IPC to make all the extra context switches affordable. Mach doesn't give you this, or any of the other advantages of a microkernel, which is why Mac OS X is a single-server design that only really uses Mach for the relatively clean kernel module mechanism... like just about every other practical Mach-based operating system, ever.
They'll replace Mach messages with faster mechanisms... they've been doing that for a while.
From 32 bit to 64 bit for UI apps.
That's easy to do, it's just a performance hit - we've been doing 64-bit on the Alpha for 10 years now, and there's damn few apps that really need that kind of address space. I don't anticipate this happening until they've moved more of the UI into the GPU so the bigger structures and pointers aren't relevant. After all, most of the apps that will benefit from 64 bit are server apps, with no GUI.
The point is that the World isn't going to jump aboard this Rhapsody [i.e. Mac OS X] ship any time soon. Elitism, attitude and bragadaccio [sic] about Rhapsody's 10 year heritage aside, there first needs to be a warm, fuzzy community. -- The BOZO Bit
Well, now it's got a warm, fuzzy community.
And, look, Mac OS just went down the drain... there's no new Macs that'll boot OS 9 now, and after 2007 there won't be any new Macs that'll even run OS 9 apps.
It's all NeXTSTeP... I mean Rhapsody... I mean OS X from now on. Mac OS is dead, long live Mac OS X.
Steve's been trying to kill Classic Mac OS for longer than that.
Steve to developers in 1997: Rhapsody will only run OS 8 apps in an emulator, start using "Yellow Box" now.
Steve to developers in 1998: If you port to Carbon, you'll be able to run on Rhapsody and OS 8/9.
Steve to developers in 1997: If you develop for Carbon, you'll be able to run on OS X and OS 8/9.
Steve to developers in 2000: If you develop for Carbon, you can run on OS X, but Cocoa is really the way forward.
Steve to developers in 2001: We really have OS X working properly now, switch to Cocoa.
Steve to developers in 2002: OS 9 is dead, stop developing for it.
Steve in 2003: You should all be developing for OS X now, OS 9 is dead.
Steve in 2004: Develop under OS X Xcode, OS 9 is long dead
Steve in 2005: It'll be much easier to port Cocoa apps to OS X Intel, and did you notice we don't sell OS 9 bootable Macs any more?
Steve in 2006: It's much easier to port Cocoa apps to OS X Intel, you don't need to keep OS 9 compatibility, honest!
Steve in 2007: WTF is wrong with you people, stop developing for OS 9 already.
Clever, but it means the attack is not a general way to forge an MD5-signed document... you couldn't use this (for example) to seed a P2P network with malicious files that look like safe ones. It only works if you generate both documents, and it can only be used maliciously if it's never examined by an expert: the signer can't retain a copy of the signed document or obtain a copy through discovery.
Remember that NeXT already had a CPU- and OS- independent API long before Microsoft.
.net hard for MacOS X86, and... ... Apple to resurrect and push Openstep/Cocoa on Windows, and all of a sudden the race is on again. And I sure as hell would rather develop for *step than .NET.
All MS needs to do is push
If offered both here is what would happen. I would order the computer with OSX and when it arrived, I would then set it to dual boot with my current copy of Win2k.
Why would you order it with OS X, then? I gave up on dual-booting my computer long ago. It's just too bloody disruptive to stop EVERYTHING I'm doing and reboot it to run an application.
In practice, dual-boot machines are either run by hardcore hobbyists, or they hardly ever get booted into one of the operating systems.
So:
Windows Only Machines: 60%
OSX + Windows Machines: 40%
I think this is more likely:
Windows-only machines: 60%
Dual-boot hobbyist machines: 10%
Dual-boot Windows-only: 10%
Dual-boot Mac-only: 10%
Mac-only machines: 10%
An since people who buy Mac buy more software, and hard-core hobbyists buy hardly anything but games, from the software developer's point of view this reduces to sales that look like this:
Windows-only: 60% times a "buying factor" of 0.8 = 48%
Dual-boot hobbyists: 10% times a "buying factor" of 0.2 = 2%
Dual-boot Windows-only: 10% times a "buying factor" of 1.0 = 10%
Mac-only: 20% times a "buying factor" of 2.0 = 40%
Interesting. That's more likely than any of the other "IBM is the problem" theories I've seen. I'll have to think on that one, because IBM hasn't been really misbehaving in public, other than the way they seem to have run into the same clock-speed wall as everyone else.
I simply have to conclude that technology has nothing at all to do with this decision
Agreed.
I think this is part of a bigger game, just not the one Cringely's talking about.