I think what I'm most excited for with this release is seeing if Oracle follows through on their promise to put out the source for the up-to-the-date work on ZFS. While ZFS at v28 has proven to be both a lot of fun and very useful for many of us, the updates since (first available for general use with Solaris 11 Express last year I believe) add a few really nice features, including crypto and work on block pointer rewrite. While the illumos project could certainly fork it if required, it would be really great if everyone could stay in sync more. After the acquisition, rather then do nightly releases there was a decision to opt for only releasing code with major versions, which while disappointing at least offered hope going forward. I don't see that Oracle has anything to lose here by staying open with that component, filesystems benefit a lot from widespread use and lots of testing, but, well, it is Oracle.

I addressed this in passing, but perhaps it's worth some additional expansion. I wrote:

What you seem to be arguing for is additional DRM, ie., a technical protection measure in order to enforce the wishes of the developer. However, compared to a purely social and legal framework, where customers and people in general are simply expected to be adults and do the right thing, there are significant downsides.

1. There is additional cost to develop and deploy technical protection methods on the developer side, towards no real overall economic gain.
2. On the user side, these measures can present honest customers with significant additional hassle and no gain while failing to do anything to the dishonest. This is the case in general, but particularly the case with an operating system. Under the current state of things, Mac OS X has no serial, no ownership checks, and no checks for previous versions. It only has some weak checks to see if it's on a Mac, and otherwise depends on license requirements. The net result is that one never even has to think about it when it comes to upgrading a machine, imaging new machines, etc. It's fine to change hardware, nuke the old hard drive, run it off a direct connect or networked image, just copy right over from one hard drive to another, or anything else possible. In any case, there will never be any trip up.
   Under your scenario, things become much more complicated to no value. To upgrade, you first need to go and dig up your old install media and install that? What if it's been a few versions, you have to start a couple back, then install one upgrade, then the next upgrade? Is it even allowed under this scenario to simply ditto over from an old drive to a new one? This doesn't seem like a net gain.
3. Finally, if there is no rule of law and society involved, but merely technical protection, I see no way around the economic incentive to ever more heavily restrict stuff. Deep hardware level DRM practically becomes a requirement under this scenario, one where you're not just up against random individuals who aren't really any commercial loss, but against serious businesses. This seems bad every way around, from the perspective of consumer choice and of competition. A massive multinational like Apple could afford to reengineer everything, but a small dev?

I think it's better to have a system where the general standards just exist as a matter of law and society.

To my mind, software upgrades are an economically efficient and pro-user offering. They are good for both the production and use side of the equation, allowing users to pay directly for the additional cost of development since their last version rather then all the original work and value that went into the product. They allow developers to reward their own supporters and more efficiently allocate resources. Additionally, "upgrades" should be (again, from a user perspective) simply full versions, identical, except cheaper and for existing users. This is how all commercial software I use works as well.

However, the entire concept of upgrades depends completely on legal licensing: that I can have a clause that says "you may not use this unless you previously owned a full version". I already see a number of posts, both here on Slashdot and on other forums (such as the comments with the Ars Technica article on this story), that are enraged at the result, and that argue that Psystar was "adding value" by "lowering hardware costs". The underlying argument is that, if a piece of software is sold, that should be that. However, how do those of you who argue for that square it with upgrading? Do you simply agree with the App Store take, where upgrades don't exist at all? Or do you have some other way of squaring things away?

As things have existed, Mac OS X offerings have all been upgrades and have been priced accordingly. There seems to be a reasonable consideration on both sides here: buyers pay less money, but in exchange have the restriction of needing to have a Mac as Apple has chosen to build their development around an integrated model. Do some of you think that such integrated models should be illegal, regardless of what benefits they offer? Should Apple be required by law to sell a "full" version of Mac OS X, and would you actually be willing to pay what that might cost (ie., if they said "full version, $400")? I'm genuinely curious about people's thoughts around this.

Haven't posted in a long time either, but I too want to toss in my small token of thanks for an amazing job and long run.

It seems to have become trendy again to hate Apple no matter what, but this is getting ridiculous. Why is it that Apple is expected to be the only platform vendor that has to maintain their own version of the JVM for free? Jobs is quite correct in saying that Java under OS X has long lagged behind the latest official Sun release. I wish it was more common for Apple to leave more components to third parties now that they've got more market share. Another example would be graphics drivers, which lag tremendously in both performance and features. I don't understand why on Earth any Java dev would want to be stuck indefinitely with Apple's outdated implementation that by definition would never be a major priority rather then get a version from the main organization behind it. For that matter I blame Sun's longstanding ambivalence toasted FOSS. If we had a fully open GPL edition of the JVM that was best of class like we should have gotten years ago, this never would have been an issue in the first place. It's yet another tech Sun's BS has screwed us on, with their insistance to out ZFS under the CDDL rather then Apache/BSD/LGPL being another major example. Anyone still have that old sun strategy wheel, from before 'acquisition' became their final exit?

Or the converse, I suppose (hardware solutions can add another layer to this). This looks like some very interesting work, and may have more applicability in general beyond this one scenario. I'm certainly looking forward to following their implementation as it comes along. But with that said, if this attack was a serious concern for a given entity there seem to be some obvious potential hardware solutions. The attack essentially depends on being able to shutdown the computer but keep the memory cold enough that the randomization time is slowed down tremendously, giving enough time to perform a dump of the contents onto another system for further analysis. Therefore, it can be prevented by, for example, having electric heater units surrounding the memory connected to a dedicated capacitor bank and temperature sensor, as well as a sensor to detect if someone tries for force open the machine (intrusion alarm). Then the system can perform a scram shutdown (or if it is just shutdown normally), and the heaters can assure that the memory is kept hot for a couple of seconds afterwards even in the face of attempted cooling. It only needs to manage it very briefly and then all the contents are scrambled. Other similar methods (maybe a really micro EMP inside a shield memory space) would be possible to, but basically they just need to deny an attacker for a very short amount of time or ensure entropy in the RAM and then the attack is useless.

Ultimately a dedicated hardware secure key store would be better and easier to integrate across all systems, and this more software solution of course has the massive advantage of being able to run for free on existing hardware. But the above could at least be retrofitted on nearly anything, and while it is more esoteric, then again so is the attack since it requires physical access.