Well, "closed off" in the sense that nothing changed. The reality is that Be lost interest in the platform as they had their eyes on x86: technically they could have found a way, politically they were looking for an out.
At the time they came out with a fairly spurious argument that the GPL might somehow contanimate them if they so much as looked at the N various flavours of Linux which could all boot on the machines they didn't want to support.
The software was so completely irritating and impossible to use that I decided it was more than my university career was worth and dropped out of university with nothing at the end of first year
Here's an alternative explanation. You're a bit of a dumbass, and decided to bail from a privilege that most of humanity never gets a chance to experience (higher education).
Anyone who decides to give up that opportunity because of a flaky IDE is a dipshit. Sorry to have to be the one to break it to you.
Oh, they've heard of it - unfortunately just about everything related to wavelet compression is patented beyond belief, and as such nobody is particularly interested in turning it into a mass-market product.
Most of the patent holders are not in the consumer space, and are happy to sit on it for now or use it for specialised areas such as commercial archival.
Personally, due to the number of devices that I have had batteries go in (cameras and cell phones) I would never buy an iPod for fear of the battery issues.
Personally, the "iPod batteries die" story doesn't match my experience. I have two original 5Gb iPods, purchased in December 2001, which are still doing fine (6 hours on one, 5 on the other).
Sure, the batteries will die eventually. But to be honest they're as likely to end their life due to being stolen/dropped/soaked/etc like any other piece of consumer electronics you carry around with you whenever you leave the house.
No, you download games because a)they're something you want and b)downloading lets you get them for free. If you didn't want them, you wouldn't download them.
Your little "I have a god given right to ship gigs of traffic over the campus network" rant is made all the funnier by the fact that your ~jrockway link is now 404...
Encryption is real, and it's powerful.
Certainly is, but sysadmins are more powerful. If you're shipping gigs of encrypted traffic around then prepare to find yourself with a bandwidth cap if they're feeling nice, and a rumor that you're distributing child pr0n and using encryption to cover your tracks if they're not so nice.
I suspect you'll divulge the true contents fairly quickly once word of that gets around (at which point your cries of "but it's only Spiderman 2" aren't going to cut much ice either: you're denying distributing something very illegal in order to admit to distributing something that's plain normal illegal? Smooth move there...).
That's a pretty weak analogy - those plug-ins are plug-ins that the host application designed itself to be able to support. An app developer may not have anticipated exactly what QuickTime codecs the user was planning to install, but they're aware that the list is extensible and may change over time.
A haxie is injecting completely arbitrary code into the app, code that the app developer had no way of planning for. E.g., I call MoveWindow to move the window - and your code replaces my call with one to a FunkyMoveWindow that snaps it to some other position. Except that elsewhere in my code I assumed (quite reasonably) that MoveWindow(100,100) would do exactly what I expected it to - and wasn't anticipating it leaving the window at (30,100) instead...
Moving a window to the wrong place might not be a problem (then again, who can tell) but that level of redirection can easily get you into trouble - a haxie just doesn't know what assumptions the app code is making that it might be changing from under it. And that's not even touching on the fact that my app has no idea what your code is doing: if it scribbles over my address space and makes me crash, how am I supposed to debug something like that?
Let's hope after WWDC people see the trend of less Carbon and more Cocoa that Apple is committing to, now and the long-term.
Enough already with the Cocoa fanboy stuff - if you like the API, you do neither it nor yourself any favors with this kind of post. Bits of the system are implemented in Carbon, bits are implemented in Cocoa, and neither are going away.
Apple have committed to maintaining both Carbon and Cocoa as equally valid frameworks for application development within the system - that's been the message on stage from the last 3 WWDCs, and I see no reason to think it'll be any different this year.
Had the supposedly "buggy" patch installed, and then got the new one. Never saw a difference in wireless signal strength. All bars lit.
Of course, the AP is located in a strategic location in the house using sound RF engineering principals to determine the location and not stuffed in a dresser underneath the clean socks, and a pie tin, as it would appear the whiners have done to themselves...;-)
Conversely I had the AP located 40cm away from the PowerBook, passing through 3cm of wood, and got repeated loss of signal (I'd still be joined to the network, but would be unable to pass IP traffic anywhere: even to ping the base station).
This was a 1.25Ghz AlBook connecting to an original Graphite base station. A G3 iBook connecting to the exact same base station from 2 rooms away was absolutely fine with the update installed, but the AlBook was lucky to last 5 minutes before losing the connection.
The physics of RF at 2.4 GHz haven't changed any recently, last I checked.
Although a lot of people complained about the signal strength dropping, there were definitely other problems with the previous release. I was still getting 5 bars, yet was unable to make a stable connection - absolutely nothing else changed on the Mac or the AP apart from this update, and since rolling it back I haven't lost the connection once.
It is indeed a carbon thing.
I'm not sure if there is a similar limitation in Cocoa or not.
Given that iMovie is a Cocoa app, it's more likely to be "a Cocoa thing". The Carbon API for allocating large files, FSAllocateFork, takes a UInt64 for the file size (so can allocate a lot more than 2Gb).
if some customer has a bug with version 2.1.2.4 of Foofware, the company can just check that out, instead of figuring out (and hoping to get it right) how to build it
Your build system is seriously broken if this is the case. The whole point of revision control is that you can get back to a previous build just by fetching a specific tag or branch. If that means that you need to keep your entire dev environment (IDE+tools straight off the CD, headers, runtime libraries, etc) under revision control then that's what you should do.
Builds have to be deterministic if you want to have reliable QA, and making the build process reproducible is at least as important as using source control. The alternative is you end up checking out a build from 6 months ago that crashes, yet when you try and build the equivalent source the crash goes away. Having to say "um, this should be the same build but this one works and that one doesn't and I can't tell you why" is a sign that something pretty serious has gone wrong in your process.
There are plenty of other good reasons to keep binary data in a revision control system (images, sound, models, data for regression tests, materials for installers, etc) but trying to avoid having to have a deterministic build process shouldn't be one of them.
Third party libraries that you never build yourself can obviously be checked in as-is, but anything that you build from source should always be buildable from source on a brand new workspace. No ifs, no buts - if you can't produce a reliable build on demand, how do you know what's going into any of your builds?
Z is a "formal methods" language. These are languages that allow you to write proofs about your programs - given some specification, you can generate a proof which demonstrates that your program complies to the specification.
Obviously it doesn't/can't deal with errors in the specification itself, but it can reduce errors in the implementation process.
Bones we need on the earth would be overkill on the moon! Same is valid for muscles
That could well be true, however a lifetime of zero-g could mean you would never be able to leave space (so you'd have the same problem, in reverse).
As soon as you tried to land on a planetary body with noticeable gravity, your skeleton would probably be unable to support your own weight. Unless you also underwent significant weight loss - in which case you would find yourself abnormally frail, and could easily suffer a fatal bone fracture to something like your rib-cage or skull (weaker bones combined with lack of surrounding fat/muscle).
Among lonely Slashdot posters, maybe. Among professionals, the opposite is true.
Actually I've been a professional (i.e., making my living from it) Mac developer for about 10 years now. I'd have no problem switching to Xcode if I thought it was an improvement on CW - it's certainly getting there, but I'm pretty sure I'll pass on it for the next couple of versions.
Xcode compiles are nearly as fast as CodeWarrior.
If you honestly believe this, you've not used either of them heavily enough. An example I can quote you is a project that takes about 45 minutes to build in CW, takes about an hour and 15 minutes with Xcode. Obviously once you start throwing distributed builds or multiprocessing in then your build times go down, but gcc's precompiled header support (even with the changes in Xcode) just isn't as quick as CW.
Apple's XCode and Project Builder have a pretty good reputation, I think.
Actually they have a spectacularly lousy reputation - ProjectBuilder was woeful, and while Xcode has made a lot of improvements (primarily in precompiled headers) it (or rather gcc) is still noticeably slower than CodeWarrior. If your time is money, a 40 minute build vs 2 hours makes CW a pretty easy choice.
Xcode does have distributed builds and MP support, but they probably won't be of much use if you're working on a single PowerBook.
Sure - although this is talking about NYC, the principle (low/zero-interest loans from a collective) is pretty common in any society with a large immigrant population (i.e., not just in the US, world-wide).
pushing Beagle2 on a shopping trolley. This wasn't a "let's play up the low price tag" PR photograph. He really was transporting the lander on a shopping trolley
It may have been a genuine photo, however he would have been pushing a shell or one of the mock-ups used for assembly testing. The actual lander itself was assembled in an Aseptic Assembly Facility (aka "clean room"), and transported to the launch site by truck on a sealed container. This container was about 2-3m on each side, and lifted into the truck on a pallet. The seal had to be intact from the time it left the AAF until it was inserted into Mars Express, as one of the biggest concerns has been that we will end up shipping some Earth microbes along with Beagle 2 - and giving false positives when it starts looking for microbes on Mars.
Blur's call sign is simply a couple of bytes used to identify packets coming from Beagle that can be mapped to a table of notes back on earth. It will doubtless be played through a futuristic-sounding synth for PR purposes, but then how else would you "play" eight or nine bytes...:-)
Which isn't to say the project hasn't been an incredible achievement. It's been done on an absolutely miniscule budget/schedule compared with other lander missions, and it's a real achievement to have even made it this far given the paucity of space funding in the UK.
You build a simulation. Right now this is still in its infancy, and these systems obviously have to prove their worth by producing accurate results, but virtual organ simulation is where things are headed.
It's very likely we won't have the computing power available to simulate these accurately for another 20 years - but so far there doesn't seem to be anything that would prevent you from, in principle, modeling organs on a sub-cellular basis and obtaining a reasonable simulation of their macroscopic behaviour.
I hear a lot about people going to universities with video game degrees. I don't hear much about how the video game industry in general views these degrees. Do they respect them?
No, not really. Which you're not going to hear from anyone employed by/who's been through one of these places, but it's the truth.
The modern games industry is structured around two basic concepts - a continual cycle of cheap and keen labour ("I write games" sounds a lot sexier than "I submit databases queries to a machine I've never seen down in the basement", so there's always demand) coming in, and making money on 1-2 hits from big names (Will Wright, Warren Spector, Peter Molyneux, etc) to pay for the other 8-9 titles that flop.
From a publisher's point of view, if you've signed up your sure-fire/franchise hits for the year then you can afford to take a gamble on your 8-9 other titles - and you really don't care where the people developing them went to school, you want to know their track record. If they've actually shipped something in the past they have a good chance of doing it again, and so even if the game isn't a blockbuster you will at least get it delivered. This means, even if the game sucks, you will probably sell enough to break even - and may even get lucky and have a surprise hit.
From a developer, the same applies. First and foremost you're looking for people who've actually shipped things in the past. Failing which you're looking for cheap new hires (from anywhere), who're a)keen and b)smart (the second one being optional, depending on how good the company is).
These places are attempting to set themselves up as almost trade schools, but they're missing the point - although the application of computing science is what both they and the real world "do", the real world only cares about the real world.
If you haven't actually got that "I shipped this title" on your CV yet, what you do have on your CV is less interesting to an employer than how you've conducted yourself. If you've continued your education then that's encouraging, but if you want to distinguish yourself then either a)do something like a challenging degree (CS, maths, philosophy, medicine, law, theology - the subject isn't particularly significant) or b)skip academia and achieve something independently.
A lot of what he writes is tripe, but you should assume that your prospective employer is looking for people who are Smart and Gets Things Done. Neither of those are contingent on having a degree in Pokemon.
You don't expect a developer who's exceptionally good at 3D/game programming to be able to write optimized code for a database engine, do you?
Of course I would. Being able to write move between fields within your discipline is the hallmark of anyone who's "exceptionally good" at anything (barring idiot savants).
If a developer came to me and said "ooh, I can't work on project X - I only work on project Ys", then it really doesn't matter how good they are at working on project Ys. If they're a one-trick-pony, they don't have the experience or the skills that make them truly valuable.
I don't expect them to be born with the knowledge of how to write an optimized database query, but at the same time neither were the developers who are exceptionally good at doing that today - they're just smart people, who were willing to apply themselves.
I would hazard that he might view Apple's decision to market their "Panther" product via the use of an all-black box and the "X" symbol as an example of whites exploiting African American cultural symbols for their own ends (and profits).
Uh, right - on the other hand, given that he was a fairly smart guy, he may well have realised that the "X" stands for ten, the Panther is because all the Mac OS X releases are named after big cats, and the box is black for the same reason the Jaguar box had faux-Jaguar fur...
Slashdot Mirror
You can't have the man married, then pretend it never happend (which it should not have in the first place).
But Aquaman, you can't marry a woman without gills... you're from two completely different worlds!
Well, "closed off" in the sense that nothing changed. The reality is that Be lost interest in the platform as they had their eyes on x86: technically they could have found a way, politically they were looking for an out.
At the time they came out with a fairly spurious argument that the GPL might somehow contanimate them if they so much as looked at the N various flavours of Linux which could all boot on the machines they didn't want to support.
The software was so completely irritating and impossible to use that I decided it was more than my university career was worth and dropped out of university with nothing at the end of first year
Here's an alternative explanation. You're a bit of a dumbass, and decided to bail from a privilege that most of humanity never gets a chance to experience (higher education).
Anyone who decides to give up that opportunity because of a flaky IDE is a dipshit. Sorry to have to be the one to break it to you.
Oh, they've heard of it - unfortunately just about everything related to wavelet compression is patented beyond belief, and as such nobody is particularly interested in turning it into a mass-market product.
Most of the patent holders are not in the consumer space, and are happy to sit on it for now or use it for specialised areas such as commercial archival.
Personally, due to the number of devices that I have had batteries go in (cameras and cell phones) I would never buy an iPod for fear of the battery issues.
Personally, the "iPod batteries die" story doesn't match my experience. I have two original 5Gb iPods, purchased in December 2001, which are still doing fine (6 hours on one, 5 on the other).
Sure, the batteries will die eventually. But to be honest they're as likely to end their life due to being stolen/dropped/soaked/etc like any other piece of consumer electronics you carry around with you whenever you leave the house.
There are no facts.
Is that a fact?
We don't; that's why we download games.
No, you download games because a)they're something you want and b)downloading lets you get them for free. If you didn't want them, you wouldn't download them.
Your little "I have a god given right to ship gigs of traffic over the campus network" rant is made all the funnier by the fact that your ~jrockway link is now 404...
Encryption is real, and it's powerful.
Certainly is, but sysadmins are more powerful. If you're shipping gigs of encrypted traffic around then prepare to find yourself with a bandwidth cap if they're feeling nice, and a rumor that you're distributing child pr0n and using encryption to cover your tracks if they're not so nice.
I suspect you'll divulge the true contents fairly quickly once word of that gets around (at which point your cries of "but it's only Spiderman 2" aren't going to cut much ice either: you're denying distributing something very illegal in order to admit to distributing something that's plain normal illegal? Smooth move there...).
That's a pretty weak analogy - those plug-ins are plug-ins that the host application designed itself to be able to support. An app developer may not have anticipated exactly what QuickTime codecs the user was planning to install, but they're aware that the list is extensible and may change over time.
A haxie is injecting completely arbitrary code into the app, code that the app developer had no way of planning for. E.g., I call MoveWindow to move the window - and your code replaces my call with one to a FunkyMoveWindow that snaps it to some other position. Except that elsewhere in my code I assumed (quite reasonably) that MoveWindow(100,100) would do exactly what I expected it to - and wasn't anticipating it leaving the window at (30,100) instead...
Moving a window to the wrong place might not be a problem (then again, who can tell) but that level of redirection can easily get you into trouble - a haxie just doesn't know what assumptions the app code is making that it might be changing from under it. And that's not even touching on the fact that my app has no idea what your code is doing: if it scribbles over my address space and makes me crash, how am I supposed to debug something like that?
Let's hope after WWDC people see the trend of less Carbon and more Cocoa that Apple is committing to, now and the long-term.
Enough already with the Cocoa fanboy stuff - if you like the API, you do neither it nor yourself any favors with this kind of post. Bits of the system are implemented in Carbon, bits are implemented in Cocoa, and neither are going away.
Apple have committed to maintaining both Carbon and Cocoa as equally valid frameworks for application development within the system - that's been the message on stage from the last 3 WWDCs, and I see no reason to think it'll be any different this year.
Had the supposedly "buggy" patch installed, and then got the new one. Never saw a difference in wireless signal strength. All bars lit. Of course, the AP is located in a strategic location in the house using sound RF engineering principals to determine the location and not stuffed in a dresser underneath the clean socks, and a pie tin, as it would appear the whiners have done to themselves... ;-)
Conversely I had the AP located 40cm away from the PowerBook, passing through 3cm of wood, and got repeated loss of signal (I'd still be joined to the network, but would be unable to pass IP traffic anywhere: even to ping the base station).
This was a 1.25Ghz AlBook connecting to an original Graphite base station. A G3 iBook connecting to the exact same base station from 2 rooms away was absolutely fine with the update installed, but the AlBook was lucky to last 5 minutes before losing the connection.
The physics of RF at 2.4 GHz haven't changed any recently, last I checked.
Although a lot of people complained about the signal strength dropping, there were definitely other problems with the previous release. I was still getting 5 bars, yet was unable to make a stable connection - absolutely nothing else changed on the Mac or the AP apart from this update, and since rolling it back I haven't lost the connection once.
It is indeed a carbon thing. I'm not sure if there is a similar limitation in Cocoa or not.
Given that iMovie is a Cocoa app, it's more likely to be "a Cocoa thing". The Carbon API for allocating large files, FSAllocateFork, takes a UInt64 for the file size (so can allocate a lot more than 2Gb).
You say I'm wrong without any facts to back it up, and someone is supposed to believe your claim?
You say you're right without anything to back it up, and someone is supposed to believe your claim?
if some customer has a bug with version 2.1.2.4 of Foofware, the company can just check that out, instead of figuring out (and hoping to get it right) how to build it
Your build system is seriously broken if this is the case. The whole point of revision control is that you can get back to a previous build just by fetching a specific tag or branch. If that means that you need to keep your entire dev environment (IDE+tools straight off the CD, headers, runtime libraries, etc) under revision control then that's what you should do.
Builds have to be deterministic if you want to have reliable QA, and making the build process reproducible is at least as important as using source control. The alternative is you end up checking out a build from 6 months ago that crashes, yet when you try and build the equivalent source the crash goes away. Having to say "um, this should be the same build but this one works and that one doesn't and I can't tell you why" is a sign that something pretty serious has gone wrong in your process.
There are plenty of other good reasons to keep binary data in a revision control system (images, sound, models, data for regression tests, materials for installers, etc) but trying to avoid having to have a deterministic build process shouldn't be one of them.
Third party libraries that you never build yourself can obviously be checked in as-is, but anything that you build from source should always be buildable from source on a brand new workspace. No ifs, no buts - if you can't produce a reliable build on demand, how do you know what's going into any of your builds?
Z is a "formal methods" language. These are languages that allow you to write proofs about your programs - given some specification, you can generate a proof which demonstrates that your program complies to the specification.
Obviously it doesn't/can't deal with errors in the specification itself, but it can reduce errors in the implementation process.
Bones we need on the earth would be overkill on the moon! Same is valid for muscles
That could well be true, however a lifetime of zero-g could mean you would never be able to leave space (so you'd have the same problem, in reverse).
As soon as you tried to land on a planetary body with noticeable gravity, your skeleton would probably be unable to support your own weight. Unless you also underwent significant weight loss - in which case you would find yourself abnormally frail, and could easily suffer a fatal bone fracture to something like your rib-cage or skull (weaker bones combined with lack of surrounding fat/muscle).
Among lonely Slashdot posters, maybe. Among professionals, the opposite is true.
Actually I've been a professional (i.e., making my living from it) Mac developer for about 10 years now. I'd have no problem switching to Xcode if I thought it was an improvement on CW - it's certainly getting there, but I'm pretty sure I'll pass on it for the next couple of versions.
Xcode compiles are nearly as fast as CodeWarrior.
If you honestly believe this, you've not used either of them heavily enough. An example I can quote you is a project that takes about 45 minutes to build in CW, takes about an hour and 15 minutes with Xcode. Obviously once you start throwing distributed builds or multiprocessing in then your build times go down, but gcc's precompiled header support (even with the changes in Xcode) just isn't as quick as CW.
Apple's XCode and Project Builder have a pretty good reputation, I think.
Actually they have a spectacularly lousy reputation - ProjectBuilder was woeful, and while Xcode has made a lot of improvements (primarily in precompiled headers) it (or rather gcc) is still noticeably slower than CodeWarrior. If your time is money, a 40 minute build vs 2 hours makes CW a pretty easy choice.
Xcode does have distributed builds and MP support, but they probably won't be of much use if you're working on a single PowerBook.
Sure - although this is talking about NYC, the principle (low/zero-interest loans from a collective) is pretty common in any society with a large immigrant population (i.e., not just in the US, world-wide).
pushing Beagle2 on a shopping trolley. This wasn't a "let's play up the low price tag" PR photograph. He really was transporting the lander on a shopping trolley
:-)
It may have been a genuine photo, however he would have been pushing a shell or one of the mock-ups used for assembly testing. The actual lander itself was assembled in an Aseptic Assembly Facility (aka "clean room"), and transported to the launch site by truck on a sealed container. This container was about 2-3m on each side, and lifted into the truck on a pallet. The seal had to be intact from the time it left the AAF until it was inserted into Mars Express, as one of the biggest concerns has been that we will end up shipping some Earth microbes along with Beagle 2 - and giving false positives when it starts looking for microbes on Mars.
Blur's call sign is simply a couple of bytes used to identify packets coming from Beagle that can be mapped to a table of notes back on earth. It will doubtless be played through a futuristic-sounding synth for PR purposes, but then how else would you "play" eight or nine bytes...
Which isn't to say the project hasn't been an incredible achievement. It's been done on an absolutely miniscule budget/schedule compared with other lander missions, and it's a real achievement to have even made it this far given the paucity of space funding in the UK.
You build a simulation. Right now this is still in its infancy, and these systems obviously have to prove their worth by producing accurate results, but virtual organ simulation is where things are headed.
It's very likely we won't have the computing power available to simulate these accurately for another 20 years - but so far there doesn't seem to be anything that would prevent you from, in principle, modeling organs on a sub-cellular basis and obtaining a reasonable simulation of their macroscopic behaviour.
no-iron slacks and no-iron shits
Dude, if you're thinking of ironing your own faeces then you've got bigger problems than just dress sense...
I hear a lot about people going to universities with video game degrees. I don't hear much about how the video game industry in general views these degrees. Do they respect them?
No, not really. Which you're not going to hear from anyone employed by/who's been through one of these places, but it's the truth.
The modern games industry is structured around two basic concepts - a continual cycle of cheap and keen labour ("I write games" sounds a lot sexier than "I submit databases queries to a machine I've never seen down in the basement", so there's always demand) coming in, and making money on 1-2 hits from big names (Will Wright, Warren Spector, Peter Molyneux, etc) to pay for the other 8-9 titles that flop.
From a publisher's point of view, if you've signed up your sure-fire/franchise hits for the year then you can afford to take a gamble on your 8-9 other titles - and you really don't care where the people developing them went to school, you want to know their track record. If they've actually shipped something in the past they have a good chance of doing it again, and so even if the game isn't a blockbuster you will at least get it delivered. This means, even if the game sucks, you will probably sell enough to break even - and may even get lucky and have a surprise hit.
From a developer, the same applies. First and foremost you're looking for people who've actually shipped things in the past. Failing which you're looking for cheap new hires (from anywhere), who're a)keen and b)smart (the second one being optional, depending on how good the company is). These places are attempting to set themselves up as almost trade schools, but they're missing the point - although the application of computing science is what both they and the real world "do", the real world only cares about the real world.
If you haven't actually got that "I shipped this title" on your CV yet, what you do have on your CV is less interesting to an employer than how you've conducted yourself. If you've continued your education then that's encouraging, but if you want to distinguish yourself then either a)do something like a challenging degree (CS, maths, philosophy, medicine, law, theology - the subject isn't particularly significant) or b)skip academia and achieve something independently.
A lot of what he writes is tripe, but you should assume that your prospective employer is looking for people who are Smart and Gets Things Done. Neither of those are contingent on having a degree in Pokemon.
You don't expect a developer who's exceptionally good at 3D/game programming to be able to write optimized code for a database engine, do you?
Of course I would. Being able to write move between fields within your discipline is the hallmark of anyone who's "exceptionally good" at anything (barring idiot savants). If a developer came to me and said "ooh, I can't work on project X - I only work on project Ys", then it really doesn't matter how good they are at working on project Ys. If they're a one-trick-pony, they don't have the experience or the skills that make them truly valuable.
I don't expect them to be born with the knowledge of how to write an optimized database query, but at the same time neither were the developers who are exceptionally good at doing that today - they're just smart people, who were willing to apply themselves.
I would hazard that he might view Apple's decision to market their "Panther" product via the use of an all-black box and the "X" symbol as an example of whites exploiting African American cultural symbols for their own ends (and profits).
Uh, right - on the other hand, given that he was a fairly smart guy, he may well have realised that the "X" stands for ten, the Panther is because all the Mac OS X releases are named after big cats, and the box is black for the same reason the Jaguar box had faux-Jaguar fur...