The problem is that it disperses the rare elements in the trash where they can't be recovered. One day we'll want to mine landfills for raw materials and burning it means we won't be able to.
When software or hardware are used to take control of a computer away from that computer's owner bad things will happen.
... on an article about viruses. Yes well done, +1 Insightful. Never mind that trusted computing != DRM and that the most common use of TC is for security software, doh.
Yeah but I'm not convinced that'll last. I mean the "visibility" you get from the App Store is only really possible because it's still quite small. Imagine if there was a million apps in the app store, the UI would rapidly become a hinderance rather than a help. Most apps would instantly vanish into obscurity with no way to advertise themselves, except via the web, word of mouth etc, in which case there's not much advantage over just selling your app on your website as is done today for WM software. App Store works great today but I am skeptical about its scalability.
Why? It's a drive by download against some unnamed browser (probably but not definitely IE). You don't have to visit shady sites to get those - these days they hack poorly protected legitimate sites and embed the exploit code into otherwise harmless pages.
I'm 24 too. Don't worry, you'll get over the Ron Paul phase. Took me about a week - ended around the time I read some of the things he actually said, instead of the lofty philosophies his fans assigned to him.
Probably because Joe the Plumber was such a great story. A guy who rabidly supports McCain apparently because as an aspiring business owner, he'd lose under Obamas tax plan. Except that he's not a plumber, is nowhere near owning his own business, would actually get a tax cut under Obamas plan and that's just as well - he's in tax deficit anyway! Meanwhile McCain and Palin are moronically promoting this guy as some kind of symbol.
Is it any wonder the press loved that story? It's just so entertaining.
Sorry, I forgot something whilst doing the calculations. Yahoo said that's what they handled in 2004 and that they want to be ready for 3x that last year. So for their homepage alone they'd need about 384,000 hits/sec of capacity. That's just the Yahoo home page, and ignores clickthroughs to other parts of the site. It does assume everybody hits the site on a cold cache though. Most likely a lot of those users are Yahoo regulars and they'll only have to load 7 or 8 files instead of 32. So actual traffic won't be as high as that.
142 million visits in one day is about ~1640 visits per second. However, traffic isn't distributed evenly - typically peak is twice that of average. So they need to be provisioned to handle ~3287 visits per second.
They'll also want some headroom to ensure they can still serve in case of hardware failure, so let's imagine they provision for 4000 visits/second.
The Yahoo homepage, at least for me, triggers about 32 file loads on a cold cache, so that's a peak hits per second of about 128,000.
The trick is not, did sales grow? It's what was the derivative of the growth. If sales were growing at a steady 10% a year and the year CSS was cracked it dropped to a steady 3% growth, sales still grew the year it was cracked, but it's fair to assume not as much. But I don't have those figures - can you cite?
The whole point of BD+ is to change that, because player manufacturers have a built-in incentive to produce weak protection. The idea is to let the studios decide how much to invest in protection.
By this theory, you should see DVD sales drop to nothing almost instantaneously.
Even if Blu-Ray copy protection were as utterly broken as DVD copy protection is, the disks would still sell fine.
If you read what I wrote more carefully, you'll see it says "sharp drop" not "drop to nothingness". Obviously there are always some people who will buy the discs. The question is how many sales did you lose because obtaining a free copy became so easy. By the way, your belief that without DRM the discs would sell "fine" is pretty weak - who decides what "fine" is? You know most movies lose money and are subsidised by the blockbusters, right?
I'm surprised this even still comes up. By definition sales fall when copy protection is cracked, otherwise nobody would bother developing it in the first place. A system like BD+ isn't cheap to create or maintain so I'd imagine the losses are significant.
Unless you actually believe all the executives at all the movie studios and their major shareholders are so stupid they can't read a graph, of course. In which case I don't know what to say... none of us here have the information needed to know the economics of BD+ or similar systems but it's reasonable to infer the entire industry isn't staffed by financial illiterates, otherwise movies would never get made at all.
I agree that the BD group may eventually be backed into a corner over software players, at which point it'll boil down to pure economics. I read that the vast majority of BluRay players in the world are PS3, although of course, that doesn't mean the vast majority of used BR players are PS3s.
I honestly have no idea what proportion of BluRay watchers watch via their PCs, but the equation is simple - take a graph of disc sales. Presumably at some point its BD+ program is cracked and sales will fall as high quality rips show up on the internet - I'd imagine the graph looks like a sharp rise upwards on release week followed by a gradual decay into nothingness over time, with a sharp drop around the time the BD+ program is cracked (assuming it lasts long enough that you can even get a sales baseline, ie, not within a few days).
Now let's say 10% of BluRay watchers use a PC, so reduce your project sales by 10% but remove the sharp drop due to piracy, take the integral of both graphs and see if the difference is positive. If it's big enough it might be worth abandoning PC playback to avoid the piracy (or shift that sales cliff to a point where sales were low anyway).
If the economics don't look like that, then the BD group needs to try and get PowerDVD and friends seriously buffed up, security wise. It's certainly possible to make x86 code annoying and difficult to reverse engineer, but very few people can do it well. I'd imagine most of them don't work for BluRay player software companies.
I'd be very interested in a chart of every BluRay title released and when it was cracked, but I doubt such information is publically available.
Yes I know. What I meant was, what proportion of BluRay watching people watch the movies on their laptops or desktops, vs a dedicated hardware player or PS3. And yes I expect the PS3 does a lot of it in software too. Point is, I also expect tracing the BD+ VM in a PS3 to be quite hard.
The differences between Linux distros are big enough to annoy programmers with better things to do, but small enough that you can still write a virus that works on all of them if you want to. So it's actually the worst of all possible worlds.
As far as I can tell, it wasn't actually disabled though. What they guy did is write his own BD+ VM. An impressive feat for sure, but that attack was always anticipated. As the dude says later,
Apart from that the purpose of the program (called "content code") running inside the player on a virtual machine is to detect any known compromised players or known unlicensed emulators (like ours). The content code is give a wide range of opportunities to do that. For example it has (limited) access to the player memory and can even execute arbitrary code on the machine though we haven't seen that yet and our emulator doesn't support this either. As long as we have access to a working (licensed) players all these measures are useless as we can record traces from this player and adjust the data "injected" in the virtual machine address space by traps or events to perfectly match our recordings. Even if whitebox attack resistant AES or ECDSA algorithms are used and nobody manages to break them we can still use the obfuscated algorithms and their keys.
So basically the disk authors can keep up for as long as they can trace the VM of an existing licensed player. They don't need to do that currently because no publishers are searching for their VM specifically.
They'll probably be able to do this for as long as publishers want their discs to be playable on software players, simply because it's quite easy to reverse engineer x86 code on a PC, when you have a debugger and plenty of Jolt. I don't know what the BluRay player market looks like. If most BluRay players are hardware based, then as a movie studio I'd be tempted to simply write some BD+ code that looked for existing software players and banned all of them. Then the "trace a licensed player" step outlined above suddenly turns into a silicon reverse engineering problem instead of a software reverse engineering problem. Much harder.
That said, I doubt they'd actually do that. Presumably they allowed software players for a reason, despite knowing they were way easier to hack than hardware players.
You've just explained why Python on a phone is a dumb idea. Have you ever looked at the memory usage of a Python program? Java is bad but Python is absolutely insane. For the longest time (and perhaps this is still true) the Python interpreter just never released memory back to the OS once it had been allocated. That's how much they cared about memory usage.
Here's a few more reasons why Python would be an awful language to develop phone software in. The Python interpreter doesn't "do" multi-threading. It's easier to use Python APIs mistakenly because there's no explicit typing. There's no good IDE for Python, but Eclipse rocks.
You mentioned that Python is appropriate because "for everything performance-critical it uses libraries written in C". So does Android - I suggest you read the code, you'll find that anything CPU intensive is written in C++ or C.
I can't actually think of a worse language for a cell phone than Python, which is not only extremely poor CPU wise, but also memory wise. Actually there are only a few tasks Python is really appropriate for (and I say that as somebody who gets paid to write Python programs every day) - for any codebase of a significant size, there are better tools. Android is a pretty giant codebase.
Yeah there's some pretty weak justifications given for their policies here, but there's also a lot of people pointing out how dumb that is. You included. And your "karma killer" post is at +4 currently, so you should give Slashdotters more credit...
Yes indeed. A little known fact about the UK is that it pays less for drugs than most other countries, because it negotiates collectively on the behalf of 60 million people.
Such is the effectiveness of the nationally co-ordinated generic contracting process, that the prices offered can occasionally be driven too low, which can force suppliers out of the market or make the market unattractive for new entrants. The national Pharmaceutical Market Support Group (PMSG) has systems in place that aim to ensure that a sufficient number of suppliers are in the market for each product and that competition is fair and appropriate.
Because I have a right to my income and property and would rather not pay into an inefficient, unsustainable system.
Argh. Where does this idea that the public sector is inherently less efficient and good than the private sector come from?
Efficiency and competency are not magically grown by acting in a market. All a market does is impose a lower bound on inefficiency and incompetency. In a perfectly functioning free market the smallest improvement by any participant has to be matched by all the participants, so there's a gradual progression upwards. Unfortunately many (most?) markets function poorly. Barriers to entry, over or under regulation, too few competitors or too many, lack of information... whatever the cause, there's a massive gulf between practice and theory.
Look at mobile phone companies if you don't believe me. Have you ever been with a cellular company that didn't have atrocious customer service, rampant incompetence and all kinds of stupid problems? I never have. That's because the market has huge barriers to entry and so there isn't much competition. The few companies that do exist stagnate and nothing gets better until some external party forces it (eg Apple with the AT&T deal or the EU with roaming charges).
Now consider the NHS. It is very much in competition with private health companies - if the NHS failed completely, people would go to the private sector despite the cost, and any politician who ran on a manifesto of shutting it down would win. This doesn't happen because the NHS is not a disaster, not even close.
A great organization comes from having smart, knowledgable, well motivated staff who have the resources they need to get things done. Period. End of story. You can use a (well run) market and hope that people get a choice of such a company, thus forcing improvement or death on the others - or you can vote in politicians who'll go in and make sure the people are good and the resources are available. Both solutions work in a theoretical work, and both sometimes fail in the real world. But ultimately they are two means to the same end.
Huh what? I think you're confusing the Objective-C shipped with Leopard, which does (finally) do GC, with the Objective-C you have to use in the iPhone which apparently does not. That's pretty shocking. I had no idea the iPhone SDK was that far behind but it appears to be true.
It's pretty ballsy to ask developers to do phone development without a GC these days. Manual memory management is just pain for users and developers. I guess the lack of multi-tasking makes memory leaks less of an issue because apps won't live very long, but on Android it'd be essential - you don't want the system to be constantly recycling leaky apps. You especially don't want apps to crash because they double-freed an allocation.
If you build your hardware in a country notorious for having shadow shifts at factories, and then give away your source code as well, what makes you think there'd be any market left for your products?
If ODF becomes a re-implementation of OOXML, who is going to use ODF?
The real question is, if ODF doesn't become a re-implementation of OOXML, who is going to use it?
I think a lot of people are struggling with a painful but unavoidable truth - ODF does not matter, has never mattered and never will matter. The vast, vast, vast majority of spreadsheets today are produced using Excel, which has a long history as a program and has at various times had bugs and defects introduced into its calculation engine. People went on to produce millions of business documents that either rely on these bugs, or work around them such that they will break if the bugs are fixed.
Microsoft, PR wise, are in a lose-lose situation here. Either they can request that ODF has a way to express some of these bugs, and be able to reliably export Excel documents to it. Or they can leave ODF "pure" and "clean" and implement an exporter that subtly mangles documents such that they appear to work but produce incorrect answers. The latter is probably a good way to get sued and would certainly result in a shit-storm of "Microsoft makes deliberately buggy code to discredit ODF", but the former is a good way to ALSO get a PR disaster of "Microsoft dictates direction of open standards".
I'd really like to see more competition and better compatibility in the office suite world, but to be completely honest if I was a program manager for Excel at Microsoft I'd be very tempted to walk away from the whole standardisation process. I'd publish precise documentation for the binary formats (which they've done) and then leave it. No slow XML formats. No stupid attempts to pretend that the StarOffice spreadsheet format can be some kind of international standard when the actual, de facto standard is.XLS, warts and all. No lose-lose PR situations. Publish the bugs so other companies can be compatible with the 800 pound gorilla, and that goes far enough.
Slashdot Mirror
Yeah, Monty Python was OK, but for even tighter Brit humour you want to watch Brass Eye.
The problem is that it disperses the rare elements in the trash where they can't be recovered. One day we'll want to mine landfills for raw materials and burning it means we won't be able to.
You can skip the tutorial from the menu. Useful if you want to practice the demo level a bit. It was fun, I'm definitely buying the game.
lol,
... on an article about viruses. Yes well done, +1 Insightful. Never mind that trusted computing != DRM and that the most common use of TC is for security software, doh.
Yeah but I'm not convinced that'll last. I mean the "visibility" you get from the App Store is only really possible because it's still quite small. Imagine if there was a million apps in the app store, the UI would rapidly become a hinderance rather than a help. Most apps would instantly vanish into obscurity with no way to advertise themselves, except via the web, word of mouth etc, in which case there's not much advantage over just selling your app on your website as is done today for WM software. App Store works great today but I am skeptical about its scalability.
Why? It's a drive by download against some unnamed browser (probably but not definitely IE). You don't have to visit shady sites to get those - these days they hack poorly protected legitimate sites and embed the exploit code into otherwise harmless pages.
I'm 24 too. Don't worry, you'll get over the Ron Paul phase. Took me about a week - ended around the time I read some of the things he actually said, instead of the lofty philosophies his fans assigned to him.
Probably because Joe the Plumber was such a great story. A guy who rabidly supports McCain apparently because as an aspiring business owner, he'd lose under Obamas tax plan. Except that he's not a plumber, is nowhere near owning his own business, would actually get a tax cut under Obamas plan and that's just as well - he's in tax deficit anyway! Meanwhile McCain and Palin are moronically promoting this guy as some kind of symbol.
Is it any wonder the press loved that story? It's just so entertaining.
Sorry, I forgot something whilst doing the calculations. Yahoo said that's what they handled in 2004 and that they want to be ready for 3x that last year. So for their homepage alone they'd need about 384,000 hits/sec of capacity. That's just the Yahoo home page, and ignores clickthroughs to other parts of the site. It does assume everybody hits the site on a cold cache though. Most likely a lot of those users are Yahoo regulars and they'll only have to load 7 or 8 files instead of 32. So actual traffic won't be as high as that.
142 million visits in one day is about ~1640 visits per second. However, traffic isn't distributed evenly - typically peak is twice that of average. So they need to be provisioned to handle ~3287 visits per second.
They'll also want some headroom to ensure they can still serve in case of hardware failure, so let's imagine they provision for 4000 visits/second.
The Yahoo homepage, at least for me, triggers about 32 file loads on a cold cache, so that's a peak hits per second of about 128,000.
For comparison, Akamai globally peaks at about 6.5 million hits/second.
The trick is not, did sales grow? It's what was the derivative of the growth. If sales were growing at a steady 10% a year and the year CSS was cracked it dropped to a steady 3% growth, sales still grew the year it was cracked, but it's fair to assume not as much. But I don't have those figures - can you cite?
The whole point of BD+ is to change that, because player manufacturers have a built-in incentive to produce weak protection. The idea is to let the studios decide how much to invest in protection.
If you read what I wrote more carefully, you'll see it says "sharp drop" not "drop to nothingness". Obviously there are always some people who will buy the discs. The question is how many sales did you lose because obtaining a free copy became so easy. By the way, your belief that without DRM the discs would sell "fine" is pretty weak - who decides what "fine" is? You know most movies lose money and are subsidised by the blockbusters, right?
I'm surprised this even still comes up. By definition sales fall when copy protection is cracked, otherwise nobody would bother developing it in the first place. A system like BD+ isn't cheap to create or maintain so I'd imagine the losses are significant.
Unless you actually believe all the executives at all the movie studios and their major shareholders are so stupid they can't read a graph, of course. In which case I don't know what to say ... none of us here have the information needed to know the economics of BD+ or similar systems but it's reasonable to infer the entire industry isn't staffed by financial illiterates, otherwise movies would never get made at all.
I agree that the BD group may eventually be backed into a corner over software players, at which point it'll boil down to pure economics. I read that the vast majority of BluRay players in the world are PS3, although of course, that doesn't mean the vast majority of used BR players are PS3s.
I honestly have no idea what proportion of BluRay watchers watch via their PCs, but the equation is simple - take a graph of disc sales. Presumably at some point its BD+ program is cracked and sales will fall as high quality rips show up on the internet - I'd imagine the graph looks like a sharp rise upwards on release week followed by a gradual decay into nothingness over time, with a sharp drop around the time the BD+ program is cracked (assuming it lasts long enough that you can even get a sales baseline, ie, not within a few days).
Now let's say 10% of BluRay watchers use a PC, so reduce your project sales by 10% but remove the sharp drop due to piracy, take the integral of both graphs and see if the difference is positive. If it's big enough it might be worth abandoning PC playback to avoid the piracy (or shift that sales cliff to a point where sales were low anyway).
If the economics don't look like that, then the BD group needs to try and get PowerDVD and friends seriously buffed up, security wise. It's certainly possible to make x86 code annoying and difficult to reverse engineer, but very few people can do it well. I'd imagine most of them don't work for BluRay player software companies.
I'd be very interested in a chart of every BluRay title released and when it was cracked, but I doubt such information is publically available.
Yes I know. What I meant was, what proportion of BluRay watching people watch the movies on their laptops or desktops, vs a dedicated hardware player or PS3. And yes I expect the PS3 does a lot of it in software too. Point is, I also expect tracing the BD+ VM in a PS3 to be quite hard.
The differences between Linux distros are big enough to annoy programmers with better things to do, but small enough that you can still write a virus that works on all of them if you want to. So it's actually the worst of all possible worlds.
As far as I can tell, it wasn't actually disabled though. What they guy did is write his own BD+ VM. An impressive feat for sure, but that attack was always anticipated. As the dude says later,
So basically the disk authors can keep up for as long as they can trace the VM of an existing licensed player. They don't need to do that currently because no publishers are searching for their VM specifically.
They'll probably be able to do this for as long as publishers want their discs to be playable on software players, simply because it's quite easy to reverse engineer x86 code on a PC, when you have a debugger and plenty of Jolt. I don't know what the BluRay player market looks like. If most BluRay players are hardware based, then as a movie studio I'd be tempted to simply write some BD+ code that looked for existing software players and banned all of them. Then the "trace a licensed player" step outlined above suddenly turns into a silicon reverse engineering problem instead of a software reverse engineering problem. Much harder.
That said, I doubt they'd actually do that. Presumably they allowed software players for a reason, despite knowing they were way easier to hack than hardware players.
You've just explained why Python on a phone is a dumb idea. Have you ever looked at the memory usage of a Python program? Java is bad but Python is absolutely insane. For the longest time (and perhaps this is still true) the Python interpreter just never released memory back to the OS once it had been allocated. That's how much they cared about memory usage.
Here's a few more reasons why Python would be an awful language to develop phone software in. The Python interpreter doesn't "do" multi-threading. It's easier to use Python APIs mistakenly because there's no explicit typing. There's no good IDE for Python, but Eclipse rocks.
You mentioned that Python is appropriate because "for everything performance-critical it uses libraries written in C". So does Android - I suggest you read the code, you'll find that anything CPU intensive is written in C++ or C.
I can't actually think of a worse language for a cell phone than Python, which is not only extremely poor CPU wise, but also memory wise. Actually there are only a few tasks Python is really appropriate for (and I say that as somebody who gets paid to write Python programs every day) - for any codebase of a significant size, there are better tools. Android is a pretty giant codebase.
Yeah there's some pretty weak justifications given for their policies here, but there's also a lot of people pointing out how dumb that is. You included. And your "karma killer" post is at +4 currently, so you should give Slashdotters more credit ...
Yes indeed. A little known fact about the UK is that it pays less for drugs than most other countries, because it negotiates collectively on the behalf of 60 million people.
An entertaining quote from an article by an NHS manager:
Argh. Where does this idea that the public sector is inherently less efficient and good than the private sector come from?
Efficiency and competency are not magically grown by acting in a market. All a market does is impose a lower bound on inefficiency and incompetency. In a perfectly functioning free market the smallest improvement by any participant has to be matched by all the participants, so there's a gradual progression upwards. Unfortunately many (most?) markets function poorly. Barriers to entry, over or under regulation, too few competitors or too many, lack of information ... whatever the cause, there's a massive gulf between practice and theory.
Look at mobile phone companies if you don't believe me. Have you ever been with a cellular company that didn't have atrocious customer service, rampant incompetence and all kinds of stupid problems? I never have. That's because the market has huge barriers to entry and so there isn't much competition. The few companies that do exist stagnate and nothing gets better until some external party forces it (eg Apple with the AT&T deal or the EU with roaming charges).
Now consider the NHS. It is very much in competition with private health companies - if the NHS failed completely, people would go to the private sector despite the cost, and any politician who ran on a manifesto of shutting it down would win. This doesn't happen because the NHS is not a disaster, not even close.
A great organization comes from having smart, knowledgable, well motivated staff who have the resources they need to get things done. Period. End of story. You can use a (well run) market and hope that people get a choice of such a company, thus forcing improvement or death on the others - or you can vote in politicians who'll go in and make sure the people are good and the resources are available. Both solutions work in a theoretical work, and both sometimes fail in the real world. But ultimately they are two means to the same end.
Huh what? I think you're confusing the Objective-C shipped with Leopard, which does (finally) do GC, with the Objective-C you have to use in the iPhone which apparently does not. That's pretty shocking. I had no idea the iPhone SDK was that far behind but it appears to be true.
It's pretty ballsy to ask developers to do phone development without a GC these days. Manual memory management is just pain for users and developers. I guess the lack of multi-tasking makes memory leaks less of an issue because apps won't live very long, but on Android it'd be essential - you don't want the system to be constantly recycling leaky apps. You especially don't want apps to crash because they double-freed an allocation.
If you build your hardware in a country notorious for having shadow shifts at factories, and then give away your source code as well, what makes you think there'd be any market left for your products?
The real question is, if ODF doesn't become a re-implementation of OOXML, who is going to use it?
I think a lot of people are struggling with a painful but unavoidable truth - ODF does not matter, has never mattered and never will matter. The vast, vast, vast majority of spreadsheets today are produced using Excel, which has a long history as a program and has at various times had bugs and defects introduced into its calculation engine. People went on to produce millions of business documents that either rely on these bugs, or work around them such that they will break if the bugs are fixed.
Microsoft, PR wise, are in a lose-lose situation here. Either they can request that ODF has a way to express some of these bugs, and be able to reliably export Excel documents to it. Or they can leave ODF "pure" and "clean" and implement an exporter that subtly mangles documents such that they appear to work but produce incorrect answers. The latter is probably a good way to get sued and would certainly result in a shit-storm of "Microsoft makes deliberately buggy code to discredit ODF", but the former is a good way to ALSO get a PR disaster of "Microsoft dictates direction of open standards".
I'd really like to see more competition and better compatibility in the office suite world, but to be completely honest if I was a program manager for Excel at Microsoft I'd be very tempted to walk away from the whole standardisation process. I'd publish precise documentation for the binary formats (which they've done) and then leave it. No slow XML formats. No stupid attempts to pretend that the StarOffice spreadsheet format can be some kind of international standard when the actual, de facto standard is .XLS, warts and all. No lose-lose PR situations. Publish the bugs so other companies can be compatible with the 800 pound gorilla, and that goes far enough.