While I could easily strip the DRM off the WMA files (assuming they use a current-gen version of WMA, which we don't know), that would take too much effort on my part to make it worth the money.
Um, how? Last I checked, WMDRM10 had not been cracked for nearly a year. And, the last crack that came out didn't let you strip the DRM from any old file, you had to own a license to it first.
I meant it was temporary in that the unofficial patch was temporary. This kind of in-memory patching of binary code is absolutely not common, nor to be encouraged. It's a 5 day fix type thing and is needed (and possible!) so rarely that writing off an entire infrastructure because of it would IMHO be silly.
That whole post is based on a series of far-fetched theories and misconceptions.
It's very unlikely Windows will ever try to stop you running "unauthorized code" - what is the definition of such a thing? How can Windows possibly tell the difference between a 3rd party application and something that would be "unauthorized". Windows doesn't even try to prevent you installing unsigned drivers. Buffer overflows are already the domain of things like execshield and DEP, and obviously there are no legitimate uses for buffer overflows (or not very many anyway).
ISPs may or may not block people from their networks who have modified system files, but as such a thing is typically pretty good evidence of a rootkit or trojan I would not be surprised if many did so. What - you think the net should continue to be flooded by spam and viruses because you want the ability to perform binary patching of the OS? If so, then go use a hacker friendly ISP who replaces automated TPM based checks with human monitoring of traffic flow. That's more expensive, but more flexible. 99% of people won't need it and would be better off with fully automated checks.
Yes, the TPM can absolutely block many types of game cheats, because it can be used to prove to a remote server that you aren't trying to interfere with the game in some way (by screwing about with drivers and such).
I wonder how much of the load they're spilling out onto new hardware would be reduced if MediaWiki was written in C++ instead of PHP? I know they use bytecode caching, but still, there's a huge difference between running optimized native code and a bytecode interpreter.
I completely agree it's not mine to copy, but it will become mine pretty damned quickly if I scratch it. And I bet I would be charged the full game price as a replacement. Maybe the rental company should have backups. Kind of makes me nervous about renting games now.
It'll only become yours if the rental company is badly run and doesn't care about customer loyalty - a smart rental agency that has this problem will do what GameFly are doing and only charge you if you repeatedly rent disks that you know may get scratched by your defective hardware. And if they are charging the full price of the game, then they need to look at their own management or suppliers.
I really love how a simple hardware/economics problem has been turned into "DRM is evil" by the Slashdot crowd here. As if renting games would make economic sense without copy protection (even a leaky form) - it would become equivalent to simply buying the game, but at a fraction of the original price.
..that if we all were running "trustworthy" computers, this problem would be much, much worse than it is now. Imagine that now instead of having a patch that's already been made by someone else while we sit and wait for Microsoft to get off their asses, we now have to wait on Microsoft, who still hasn't shown up.
Huh? I am not aware of any current implementations of "trustworthy computing" that would prevent you applying this sort of patch. The TPM chip and the like simply let you prove things about the configuration of your computer to other computers (and lock data to a particular machine) - by all means, go wild, do whatever you want to your own computer. Just don't expect to then be able to lie about it to others.
If you then rely on others for various things who refuse to trust you because you're loading patch DLLs into every process then you may have a problem yes, but this is only temporary and the benign applications of such a technology (death to game cheaters!) IMHO outweigh the very slight theoretical risks.
WMF is a very old image format and dates from the time of Windows 3.1 and earlier. In other words, it dates from a time before the web and the idea that people would be transmitting malicious image files around was foreign. The idea that programs would routinely display thousands of images every day from potentially untrusted sources was also alien (remember most PCs were in business at this time not at home). So I can't really blame them for not forseeing this over 10 years ago, nobody did really.
Remember that even very modern "data" formats like HTML allow you to embed code into them.
That list of requirements at the end interests me. I'd consider myself a reasonable C/C++ programmer and a good general programmer (my experience is fairly widespread across languages, tools and platforms right now), but I've never needed to reverse a linked list in-place, by which I assume you mean in an allocation-free manner. I've seen code that can do it using XOR swaps and such but I'd never choose such a method over a clearer, more verbose system unless reversing that list happened to be a huge performance hotspot.
Likewise, I have no idea what a "scatter gather DMA transfer" is, but to me DMA is something the operating system deals with and as I've never written driver code (read it, not written in) I'd be lost as to why such a thing is bad.
Perhaps it's more that most C/C++ programmers don't know the quirks of safety-critical avionics programming?
Briefly, the argument was "20mb of memory overhead is not acceptable for an applet", as they are expected to run all the time. Personally I'd find 20mb of overhead for a very simple program to be unacceptable nearly all the time, as the developer can't know if the user will keep it running or not.
No, it's not at all like stack allocation. It's an order of magnitude better.
Can you justify that please? Stack allocation has many performance benefits - it's only an instruction of two to allocate or deallocate memory, and the stack is usually hot in the cache.
And once you've tasted refcounted objects, you don't want to look back (I wonder how I could survive all these years of C++ without them built in the language).
It's certainly not hard to add refcounted objects to C++ using smart pointers and the like, it's a very common technique.
Oh sure, I'm not saying GC should always be used for everything. There are places where it's not appropriate. But, in nearly all the places Objective-C is appropriate I'd say GC is appropriate.
Look at the arguments over the inclusion of the gnome launch toolbar a few months ago on desktop-devel-list to see an example of why Python really isn't suitable for desktop applications, C or no C.
You've clearly never attempted to migrate a large business from Windows to Linux.
Neither have I for that matter, but I've seen inside some of the largest (and most secret) migrations around. It isn't pretty. If you think there's magically no lockin now then you're dreaming.
Oh, and it's not like the Mac will save anybody. If you want to change who you're locked in to from one big company full of control-freaks with a vision to another big company full of control freaks with a vision then you're welcome, but I'd save myself the pain.
I've tried PAQ before and it can achieve good results, especially for text, but given the extremely slow nature of the algorithm I judged it not a good enough improvement over LZMA for the autopackage installers.
Still, worth remembering, especially as these algorithms are being improved all the time.
msgc_ObjSend without the GCC 4.0 optimization is 22 cycles. Somehow I doubt that's really your big performance issue.
The expensive part is not so much the function itself, it's the jump into the standard runtime library. Dynamic linking always imposes overhead for inter-library function calls, however the best implementations reduce it to an instruction or so in the best case (for ELF after lazy linking is complete, it's basically one jump opcode). Unfortunately MachO is not a terribly well designed format and the cost of an inter-library jump is far higher there, so the cost of an Objective-C method call is actually not only the instructions inside msgc_ObjSend (or whatever it's called) but also the time required to get there and back.
The single selling point with Objective-C / Cocoa is the NSAutoreleasePool mechanism. This mechanism is like a garbage collector finally done right.
I must strongly disagree. In no sense is the auto-release pool equivalent to garbage collection. For one, you still have to think hard about memory management in any complex application - for temporary objects that are just part of the internal works of a function, they work OK, but then stack allocation works better. For actually passing objects around inside a program they don't work at all and you must still manage refcounting and ensure there are no refcount cycles.
For those who have not encountered this particular construct (which is not unique to Cocoa), an NSAutoreleasePool basically keeps memory around until the main loop is reached. So you can allocate objects inside one and not worry about freeing them, as long as they don't have to survive beyond this particular event. It's a bit more involved than that : there are stacks of them, and you can create them and flush them manually outside the context of a GUI thread. But it's a bit of a cludge and not a substitute for full automatic memory management (though I would agree that a language which forces you to use GC for everything is not suitable for implementing desktop applications).
On UNIX systems at least the LZMA codec is excellent - it regularly achieves better ratios than bzip2, and is very fast to decompress. For many applications, decompression speed is more important than compression speed and the LZMA dictionary appears to fit inside the CPU cache, as it beats out bzip2 handily even though it's doing more work.
There are better compressors out there, in particular PPM codecs can achieve spectacular ratios, but as they're very slow to both compress and decompress they're useful mostly for archiving.
I've also seen great results from codecs tuned specifically to certain types of data over others, for instance, a PPM codec designed specifically for Intel x86 executable code can work wonders.
Ref-counting definitely has a performance impact, except it's a "death by a thousand cuts" type impact which is difficult to measure, so people don't, and they end up with this warm fuzzy feeling that it's free relative to GC.
I've looked at Cocoa, briefly, because I have a Mac-nut friend who wanted to learn programming. So he downloaded their tutorial. Oh my god, I have never seen such a convoluted tutorial in all my life. And Obj-C the language is far from "perfect" in my eyes: combine all the faults of C with the weird syntax of Smalltalk, along with a horrifically slow implementation (Mach-O inter-library jump for every method call!), and you get something that whilst it has many virtues is far from being perfect.
But it doesn't surprise me Jobs has such a bizarre attitude. The man IS bizarre, a study in contradictions. He clearly hasn't done much programming himself in the last 10 years if he truly believes Cocoa is state of the art, and the dropping of Java/Cocoa support in recent OS X releases can only be a side-effect of this warped worldview. But what do you expect from "visionary" billionaires?
Of course it isn't as simple as that. If it was, everybody would use Ruby or Python for everything and Java/C#/C++ would be dead.
In practice, strong typing and the lack of Ruby-style dynamism allows compilers and runtimes to make optimizations they otherwise couldn't. Those matter, a lot, try looking at the memory usage or execution speed of your average Ruby program sometime! Worse, it's an unfixable problem, at least without modifying the language itself quite heavily.
I think the way we're going to go with language design, as an industry, is more like Boo - a language which on the surface looks like Python and has many of the clarity and programmer efficiency features that make Python so much fun to use, but under the hood is actually a traditional strong/static typed language. In Boo, type inference is used to let you drop many of the redundant type declarations that normally clutter up Java/C#/C++ style code, and a smart compiler plugin system is used to let you add new features to the language easily. This is traded off against the ability to do things like add/remove methods at runtime which are hard to implement in a time/space efficient manner.
Video drivers can use DMA to write to kernel memory space however - apart from a few accounting tricks the idea that they are fully "userland" is incorrect as they have full system access and can load arbitrary code into the kernel at any time.
However, Linux as a system is stupid enough that installing packaged software requires root - always. Whether you futz around at install time or first run time is a bit irrelevant really.
One of the biggest complaints about Windows security is that it's hard to not run as administrator because so many programs require it to install, yet this is a guaranteed "feature" of Linux: WTF?
It's worth noting that figuring out a disk image format is a million years away from breaking Xbox 360 security. Nobody should read much into this.
There will be always more clever people out there then those employed in various corporations...
Yeah, that's what I used to think as well. These days I think differently.
Sure, the world is full of clever people. However, the clever people who work for the technology companies have several advantages over those that don't:
They work full time. In terms of sheer man-hours the tech companies can throw at the problem, Joe Randoms in their bedrooms will always lose.
They work together. The internet is great but a mailing list and IRC channel for people in 12 different timezones is no substitute for a well equipped set of offices and labs where everybody works together every day.
They have access to advanced equipment most other people don't. For instance, fully reverse engineering smart cards is very hard because you need tools that can be difficult to get hold of (eg, SEMs)
They have (almost) unlimited financial resources, so they can buy the work and brainpower of other smart people
I think people have been misled by the ease of breaking pure software copy protection on x86 computers. Compared to dealing with custom hardware like the Xbox pure software solutions are very easy to attack because many people have the required tools and knowledge (typically a debugger and fluency in assembly). Comparitively few people have tools to look inside microchips and figure out what they're doing - and of course, physical things are far harder to change than software which is just a series of numbers.
And even then, it's possible to make very tough to crack pure software solutions if you get enough smart people on the problem. For instance, Windows Media DRM has had remarkably few exploits given how high profile it is: the last was back in January IIRC and it was rapidly patched (so it no longer worked after a few weeks). Even then that crack didn't let you decrypt any arbitrary file: you had to actually purchase a license first. The current generation has remained uncracked for nearly a year.
For games, some programs protected with StarForce encryption have never been cracked (and some have, but StarForce lets the developers decide how much effort they'll put into protecting their software so that's not really surprising).
Anyway, if you look at the actual technical details of how things like Xbox and DVD protection were cracked, they mostly relied on massive flukes that were only found after years of searching and typically a 3rd party had to screw up somewhere first. With each successive generation of these technologies they've been iteratively improved and I see no reason why console protection won't follow the same path DirecTV/NDS satellite security followed: a few generations in, no more cracks have become available even after many years and despite the potential profit.
Slashdot Mirror
Um, how? Last I checked, WMDRM10 had not been cracked for nearly a year. And, the last crack that came out didn't let you strip the DRM from any old file, you had to own a license to it first.
I meant it was temporary in that the unofficial patch was temporary. This kind of in-memory patching of binary code is absolutely not common, nor to be encouraged. It's a 5 day fix type thing and is needed (and possible!) so rarely that writing off an entire infrastructure because of it would IMHO be silly.
I wonder how much of the load they're spilling out onto new hardware would be reduced if MediaWiki was written in C++ instead of PHP? I know they use bytecode caching, but still, there's a huge difference between running optimized native code and a bytecode interpreter.
It'll only become yours if the rental company is badly run and doesn't care about customer loyalty - a smart rental agency that has this problem will do what GameFly are doing and only charge you if you repeatedly rent disks that you know may get scratched by your defective hardware. And if they are charging the full price of the game, then they need to look at their own management or suppliers.
I really love how a simple hardware/economics problem has been turned into "DRM is evil" by the Slashdot crowd here. As if renting games would make economic sense without copy protection (even a leaky form) - it would become equivalent to simply buying the game, but at a fraction of the original price.
Huh? I am not aware of any current implementations of "trustworthy computing" that would prevent you applying this sort of patch. The TPM chip and the like simply let you prove things about the configuration of your computer to other computers (and lock data to a particular machine) - by all means, go wild, do whatever you want to your own computer. Just don't expect to then be able to lie about it to others.
If you then rely on others for various things who refuse to trust you because you're loading patch DLLs into every process then you may have a problem yes, but this is only temporary and the benign applications of such a technology (death to game cheaters!) IMHO outweigh the very slight theoretical risks.
Remember that even very modern "data" formats like HTML allow you to embed code into them.
Likewise, I have no idea what a "scatter gather DMA transfer" is, but to me DMA is something the operating system deals with and as I've never written driver code (read it, not written in) I'd be lost as to why such a thing is bad.
Perhaps it's more that most C/C++ programmers don't know the quirks of safety-critical avionics programming?
Briefly, the argument was "20mb of memory overhead is not acceptable for an applet", as they are expected to run all the time. Personally I'd find 20mb of overhead for a very simple program to be unacceptable nearly all the time, as the developer can't know if the user will keep it running or not.
Can you justify that please? Stack allocation has many performance benefits - it's only an instruction of two to allocate or deallocate memory, and the stack is usually hot in the cache.
It's certainly not hard to add refcounted objects to C++ using smart pointers and the like, it's a very common technique.
Oh sure, I'm not saying GC should always be used for everything. There are places where it's not appropriate. But, in nearly all the places Objective-C is appropriate I'd say GC is appropriate.
Look at the arguments over the inclusion of the gnome launch toolbar a few months ago on desktop-devel-list to see an example of why Python really isn't suitable for desktop applications, C or no C.
Neither have I for that matter, but I've seen inside some of the largest (and most secret) migrations around. It isn't pretty. If you think there's magically no lockin now then you're dreaming.
Oh, and it's not like the Mac will save anybody. If you want to change who you're locked in to from one big company full of control-freaks with a vision to another big company full of control freaks with a vision then you're welcome, but I'd save myself the pain.
Still, worth remembering, especially as these algorithms are being improved all the time.
The expensive part is not so much the function itself, it's the jump into the standard runtime library. Dynamic linking always imposes overhead for inter-library function calls, however the best implementations reduce it to an instruction or so in the best case (for ELF after lazy linking is complete, it's basically one jump opcode). Unfortunately MachO is not a terribly well designed format and the cost of an inter-library jump is far higher there, so the cost of an Objective-C method call is actually not only the instructions inside msgc_ObjSend (or whatever it's called) but also the time required to get there and back.
I must strongly disagree. In no sense is the auto-release pool equivalent to garbage collection. For one, you still have to think hard about memory management in any complex application - for temporary objects that are just part of the internal works of a function, they work OK, but then stack allocation works better. For actually passing objects around inside a program they don't work at all and you must still manage refcounting and ensure there are no refcount cycles.
For those who have not encountered this particular construct (which is not unique to Cocoa), an NSAutoreleasePool basically keeps memory around until the main loop is reached. So you can allocate objects inside one and not worry about freeing them, as long as they don't have to survive beyond this particular event. It's a bit more involved than that : there are stacks of them, and you can create them and flush them manually outside the context of a GUI thread. But it's a bit of a cludge and not a substitute for full automatic memory management (though I would agree that a language which forces you to use GC for everything is not suitable for implementing desktop applications).
There are better compressors out there, in particular PPM codecs can achieve spectacular ratios, but as they're very slow to both compress and decompress they're useful mostly for archiving.
I've also seen great results from codecs tuned specifically to certain types of data over others, for instance, a PPM codec designed specifically for Intel x86 executable code can work wonders.
I've looked at Cocoa, briefly, because I have a Mac-nut friend who wanted to learn programming. So he downloaded their tutorial. Oh my god, I have never seen such a convoluted tutorial in all my life. And Obj-C the language is far from "perfect" in my eyes: combine all the faults of C with the weird syntax of Smalltalk, along with a horrifically slow implementation (Mach-O inter-library jump for every method call!), and you get something that whilst it has many virtues is far from being perfect.
But it doesn't surprise me Jobs has such a bizarre attitude. The man IS bizarre, a study in contradictions. He clearly hasn't done much programming himself in the last 10 years if he truly believes Cocoa is state of the art, and the dropping of Java/Cocoa support in recent OS X releases can only be a side-effect of this warped worldview. But what do you expect from "visionary" billionaires?
I doubt it - for one, bridging languages like that always has a friction cost, and for another, Objective-C isn't really that fast either ;)
ShedSkin compiles a language very similar but not equal to Python. It adds some restrictions.
In practice, strong typing and the lack of Ruby-style dynamism allows compilers and runtimes to make optimizations they otherwise couldn't. Those matter, a lot, try looking at the memory usage or execution speed of your average Ruby program sometime! Worse, it's an unfixable problem, at least without modifying the language itself quite heavily.
I think the way we're going to go with language design, as an industry, is more like Boo - a language which on the surface looks like Python and has many of the clarity and programmer efficiency features that make Python so much fun to use, but under the hood is actually a traditional strong/static typed language. In Boo, type inference is used to let you drop many of the redundant type declarations that normally clutter up Java/C#/C++ style code, and a smart compiler plugin system is used to let you add new features to the language easily. This is traded off against the ability to do things like add/remove methods at runtime which are hard to implement in a time/space efficient manner.
Video drivers can use DMA to write to kernel memory space however - apart from a few accounting tricks the idea that they are fully "userland" is incorrect as they have full system access and can load arbitrary code into the kernel at any time.
Most people don't even know they have a MAC address, let alone how to change it. So no, it's not really 'easy'.
One of the biggest complaints about Windows security is that it's hard to not run as administrator because so many programs require it to install, yet this is a guaranteed "feature" of Linux: WTF?
There will be always more clever people out there then those employed in various corporations...
Yeah, that's what I used to think as well. These days I think differently.
Sure, the world is full of clever people. However, the clever people who work for the technology companies have several advantages over those that don't:
I think people have been misled by the ease of breaking pure software copy protection on x86 computers. Compared to dealing with custom hardware like the Xbox pure software solutions are very easy to attack because many people have the required tools and knowledge (typically a debugger and fluency in assembly). Comparitively few people have tools to look inside microchips and figure out what they're doing - and of course, physical things are far harder to change than software which is just a series of numbers.
And even then, it's possible to make very tough to crack pure software solutions if you get enough smart people on the problem. For instance, Windows Media DRM has had remarkably few exploits given how high profile it is: the last was back in January IIRC and it was rapidly patched (so it no longer worked after a few weeks). Even then that crack didn't let you decrypt any arbitrary file: you had to actually purchase a license first. The current generation has remained uncracked for nearly a year.
For games, some programs protected with StarForce encryption have never been cracked (and some have, but StarForce lets the developers decide how much effort they'll put into protecting their software so that's not really surprising).
Anyway, if you look at the actual technical details of how things like Xbox and DVD protection were cracked, they mostly relied on massive flukes that were only found after years of searching and typically a 3rd party had to screw up somewhere first. With each successive generation of these technologies they've been iteratively improved and I see no reason why console protection won't follow the same path DirecTV/NDS satellite security followed: a few generations in, no more cracks have become available even after many years and despite the potential profit.