The message has been a bit unclear, and I think some people are misinterpreting what they've been told. What I remember from WWDC is:
1. The Kernel API's (KPI, whatever) are now fixed, and you shouldn't need to revise your drivers for future releases of the OS. This was explicitly NOT guaranteed in previous versions of Mac OS X.
2. At one or the other of the Cocoa sessions, there was a kind of vague statement that could have been interpreted as "the core Cocoa classes are not going to change in incompatible ways, going forward". The thrust of that was, once again, that you should not need to revise your application code to remain compatible with future Mac OS versions. In a practical sense, I guess this would mean APIs aren't being deprecated anymore.
Obviously, Apple is still going to be implementing new functionality (exposed via new APIs), and they'll fix bugs, which may break some apps. But there was a definite commitment to improved backward compatibility.
If you figure that the Flash will survive up to 100,000 write cycles, then if you rewrite it ten times a day, it'll last 27 years. I doubt your boot configuration will change that often. And 100,000 cycles is a lot lower than the "rated" lifetime of modern Flash, not to mention that the "actual" lifetime can be a lot longer with appropriate load-leveling and error recovery.
It's fairly trivial to add what we call a "Run Script build phase", which allows you to call any command-line tools as a part of your build. You'd simply make the PPC and x86 binaries separate targets in Xcode, and have a third "Universal" target that just combines the two.
It could certainly be made easier to do this from the standard GUI, but it's not too hard right now.
Assuming your code will compile both with GCC and with ICC, it's very easy to build a PPC binary and an x86 binary separately, and combine them into a Universal binary at the end.
Some developers I know of are planning to use this same strategy to keep their CodeWarrior projects for PPC, and use Xcode for their x86 builds.
Yeah, that really jumped out at me, too. As far as I can tell, it's there to make the design more symmetrical, which helps explain how practical this chart is - i.e. not at all.
On the other hand, it might still have value as a tool to show students that the periodic table is just one way to categorize elements, and thereby encourage them to visualize things in whatever way makes sense to them.
The obvious way to simplify D&D is to just start tossing out rules and special cases (especially in combat and character generation).
Once you've done that, you'll basically have reinvented the old Basic D&D rules. Well actually, you would if you started with AD&D. If you started with the 3.5 rules, I'm not sure where you'd end up, since the structure is very different.
Actually, I've considered starting a new D&D campaign based on the old Basic/Expert rules, as I find that the reduction in micromanagement and prep time is something of an advantage for throwing a quick game together. On the other hand, some of my friends are the kind of min-maxing, rules-lawyering munchkins that AD&D and it's descendants were invented for, so they might not go for it...
My take on this would be to run through a couple of basic scenarios (character generation, combat, etc) with a few experienced friends, following your current favorite rule set. Every time you have to look something up in a table, roll a die, or make a calculation, ask yourself whether it's adding to the fun, or just adding complication. If it's not part of the fun, strip it out. Don't worry too much about game balance, a younger player won't be too invested in that, anyway.
No. As has been pointed out repeatedly, these systems are NOT representative of what Apple will be shipping in a year. These systems exist only to help developers transition their existing applications over to the Intel architecture.
When new Intel-based Macintoshes ship next year, they'll presumably be based on whatever processors & GPUs meet Apple's needs for the product they're in. You probably wouldn't want to use the processor from the current development system in a laptop or a Mac mini, for example.
If you want to play the guessing game, take a look at the announced roadmap for Intel's processors, starting at a point about one year from now.
The document-centric model doesn't necessarily HAVE to break down the traditional application model, but it has the potential to do so, in a number of ways. The real issue for companies like Microsoft is that they've already got a large suite of extremely feature-rich applications, so the massive effort to port over to a component-based architecture would leave them with nothing they don't already have.
Meanwhile, basing Office on a set of pluggable components leaves them open to competition with an unknown number of "parts vendors" whenever they decide to offer an upgrade to their product. Microsoft's whole Office business model is based on drowning the user in features, and selling the collected applications for (much) less as a suite then they cost individually. Even if there's only one feature in Word N+1 that you want, you'd be a fool not to upgrade the full Office suite, thereby subsidizing the work on Outlook N+1 (which you'll never even use). The component model breaks this - if you want a single-feature update to your existing software, someone else might be able to sell you a replacement component, instead of Microsoft...
On Windows, Microsoft supports their own home-grown embedded object technology, but only in the simplest sense - you can embed a Word document in an Excel spreadsheet, or vice versa, but you can't make use of subsets of either application's technology in any other applications, they're very "chunky". You CAN get components from third parties that plug into Word, but they're limited to providing fairly esoteric functionality.
There are a number of similar arguments having to do with file formats and keeping users on the upgrade treadmill, among other things. Bottom line - component-based software threatens the control that big application vendors like to exercise over their user base, without offering them anything valuable in return.
I wouldn't think that would be the case - otherwise, why make the distinction at all?. The dictionary definition of ballistic looks something like this:
1 of or relating to projectiles or their flight.
2 moving under the force of gravity only.
I think sense 2 is what's meant here. A missile that, at the end of it's flight, is coasting, affected only by gravity (and drag) is a ballistic missile. Any missile that either steers itself actively, or is still accelerating when it hits its target, is not a ballistic missile.
So the distinction is then between "guided" missiles, and "ballistic" missiles, both of which are terms I've heard used before.
And the source to TextEdit is provided with Xcode, so you could just go in and add margin control, if you wanted to. I'm actually kind of surprised that there isn't an open-source "TextEdit Plus" project that just fixes the one or two egregious lacks in TextEdit.
The limitation on Services being, essentially, one-way is where this really falls down in comparison to a genuine embedded document model. You can do the same thing with the Equation Editor in Microsoft Office, but the equation remains editable, which is much cooler.
The low-effort way to make this work is for Apple to define some kind of container format which can carry a (probably PDF) visual representation of the content, and a link back to the original document.
Then these "container objects" can be displayed in any rich text control, just like an image, but when you double-click, it opens the original editing application....and I've just re-invented OpenDoc.
It's not technically hard to do, it's just (perceived to be) of dubious value. Remember, we've been down this road before - OpenDoc was a really ambitious attempt to break down the traditional application-oriented model, and it failed pretty thoroughly.
Now, there were a variety of reasons for that failure, some technical, some not. At least part of the reason OpenDoc didn't succeed is that it was too disruptive to the traditional business model of applications vendors.
On Windows, OLE was successful because the #1 piece of productivity software supported it heavily (Microsoft Office), and because the development tool of choice for corporate developers (Visual Basic) used it as the method of adding new widgets.
Right now, Mac OS X supports a variety of different ways for applications to support content in formats they don't natively understand - Plugins, Services, filtering content through Quicktime, etc. For many (most?) applications, display-only embedding through AppKit or Quicktime is sufficient.
I'd like to see a more unified plugin model, personally. I'm not sure what, exactly, I'd want that to look like, but something like how OLE works wouldn't be a bad thing, in my opinion.
That's true, but Distributed Objects is not COM/OLE. It's a (relatively) low-level technology that you could implement something like COM components on top of. In fact, any number of folks have done just that at various times in the past (including me).
The issue is just that unless/until an officially-sanctioned method is provided for embedding one application's documents inside another's, you won't see the universal adoption of such a scheme, like you see on Windows.
"So do some of the GUI features in OS X work like OpenDoc or OLE?"
No, there's nothing really like that on OS X at the system level. The text editing functionality in many applications is based on classes provided by the Cocoa framework, so you get "the same" text editing experience, by way of all the shared code.
But you don't have the situation of one application being responsible for drawing/editing content inside another application. Each approach obviously has advantages and disadvantages. It certainly would be possible to build a framework for doing that, but it's not something that Apple has put any effort into lately.
1. Light guns aren't very accurate 2. They don't work at all with LCD screens 3. They need accurate synchronization with the vertical blank signal, and a low-latency interrupt, which are hard to arrange with modern graphics cards and operating systems.
I know I'm responding to a troll, but in case anyone else is interested...
point by point:
"Overly dependent on software controls" That's one opinion, obviously. On the other hand, software issues are (in general) easier to fix than other design problems, and electrically-actuated controls should be more reliable over time (we'll see when there's more long-term data available).
"Front heavy steering due to battery weight" I don't know what "front heavy steering" is supposed to mean, but in any case, the batteries are located to the rear of the car, not in the front. It does handle like an economy car, not a sports car (go figure).
"Shaving off steel for less weighty aluminum and magnesium in some areas" Every modern car does this where practical. I don't find that the Prius is particularly extreme in terms of weight reduction (as opposed to the Honda Insight, for example). Why would this be a bad thing?
"Still over 200 pounds heavier than comparable cars" I guess that depends on what you define as "comparable". Prius weighs 140 lbs more than a Civic Hybrid, but then again, it's considerably more roomy inside (5+ extra cubic feet, 2.5 inches more legroom in back, etc), and has more standard equipment.
"VERY expensive maintenance when specialty parts (there are a ton of them) break" Your opinion is not borne out by any reliability data I've seen on the Web, and in any case, nearly all Priuses out there are stiill covered by the factory warranty, so repairs shouldn't be an issue. As for maintenance, it's just oil and brake pads for the first 50,000 miles or so, anyway.
"Replacement of main batteries after 18 months" That's just plain wrong. Toyota warrantees the batteries for EIGHT YEARS (ten in California)! Nobody would sell a hybrid vehicle that required battery replacement in less than 5 years.
"Prius is a horribly expensive car to own." Not so far as anyone's seen yet.
"It accelerates like a dog, too." Toyota claims 0-60 mph takes 10.37 secs. Not exactly blistering, but it's at least a second faster to 60 than the Civic Hybrid (maybe two, depending on whose numbers you use). I've never had any trouble merging onto the freeway or passing slower vehicles.
"Low emission diesel like in Europe is a better solution, or heck bio-diesel." Even the best diesel engines have much higher emissions than a gas/electric hybrid. If hybrid diesel-electric cars were available, that'd be an interesting comparison, but they aren't yet, and may never be in some parts of the US, due to concerns with Sulfur Oxides emissions of high-efficiency diesels.
"Diesels get great fuel economy and provide lots of low end torque where you need it." I doubt you'll find anyone complaining about insufficient torque with an electric motor onboard. Have you ever even driven a Prius?
From the download page: "Apple is providing links to these applications as a courtesy, and makes no representations regarding the applications or any information related thereto. Any questions, complaints or claims regarding the applications must be directed to the appropriate software vendor."
I'm guessing that you don't have much experience with reading MSDSs. As these sorts of sheets go, this one is very reassuring. The constant references to "industrial hygiene" are in there because they're marketing this stuff as a component to go into finished products. In normal circumstances, consumers will never come into direct contact with it.
Most of the "safety" instructions are things like "wash your hands after handling", "don't pour this into your eye", etc. I suspect that isotonic Saline solution is probably the only thing you'll find that has a less scary MSDS. And maybe not even that - if you drink enough Saline, you'll vomit, which wouldn't happen with Galinstan.
The instruction to "carry out symptomatic therapy" is standard boilerplate for these kinds of documents. Normally, no treatment would be expected to be necessary, but if someone shows an allergic reaction (for example), a doctor should know to treat that as just what it seems to be.
And as far as digesting the stuff goes, neither Indium or Gallium is appreciably attacked by weak HCl, so no worries on that score. You might absorb some Tin through your stomach, but the amount you could possibly absorb would be really small, and Tin isn't very toxic, either (they do line food cans with it, you know).
Slashdot Mirror
"Once you go Mac, you never go back!"
The message has been a bit unclear, and I think some people are misinterpreting what they've been told. What I remember from WWDC is:
1. The Kernel API's (KPI, whatever) are now fixed, and you shouldn't need to revise your drivers for future releases of the OS. This was explicitly NOT guaranteed in previous versions of Mac OS X.
2. At one or the other of the Cocoa sessions, there was a kind of vague statement that could have been interpreted as "the core Cocoa classes are not going to change in incompatible ways, going forward". The thrust of that was, once again, that you should not need to revise your application code to remain compatible with future Mac OS versions. In a practical sense, I guess this would mean APIs aren't being deprecated anymore.
Obviously, Apple is still going to be implementing new functionality (exposed via new APIs), and they'll fix bugs, which may break some apps. But there was a definite commitment to improved backward compatibility.
-Mark
If you figure that the Flash will survive up to 100,000 write cycles, then if you rewrite it ten times a day, it'll last 27 years. I doubt your boot configuration will change that often. And 100,000 cycles is a lot lower than the "rated" lifetime of modern Flash, not to mention that the "actual" lifetime can be a lot longer with appropriate load-leveling and error recovery.
It's fairly trivial to add what we call a "Run Script build phase", which allows you to call any command-line tools as a part of your build. You'd simply make the PPC and x86 binaries separate targets in Xcode, and have a third "Universal" target that just combines the two.
It could certainly be made easier to do this from the standard GUI, but it's not too hard right now.
-Mark
Assuming your code will compile both with GCC and with ICC, it's very easy to build a PPC binary and an x86 binary separately, and combine them into a Universal binary at the end.
Some developers I know of are planning to use this same strategy to keep their CodeWarrior projects for PPC, and use Xcode for their x86 builds.
-Mark
Yeah, that really jumped out at me, too. As far as I can tell, it's there to make the design more symmetrical, which helps explain how practical this chart is - i.e. not at all.
On the other hand, it might still have value as a tool to show students that the periodic table is just one way to categorize elements, and thereby encourage them to visualize things in whatever way makes sense to them.
-Mark
The obvious way to simplify D&D is to just start tossing out rules and special cases (especially in combat and character generation).
Once you've done that, you'll basically have reinvented the old Basic D&D rules. Well actually, you would if you started with AD&D. If you started with the 3.5 rules, I'm not sure where you'd end up, since the structure is very different.
Actually, I've considered starting a new D&D campaign based on the old Basic/Expert rules, as I find that the reduction in micromanagement and prep time is something of an advantage for throwing a quick game together. On the other hand, some of my friends are the kind of min-maxing, rules-lawyering munchkins that AD&D and it's descendants were invented for, so they might not go for it...
My take on this would be to run through a couple of basic scenarios (character generation, combat, etc) with a few experienced friends, following your current favorite rule set. Every time you have to look something up in a table, roll a die, or make a calculation, ask yourself whether it's adding to the fun, or just adding complication. If it's not part of the fun, strip it out. Don't worry too much about game balance, a younger player won't be too invested in that, anyway.
-Mark
Apparently, the preview function isn't sufficient to save me from my typos.
-Mark
Good grief. I can see why the publisher bailed on this. I wonder how much they would have had to charge for it?
-Mark
No. As has been pointed out repeatedly, these systems are NOT representative of what Apple will be shipping in a year. These systems exist only to help developers transition their existing applications over to the Intel architecture.
When new Intel-based Macintoshes ship next year, they'll presumably be based on whatever processors & GPUs meet Apple's needs for the product they're in. You probably wouldn't want to use the processor from the current development system in a laptop or a Mac mini, for example.
If you want to play the guessing game, take a look at the announced roadmap for Intel's processors, starting at a point about one year from now.
-Mark
The document-centric model doesn't necessarily HAVE to break down the traditional application model, but it has the potential to do so, in a number of ways. The real issue for companies like Microsoft is that they've already got a large suite of extremely feature-rich applications, so the massive effort to port over to a component-based architecture would leave them with nothing they don't already have.
Meanwhile, basing Office on a set of pluggable components leaves them open to competition with an unknown number of "parts vendors" whenever they decide to offer an upgrade to their product. Microsoft's whole Office business model is based on drowning the user in features, and selling the collected applications for (much) less as a suite then they cost individually. Even if there's only one feature in Word N+1 that you want, you'd be a fool not to upgrade the full Office suite, thereby subsidizing the work on Outlook N+1 (which you'll never even use). The component model breaks this - if you want a single-feature update to your existing software, someone else might be able to sell you a replacement component, instead of Microsoft...
On Windows, Microsoft supports their own home-grown embedded object technology, but only in the simplest sense - you can embed a Word document in an Excel spreadsheet, or vice versa, but you can't make use of subsets of either application's technology in any other applications, they're very "chunky". You CAN get components from third parties that plug into Word, but they're limited to providing fairly esoteric functionality.
There are a number of similar arguments having to do with file formats and keeping users on the upgrade treadmill, among other things. Bottom line - component-based software threatens the control that big application vendors like to exercise over their user base, without offering them anything valuable in return.
-Mark
"All missiles are ballistic missiles."
I wouldn't think that would be the case - otherwise, why make the distinction at all?. The dictionary definition of ballistic looks something like this:
1 of or relating to projectiles or their flight.
2 moving under the force of gravity only.
I think sense 2 is what's meant here. A missile that, at the end of it's flight, is coasting, affected only by gravity (and drag) is a ballistic missile. Any missile that either steers itself actively, or is still accelerating when it hits its target, is not a ballistic missile.
So the distinction is then between "guided" missiles, and "ballistic" missiles, both of which are terms I've heard used before.
-Mark
And the source to TextEdit is provided with Xcode, so you could just go in and add margin control, if you wanted to. I'm actually kind of surprised that there isn't an open-source "TextEdit Plus" project that just fixes the one or two egregious lacks in TextEdit.
:-)
Maybe I should start one
-Mark
The limitation on Services being, essentially, one-way is where this really falls down in comparison to a genuine embedded document model. You can do the same thing with the Equation Editor in Microsoft Office, but the equation remains editable, which is much cooler.
...and I've just re-invented OpenDoc.
The low-effort way to make this work is for Apple to define some kind of container format which can carry a (probably PDF) visual representation of the content, and a link back to the original document.
Then these "container objects" can be displayed in any rich text control, just like an image, but when you double-click, it opens the original editing application.
-Mark
It's not technically hard to do, it's just (perceived to be) of dubious value. Remember, we've been down this road before - OpenDoc was a really ambitious attempt to break down the traditional application-oriented model, and it failed pretty thoroughly.
Now, there were a variety of reasons for that failure, some technical, some not. At least part of the reason OpenDoc didn't succeed is that it was too disruptive to the traditional business model of applications vendors.
On Windows, OLE was successful because the #1 piece of productivity software supported it heavily (Microsoft Office), and because the development tool of choice for corporate developers (Visual Basic) used it as the method of adding new widgets.
Right now, Mac OS X supports a variety of different ways for applications to support content in formats they don't natively understand - Plugins, Services, filtering content through Quicktime, etc. For many (most?) applications, display-only embedding through AppKit or Quicktime is sufficient.
I'd like to see a more unified plugin model, personally. I'm not sure what, exactly, I'd want that to look like, but something like how OLE works wouldn't be a bad thing, in my opinion.
-Mark
That's true, but Distributed Objects is not COM/OLE. It's a (relatively) low-level technology that you could implement something like COM components on top of. In fact, any number of folks have done just that at various times in the past (including me).
The issue is just that unless/until an officially-sanctioned method is provided for embedding one application's documents inside another's, you won't see the universal adoption of such a scheme, like you see on Windows.
-Mark
"So do some of the GUI features in OS X work like OpenDoc or OLE?"
No, there's nothing really like that on OS X at the system level. The text editing functionality in many applications is based on classes provided by the Cocoa framework, so you get "the same" text editing experience, by way of all the shared code.
But you don't have the situation of one application being responsible for drawing/editing content inside another application. Each approach obviously has advantages and disadvantages. It certainly would be possible to build a framework for doing that, but it's not something that Apple has put any effort into lately.
-Mark
It's definitely one of the nicest vector drawing programs I've used on my Mac, works great with the Wacom pressure-sensitive tablet.
Unfortunately, it looks like this version only runs on Windows. Not too surprising, but disappointing, none-the-less.
-Mark
"what about users that don't connect their Xbox360 to the internet? They still have to be able to play their old games. "
Why would you think that? No, seriously - as broadband-focused as Xbox360 is, why would you expect it to work at all without a network connection?
And even if it does "work" without a network connection, it'd be entirely reasonable for it to have more limited functionality in that state.
"The game disc you have inserted isn't compatible with Xbox360, unless you have a subscription to Xbox Live"
-Mark
1. Light guns aren't very accurate
2. They don't work at all with LCD screens
3. They need accurate synchronization with the vertical blank signal, and a low-latency interrupt, which are hard to arrange with modern graphics cards and operating systems.
-Mark
Considering that there's no way to buy a new Mac mini without getting a copy of OSX (and therefore Disk Utility), I'd say "free" is pretty accurate.
I know I'm responding to a troll, but in case anyone else is interested...
point by point:
"Overly dependent on software controls"
That's one opinion, obviously. On the other hand, software issues are (in general) easier to fix than other design problems, and electrically-actuated controls should be more reliable over time (we'll see when there's more long-term data available).
"Front heavy steering due to battery weight"
I don't know what "front heavy steering" is supposed to mean, but in any case, the batteries are located to the rear of the car, not in the front. It does handle like an economy car, not a sports car (go figure).
"Shaving off steel for less weighty aluminum and magnesium in some areas"
Every modern car does this where practical. I don't find that the Prius is particularly extreme in terms of weight reduction (as opposed to the Honda Insight, for example). Why would this be a bad thing?
"Still over 200 pounds heavier than comparable cars"
I guess that depends on what you define as "comparable". Prius weighs 140 lbs more than a Civic Hybrid, but then again, it's considerably more roomy inside (5+ extra cubic feet, 2.5 inches more legroom in back, etc), and has more standard equipment.
"VERY expensive maintenance when specialty parts (there are a ton of them) break"
Your opinion is not borne out by any reliability data I've seen on the Web, and in any case, nearly all Priuses out there are stiill covered by the factory warranty, so repairs shouldn't be an issue. As for maintenance, it's just oil and brake pads for the first 50,000 miles or so, anyway.
"Replacement of main batteries after 18 months"
That's just plain wrong. Toyota warrantees the batteries for EIGHT YEARS (ten in California)! Nobody would sell a hybrid vehicle that required battery replacement in less than 5 years.
"Prius is a horribly expensive car to own."
Not so far as anyone's seen yet.
"It accelerates like a dog, too."
Toyota claims 0-60 mph takes 10.37 secs. Not exactly blistering, but it's at least a second faster to 60 than the Civic Hybrid (maybe two, depending on whose numbers you use). I've never had any trouble merging onto the freeway or passing slower vehicles.
"Low emission diesel like in Europe is a better solution, or heck bio-diesel."
Even the best diesel engines have much higher emissions than a gas/electric hybrid. If hybrid diesel-electric cars were available, that'd be an interesting comparison, but they aren't yet, and may never be in some parts of the US, due to concerns with Sulfur Oxides emissions of high-efficiency diesels.
"Diesels get great fuel economy and provide lots of low end torque where you need it."
I doubt you'll find anyone complaining about insufficient torque with an electric motor onboard. Have you ever even driven a Prius?
-Mark
From the download page:
"Apple is providing links to these applications as a courtesy, and makes no representations regarding the applications or any information related thereto. Any questions, complaints or claims regarding the applications must be directed to the appropriate software vendor."
-Mark
"Area 51 isn't filtered"
Of course, that's just what they WANT you to think...
I'm guessing that you don't have much experience with reading MSDSs. As these sorts of sheets go, this one is very reassuring. The constant references to "industrial hygiene" are in there because they're marketing this stuff as a component to go into finished products. In normal circumstances, consumers will never come into direct contact with it.
Most of the "safety" instructions are things like "wash your hands after handling", "don't pour this into your eye", etc. I suspect that isotonic Saline solution is probably the only thing you'll find that has a less scary MSDS. And maybe not even that - if you drink enough Saline, you'll vomit, which wouldn't happen with Galinstan.
The instruction to "carry out symptomatic therapy" is standard boilerplate for these kinds of documents. Normally, no treatment would be expected to be necessary, but if someone shows an allergic reaction (for example), a doctor should know to treat that as just what it seems to be.
And as far as digesting the stuff goes, neither Indium or Gallium is appreciably attacked by weak HCl, so no worries on that score. You might absorb some Tin through your stomach, but the amount you could possibly absorb would be really small, and Tin isn't very toxic, either (they do line food cans with it, you know).
-Mark