Don't forget that any DRM can be reverse engineered
I think what you meant to say was that any DRM which relies on security by obscurity can be broken by reverse engineering stuff like key generation or secure rights storage. DRM itself is not a secret thing which needs to be reverse engineered. As soon as somebody introduces an end-to-end secure solution à la Palladium, there's nothing to be reverse engineered. Rather, the game is then to find security holes.
Ok, it's not that I disagree totally, but I think you underestimate the work Apple already has done with porting Quicktime and also iTunes to Windows. In addition to that, I'm sure they can build on their experiences with their (admittely now historical) StarTrek porting efforts.
Did I say anything about X? No. Now even if we would talk about X, what in your valued opinion is the amount of code related to the UI in Carbon which would result in a from scratch port of almost the entire thing?
Also, I don't need to "realize" that Aqua is not related to X, that's not exactly news to me. Sheesh...
...as iTunes written in Carbon (Porting that to Linux would be a nightmare)
The only nightmarish thing about this is litte endian vs. big endian and maybe some Mach specific calls. The whole idea of Carbon was to make the Macintosh Toolbox portable so it could run on MacOS X.
So you take your JavaScript experience and come up with "JavaScript sucks, JavaScript uses prototyping, therefore prototyping sucks?" Or what other prototyping languages have you used?
Years of posts on how woeful the US space program is, and then something like this happens, and there's 600 posts of how Bush is just doing to distract us from Iraq/look for oil/shovel money to Haliburton.
Funny you say that. To quote from this article from the Petroleum News (admittedly older):
Briggs said NASA has been working with Halliburton, Shell, Baker-Hughes and the Los Alamos National Laboratory to identify drilling technologies that might work on Mars. ...
Halliburton and Baker-Hughes are working on some very advanced systems, Briggs said, some so advanced they aren't willing to talk much about them. He said the NASA Ames Center relies on working with people in the industry who "really understand the problems and make us face up to the realities...
Of course, you can still make analog dubs to your heart's content, so there's really not much motivation to crack it. Sure, it would be neat to get the MLP 24bit/96kHz stream onto your PC, but so few PC sound systems could do it justice.
Agree to both points, but making analog copies is at the moment more work than just ripping. Once you got used to ripping or e.g. Kazaa, you don't really want to go back. Of course that's mostly a problem of setting up the right recording system/software. I also think that the gamble was to get all new releases on DVD-A only, but that hasn't happened so far.
Do you think the Powers That Be would really utilize the revocation?
Honestly? No;) - But still, the threat is there. And I wonder how much can be done via firmware upgrades. I.e. revoke a device class but offer a firmware upgrade. The question is probably who'll pay for all that nonsense. Probably the end user.
I fully agree. Another analogy would be Windows drivers. I assume most of them do only work with Windows and were implemented with Windows in mind. But if you'd accept the notion that they are derived work of Windows because of this (as Linus argues for Linux drivers/kernel modules), then Microsoft would own their copyright (at least shared with the original author).
Somehow, this seems hard to believe. Or are there Microsoft copyright statements in non-Microsoft Windows drivers now? Can't check now since I've got no Windows machine here...
Too bad you have to be an "authorized N-Gage developer" to program in C/C++
As I understand it, that's only necessary to develop games which are supposed to use the copy protection feature. Otherwise, you can just grab the Series60 SDK and start programming. I'm not sure however if there is any additional benefit in the N-Gage SDK such as 2D/3D or input APIs. But reading that the N-Gage games seem to also run on other Series60 devices, I'm sceptical about that.
Series 60: Symbian OS based, one-handed operation, UI developed by Nokia, licensed to other OEMs
Series 80: Symbian OS based, keyboad-centric, closest to the original Symbian/EPOC world
Series 90: Symbian OS based, PDA-centric (pen input), UI developed by Nokia
As you see, everything but Series 40 is Symbian-based. That means that applications which are UI-independent can be used across S60-S90. Otherwise, a UI adaption layer is necessary.
Within say Series 60, applications should in most cases be binary compatible between models from different vendors.
The naming scheme for Nokia cell phones is not helping here at all. It seems rather random to me, the only thing you can count on seems to be a zero at the end.
My problem is that Apple broke Bluetooth in a MAJOR way with 10.2.8, and with Panther right around the corner, it looks like it'll never get fixed. That's practically illegal- "we broke it, so just buy the update." Um, no- and as a result, I think I'll be downloading Panther, not buying it.
My thoughts exactly... the Bluetooth thing really sucks. Seems like they rushed it out because of the new keyboard and mouse and screwed it up for the rest of us. There's still the option to go back to 10.2.6, but I don't feel like going through a complete archive & install session...
Good question... I guess the current target for Nokia is to get out high number of WCDMA devices since that's what the operators want at the moment. For that reason, the specs probably won't be too different from other Series 40 devices. The first Series 60 WCDMA phones would be more interesting for me...
For breaching a patent you need to apply the exact same method wich is covered by the patent. So if XOR encoding would be patented, using XOR to decode could be a patent issue. But while RSA is patented(expired) you still can use(try)brute force decoding without patent infringement.
For things like RSA you're right. But as you said, if you have to implement a patented method for circumventing a DRM system, that's it (this covers not only encryption). Have you looked at CPRM? It's not the only system doing this... It's common practice in the DRM world.
But - there are DRM systems out there which stand on two legs: DMCA-like protection and patent protection. Meaning that if you circumvent it, you infringe on one or more patents (CPRM is such a case). At least that's the idea.
Anybody remember the viruses which could travel from floppy to floppy back in the C64 days? You would put an infected floppy next to a clean floppy, and the virus would just hop over! Don't know about the speed though...
(No kidding, there were people back then who told and believed this nonsense;)
I hope I get all the pieces correctly together... Paul McKenney was working on RCU for Dynix already at Sequent before they were bought by IBM. Dynix is a SVR4 licensed derivate, and if SCO claims are correct, SCO owns the IP to all SVR4 derivates, including code added by the licensee. The question is of course how the agreements between Sequent and SCO were affected after IBM bought Sequent.
What seems to be obvious to me is however that including RCU does not make Linux a derivate of SVR4, even if RCU were an integral part of SVR4. That would be very strange definition of derivative work... but you never know.
Well, at least the later models did. But you're probably correct, the earlier models up to the MP130 weren't Ive's design.
Re:GPL the best bet
on
OSI vs SCO
·
· Score: 4, Informative
There are four separate issues here: Trade secrets, NDAs, patents and copyrights. Trade secrets are nixed by revealing the source code, NDAs possibly also, copyright and patents however aren't.
If I distribute my application in source code form, I still have all copyrights associated with it. The GPL grants others some additional rights to redistribute which they otherwise wouldn't have, even if they had the source code.
Slashdot Mirror
I think what you meant to say was that any DRM which relies on security by obscurity can be broken by reverse engineering stuff like key generation or secure rights storage. DRM itself is not a secret thing which needs to be reverse engineered. As soon as somebody introduces an end-to-end secure solution à la Palladium, there's nothing to be reverse engineered. Rather, the game is then to find security holes.
Ok, it's not that I disagree totally, but I think you underestimate the work Apple already has done with porting Quicktime and also iTunes to Windows. In addition to that, I'm sure they can build on their experiences with their (admittely now historical) StarTrek porting efforts.
Did I say anything about X? No. Now even if we would talk about X, what in your valued opinion is the amount of code related to the UI in Carbon which would result in a from scratch port of almost the entire thing?
Also, I don't need to "realize" that Aqua is not related to X, that's not exactly news to me. Sheesh...
The only nightmarish thing about this is litte endian vs. big endian and maybe some Mach specific calls. The whole idea of Carbon was to make the Macintosh Toolbox portable so it could run on MacOS X.
So you take your JavaScript experience and come up with "JavaScript sucks, JavaScript uses prototyping, therefore prototyping sucks?" Or what other prototyping languages have you used?
Funny you say that. To quote from this article from the Petroleum News (admittedly older):
Briggs said NASA has been working with Halliburton, Shell, Baker-Hughes and the Los Alamos National Laboratory to identify drilling technologies that might work on Mars.
Halliburton and Baker-Hughes are working on some very advanced systems, Briggs said, some so advanced they aren't willing to talk much about them. He said the NASA Ames Center relies on working with people in the industry who "really understand the problems and make us face up to the realities
I think he tried SyllableOS but couldn't get it working. No idea how different it is nowadays from AtheOS.
Of course, you can still make analog dubs to your heart's content, so there's really not much motivation to crack it. Sure, it would be neat to get the MLP 24bit/96kHz stream onto your PC, but so few PC sound systems could do it justice.
;) - But still, the threat is there. And I wonder how much can be done via firmware upgrades. I.e. revoke a device class but offer a firmware upgrade. The question is probably who'll pay for all that nonsense. Probably the end user.
Agree to both points, but making analog copies is at the moment more work than just ripping. Once you got used to ripping or e.g. Kazaa, you don't really want to go back. Of course that's mostly a problem of setting up the right recording system/software.
I also think that the gamble was to get all new releases on DVD-A only, but that hasn't happened so far.
Do you think the Powers That Be would really utilize the revocation?
Honestly? No
Here's one for you: DVD Audio a.k.a CPPM. Out since 2000, not cracked yet, revocation of cracked devices possible.
I fully agree. Another analogy would be Windows drivers. I assume most of them do only work with Windows and were implemented with Windows in mind. But if you'd accept the notion that they are derived work of Windows because of this (as Linus argues for Linux drivers/kernel modules), then Microsoft would own their copyright (at least shared with the original author).
Somehow, this seems hard to believe. Or are there Microsoft copyright statements in non-Microsoft Windows drivers now? Can't check now since I've got no Windows machine here...
As I understand it, that's only necessary to develop games which are supposed to use the copy protection feature. Otherwise, you can just grab the Series60 SDK and start programming. I'm not sure however if there is any additional benefit in the N-Gage SDK such as 2D/3D or input APIs. But reading that the N-Gage games seem to also run on other Series60 devices, I'm sceptical about that.
As you see, everything but Series 40 is Symbian-based. That means that applications which are UI-independent can be used across S60-S90. Otherwise, a UI adaption layer is necessary.
Within say Series 60, applications should in most cases be binary compatible between models from different vendors.
The naming scheme for Nokia cell phones is not helping here at all. It seems rather random to me, the only thing you can count on seems to be a zero at the end.
One thing for example is that the Acer BT-500 USB Dongle doesn't work anymore. It used to work with 10.2.6.
My thoughts exactly... the Bluetooth thing really sucks. Seems like they rushed it out because of the new keyboard and mouse and screwed it up for the rest of us. There's still the option to go back to 10.2.6, but I don't feel like going through a complete archive & install session...
Good question... I guess the current target for Nokia is to get out high number of WCDMA devices since that's what the operators want at the moment. For that reason, the specs probably won't be too different from other Series 40 devices. The first Series 60 WCDMA phones would be more interesting for me...
No.
The 3650 and 7600 are quite different. The 3650 is a Series 60 (Symbian OS) device, the 7600 is a Series 40 (Nokia proprietary OS) device.
For breaching a patent you need to apply the exact same method wich is covered by the patent. So if XOR encoding would be patented, using XOR to decode could be a patent issue. But while RSA is patented(expired) you still can use(try)brute force decoding without patent infringement.
For things like RSA you're right. But as you said, if you have to implement a patented method for circumventing a DRM system, that's it (this covers not only encryption). Have you looked at CPRM? It's not the only system doing this... It's common practice in the DRM world.
But - there are DRM systems out there which stand on two legs: DMCA-like protection and patent protection. Meaning that if you circumvent it, you infringe on one or more patents (CPRM is such a case). At least that's the idea.
Anybody remember the viruses which could travel from floppy to floppy back in the C64 days? You would put an infected floppy next to a clean floppy, and the virus would just hop over! Don't know about the speed though...
;)
(No kidding, there were people back then who told and believed this nonsense
I hope I get all the pieces correctly together... Paul McKenney was working on RCU for Dynix already at Sequent before they were bought by IBM. Dynix is a SVR4 licensed derivate, and if SCO claims are correct, SCO owns the IP to all SVR4 derivates, including code added by the licensee. The question is of course how the agreements between Sequent and SCO were affected after IBM bought Sequent.
What seems to be obvious to me is however that including RCU does not make Linux a derivate of SVR4, even if RCU were an integral part of SVR4. That would be very strange definition of derivative work... but you never know.
Eiffel is, or are you concerned about possible IP problems with the language spec per se?
take the best aspects of java, objective-c, eiffel and maybe some smalltalk like elements and roll them up into one language.
The D programming language looks somehow interesting...
Here you go.
...didn't have [...] Ive's design
Well, at least the later models did. But you're probably correct, the earlier models up to the MP130 weren't Ive's design.
There are four separate issues here: Trade secrets, NDAs, patents and copyrights. Trade secrets are nixed by revealing the source code, NDAs possibly also, copyright and patents however aren't.
If I distribute my application in source code form, I still have all copyrights associated with it. The GPL grants others some additional rights to redistribute which they otherwise wouldn't have, even if they had the source code.