The plist format can easily be parsed into the standard system collection opaque types (dictionaries, arrays, strings, numbers, etc) by the frameworks.
this sort of malware would not be able to do anaweful lot except perhaps create some files and run some processes as a user.
Or delete their important files. Since an awful lot of mac installations are single users who undoubtedly log in as an administrative user on a regular basis, all their files can be borken and root can effectively be gained quite easily anyway.
Not to mention, there are quite a few locally exploitable root holes in Mac OS X, and you can expect that the majority of users won't be patched and up to date.
It'd be hard to make a business case for porting iTunes to Linux on the desktop at the moment, because the user base just isn't there. I can't see that the numbers would add up.
Of course Linux users can listen to digital music legally. Just buy it on CDs;-)
Actually, iTunes doesn't use WebKit at all. It uses a custom view architecture based on rendering some HTML-like XML that is spat out of a WebObjects-powered back-end. iTunes doesn't use Cocoa at all.
It's somewhat unlikely that Apple ported all of Carbon to Windows, yes, but apparently some of the lower-level bits of it were ported to support QuickTime way back in the mid nineties (File Manager and stuff).
There's also an archaic port of Cocoa's predecessor to Windows, but you can't buy runtime licenses for it, it's horribly broken and not supported.
Not to mention, ThinkGeek is part of OSTG these days (like/.), so that's kind of a vested interest. It's great to see that they're happy to acknowledge competition (even if it's not totally direct since they're catering to a different market).
LICENSE ------- We are releasing the source code for the j3d-core-utils and j3d-examples projects under a BSD license.
We are releasing the source code for the j3d-core and vecmath projects under separate research and commercial license. The research license is the Java Research License (JRL). The commercial license is the Java Distribution License (JDL), a no-fee license that allows a vendor to ship a compatible version of Java 3D with or without modification.
While AAC itself is a standard, the DRM is not. They can't distribute Protected AAC files because they don't know how to make them and can't legally find out. That's unless Apple tells them, which they won't (they wouldn't let Real in on it, so why Napster?).
Real wanted to get in on the Protected AAC thing behind the scenes as a provider of content. As has already been mentioned, this SDK is nothing to do with AAC at all (that functionality is already provided by the QuickTime SDK, this is merely for controlling/scripting iTunes' GUI).
The QuickTime SDK merely allows you to play a Protected AAC music file to a given sound output device as a client of the system (which remains a proprietary black box). Not what Real wants at all.
From an end user perspective, the most significant change to the service will be that it will only offer freely available technical software resources. Scholarly and Academic resources will no longer be mirrored. It is expected that the current portfolio of technical resources will continue to be mirrored and that any inconvenience to users during the changeover of service will be kept to an absolute minimum.
Having said that, I'm somewhat sceptical awarding the contract based on cost won't lead to a degradation of service. Whatever happened to "if it ain't broke, don't fix it"?
You can take a.m4p and copy it to any media you like. However, if you try to play it on any new computer you will need to authorise that computer first.
Carbon is emphatically *NOT* a stepping-stone API.
Apple continues to improve and evolve the Carbon API, dropping a lot of their legacy cruft and encouraging developers to move their applications forwards. While it does ease porting, if you just do the minimum so your old apps compile and run on OS X, you do not really have a Mac OS X application - it probably won't look and feel completely right.
Carbon also works completely differently under the hood. As time goes on, Apple exposes these improvements through entirely new API, for example the HIView stuff that appeared in 10.2. Things like QuickDraw are largely going away for a lot of uses, with more modern alternatives like Quartz 2D or OpenGL recommended depending on your needs.
It's also important to note that Cocoa is actually implemented using Carbon in some cases, and we're starting to see the reverse also be true.
You can't say that Carbon, at its heart, is a "horrible, messy kludge". It's actually a fully-featured modern procedural API for creating native applications that provide a full Mac OS X look and feel.
Having said that, it's highly unlikely that Carbon will see the light of day on other platforms, purely because of the effort involved in writing something comparable and the sheer size of the API.
Apple seems to be pushing Carbon as its lower-level application development API, and Cocoa as its application framework (as a replacement to MacApp, the former C++ framework that was based on Carbon).
If you can't afford to pay, don't have a TV (which you presumably can't afford to buy, either). This way you do not break the law.
However, I find it hard to believe you can't afford to pay a television license fee, as if you look at the council flats around here (people who "can't afford" to pay for their own housing) they're covered in satellite dishes dotted all over the walls and roofs.
iTunes is a Carbon application, not a Cocoa one, so GNUstep won't help you one bit.
Apple could of course only ever release it binary-only, as it has dependencies on third party code (just from reading iTunes about box, you see that it uses Gracenote's CDDB, ACELP, Audible, Dolby and Whitecap stuff).
There are third party clones of QuickTime, the file format is pretty well documented. See OpenQuicktime. The main missing bits are codecs, but you're free to write your own for standards (MP3, hook in XviD for MPEG 4, yadda yadda) and bitch at the third party companies (Sorenson) to get them to release binaries of theirs.
Sorry to burst your bubble, but it's not going to happen
There's absolutely no reason whatsoever that Winamp can't play protected AAC files, they are free to use the QuickTime API if they want to add support for it.
iTunes is not the only player that can play them, AFAIK RealOne Player can as of a recent release.
Slashdot Mirror
The plist format can easily be parsed into the standard system collection opaque types (dictionaries, arrays, strings, numbers, etc) by the frameworks.
It can also kick daemons when the network configuration changes, on wake from sleep, etc.
this sort of malware would not be able to do anaweful lot except perhaps create some files and run some processes as a user.
Or delete their important files. Since an awful lot of mac installations are single users who undoubtedly log in as an administrative user on a regular basis, all their files can be borken and root can effectively be gained quite easily anyway.
Not to mention, there are quite a few locally exploitable root holes in Mac OS X, and you can expect that the majority of users won't be patched and up to date.
Because under the hood, OS X is a perfect OS with no evilness whatsoever. Oh, and every API that Apple uses in all their applications is documented.
Mac OS X comes with a built-in spell checker.
Apple was one of the early investors in Akamai and they've been using their streaming services for many years...
Their event streaming entry point is even http://stream.apple.akadns.net/ (although that's still pointing to the Music Event from a few months back).
You have to be enough of a fanboy to watch it live... If you already know what's going to happen, where's the fun in watching it at all?
It'd be hard to make a business case for porting iTunes to Linux on the desktop at the moment, because the user base just isn't there. I can't see that the numbers would add up.
;-)
Of course Linux users can listen to digital music legally. Just buy it on CDs
Actually, iTunes doesn't use WebKit at all. It uses a custom view architecture based on rendering some HTML-like XML that is spat out of a WebObjects-powered back-end. iTunes doesn't use Cocoa at all.
It's somewhat unlikely that Apple ported all of Carbon to Windows, yes, but apparently some of the lower-level bits of it were ported to support QuickTime way back in the mid nineties (File Manager and stuff).
There's also an archaic port of Cocoa's predecessor to Windows, but you can't buy runtime licenses for it, it's horribly broken and not supported.
Not to mention, ThinkGeek is part of OSTG these days (like /.), so that's kind of a vested interest. It's great to see that they're happy to acknowledge competition (even if it's not totally direct since they're catering to a different market).
Pity the mods don't get tongue-in-cheekness, since I'm a Mac user myself. Oh, well.
I thought they were all gay, anyway?
You can get PDFs of the entire book from http://www.oreilly.com/catalog/wemedia/book/index. csp.
While AAC itself is a standard, the DRM is not. They can't distribute Protected AAC files because they don't know how to make them and can't legally find out. That's unless Apple tells them, which they won't (they wouldn't let Real in on it, so why Napster?).
Real wanted to get in on the Protected AAC thing behind the scenes as a provider of content. As has already been mentioned, this SDK is nothing to do with AAC at all (that functionality is already provided by the QuickTime SDK, this is merely for controlling/scripting iTunes' GUI).
The QuickTime SDK merely allows you to play a Protected AAC music file to a given sound output device as a client of the system (which remains a proprietary black box). Not what Real wants at all.
The most interesting bit of the blurb is:
Having said that, I'm somewhat sceptical awarding the contract based on cost won't lead to a degradation of service. Whatever happened to "if it ain't broke, don't fix it"?
You can take a .m4p and copy it to any media you like. However, if you try to play it on any new computer you will need to authorise that computer first.
I'm more annoyed that they made it separate from NSView (the Cocoa equivalent), so you can't mix and match the two. That's teh suck.
Of course not, I'm a Cocoa nut myself. I prefer to think of myself as a realistic, objective nut though, not a zealot.
Use the right tool for the right job.
There's a general trend towards providing alternatives that take CFStrings, which are fully unicode-aware opaque types.
Carbon is emphatically *NOT* a stepping-stone API.
Apple continues to improve and evolve the Carbon API, dropping a lot of their legacy cruft and encouraging developers to move their applications forwards. While it does ease porting, if you just do the minimum so your old apps compile and run on OS X, you do not really have a Mac OS X application - it probably won't look and feel completely right.
Carbon also works completely differently under the hood. As time goes on, Apple exposes these improvements through entirely new API, for example the HIView stuff that appeared in 10.2. Things like QuickDraw are largely going away for a lot of uses, with more modern alternatives like Quartz 2D or OpenGL recommended depending on your needs.
It's also important to note that Cocoa is actually implemented using Carbon in some cases, and we're starting to see the reverse also be true.
You can't say that Carbon, at its heart, is a "horrible, messy kludge". It's actually a fully-featured modern procedural API for creating native applications that provide a full Mac OS X look and feel.
Having said that, it's highly unlikely that Carbon will see the light of day on other platforms, purely because of the effort involved in writing something comparable and the sheer size of the API.
Apple seems to be pushing Carbon as its lower-level application development API, and Cocoa as its application framework (as a replacement to MacApp, the former C++ framework that was based on Carbon).
If you can't afford to pay, don't have a TV (which you presumably can't afford to buy, either). This way you do not break the law.
However, I find it hard to believe you can't afford to pay a television license fee, as if you look at the council flats around here (people who "can't afford" to pay for their own housing) they're covered in satellite dishes dotted all over the walls and roofs.
iTunes is a Carbon application, not a Cocoa one, so GNUstep won't help you one bit.
Apple could of course only ever release it binary-only, as it has dependencies on third party code (just from reading iTunes about box, you see that it uses Gracenote's CDDB, ACELP, Audible, Dolby and Whitecap stuff).
There are third party clones of QuickTime, the file format is pretty well documented. See OpenQuicktime. The main missing bits are codecs, but you're free to write your own for standards (MP3, hook in XviD for MPEG 4, yadda yadda) and bitch at the third party companies (Sorenson) to get them to release binaries of theirs.
Sorry to burst your bubble, but it's not going to happen
There's absolutely no reason whatsoever that Winamp can't play protected AAC files, they are free to use the QuickTime API if they want to add support for it.
iTunes is not the only player that can play them, AFAIK RealOne Player can as of a recent release.