If that was the case then the tivoization clause in the GPLv3 is redundant, which seems like a pretty wild argument considering how controversial it was.
Because if you truly want to promote freedom and free code, you also have to let people to profit from it. Freedom isn't picking who gets to enjoy that "freedom" based on some rules.
You're blatantly misinterpreting what he said. The problem isn't that they profit from it -- and there is nothing in the GPL that prohibits profit. The problem is that they "take your work, profit from it, and give nothing back."
I'm sure anyone who has been paying attention has already heard this, but this is the obvious problem with BSD license: You spend a million hours creating a great program, call it Foo, and you release it under the BSD license. Someone like Microsoft comes along, takes Foo, improves it a little bit, calls it FooBar and distributes it as a binary without publishing any of the code. If the improvements are good, they can't be brought back into the main tree because the original developers don't have the source. But now FooBar, being an improved version of Foo, will take all of the Foo user base -- it has every good feature of Foo and a few more. The original developers get no bug reports. There are no longer any developer-users who can think of a great new improvement and submit a patch, because everybody is now using FooBar and nobody has the source to that. It withers as an open source project -- you might as well just assign the copyright to Microsoft for free.
Even where the original community is strong enough that it doesn't completely destroy them, it still gives them a bloody nose. You look at something like Kerberos. Who uses Kerberos? Hardly anybody. Who uses Active Directory, which Microsoft created by integrating Kerberos and LDAP with Windows and making it proprietary? Almost everybody. Which means Kerberos is finished. Everybody is already using AD, so there is no reason to adopt Kerberos, which means no community. And if you don't think so, by all means explain why Linux has a much larger community than BSD.
About the only time that a corporation adopting code licensed under the BSD license doesn't kick the crap out of the community that originally developed it is where the company that adopts it submits their changes back to the original developers -- but if they intend to do that then the developers might as well have used GPLv2.
No it isn't. Section 230 of the Communications Decency Act is good. The fact that the CDA doesn't cover "intellectual property" in the same way it does everything else is what the problem is.
I've wondered why there aren't more folks with high powered rifles taking out bankers and the like. Or some Dexter-esque like character stalking congress.
Dexter is fiction. The chances of one guy being able to kill multiple members of Congress on multiple occasions without being caught is extremely low, because as soon as it happens once, it becomes the number one priority for law enforcement. What actually happens is Gabrielle Giffords. And that sort of thing does happen. (Of course, the problem is that the people crazy enough to do something like that are so crazy that you can't count on them to only go after the evil and corrupt. No one is safe from crazy.)
I suppose you could turn off all optimizations in your compiler and get something that'll run on every different generation of a given major architecture, but it'll perform horribly.
You mean kind of like Java does?
You might notice you can't run desktop programs on a x386 CPU these days, even though it's theoretically the same architecture.
You might notice that you can run Debian on a 486, and you can get it to run on a 386 if you mess with it some. Moreover, nobody actually cares about running anything on a 386 anymore. If you release a new application, you don't have to limit yourself to instructions that exist on a 386, because nobody cares to run it on one. And if you make something "limited" to being able to run on a Pentium III then you have something that will run perfectly well on a Core i7.
The only advantage of bytecode is that if you have a program from the 386 era, it will run on modern processors and take advantage of new instructions that are supported by the JVM. But nobody runs 386 era applications any more than they run modern applications on a 386. And the 386 era applications still run without issue on modern x86 processors, they're just a little slower than they would be if you recompiled them. But if it ran with acceptable performance on a 386 then generally speaking nobody is going to complain about how it runs on a Core i7. Or a Pentium III for that matter.
App developers won't mind that compiling their app takes 100X as long. Of course. What was I thinking?
First of all, compiling it a half dozen times, and only on releases to the public, is not a big deal.
But OK, so solve it the right way then: You don't have the app developers compile them at all. They just upload the source code to the marketplace, which the marketplace keeps confidential but can periodically recompile if new architectures should appear.
Whatever world you live in, where major updates take no effort, never introduce any bugs, and everyone just does it for no benefit to themselves, with everyone who has ever written an app just sitting around with everything ready to go, just waiting to recompile their app again and again for no benefit to themselves.
Oh yes, no benefit to themselves. Bug fixes and support for new architectures have no benefits to developers. What happens when I apply your argument against JVM updates for end users? Can't use those new instructions if the JVM didn't support the processor until after the processor was in production and the devices sold with those processors all have the old JVM which never gets updated, can you?
Pretty much anywhere a crappy javascript + flash web page has been turned into an Android apps, there is lots of interest in running it on a desktop. People complain endlessly about how much CPU power is wasted by Youtube, but not an issue if you have a native app. Ditto for Pandora, and many, many others.
How is that in any way better than releasing a native desktop application with a desktop UI that does the same thing? And how do you explain the lack of such things if there is actually real demand for them?
Right... Instead of a Dalvik wrapper to allow android programs to run on any JRE anywhere... you just need to port the entire platform... it's as easy as writing WINE!
To make Android programs run on a desktop platform, all you really have to do is implement the Android APIs, which you don't even have to do from scratch because it's open source and you can use the existing code. WINE is only hard because it has to be implemented from scratch. Compare this with Boost or OpenGL, which runs on everything and shares most of the same code between platforms.
And would you care to explain what universe you live in where you can avoid having to do exactly the same thing and implement the entire Android API in your "wrapper"? Or are you just planning to virtualize the entire OS, which you could do regardless of what kind of language anybody is using?
At the moment it's not too significant, as there's quite a monoculture of hardware. However, should another arch prove to be significantly superior, such as China's Longsoon MIPS CPU, it could be a huge advantage.
Except that MIPS is an existing architecture with existing compilers, so you would already have binaries for it if you check the "make one for everything" box. There hasn't been a new major architecture in like 20 years, and there is little reason for there to be, because anyone who wants to make a new chip can far more easily just license an existing one.
Right, you only have to massively balloon the IDE / SDK with cross-compilers for every single possible architecture out there, keep copies of every single one forever, and hope nobody tries to install the APK from their phone on another device, ever...
Do you know how big a cross compiler is? It's like a couple of megabytes, on a desktop computer where people have 2TB hard drives. BFD. And the IDE can just put the URL where all the different architecture versions are available inside the APK, so that when you try to open it on the wrong architecture, it just downloads the right one from the internet.
Are you even talking about the same subject? How are you planning on forcing 100 million app developers to go download your latest IDE / SDK and recompile all their programs?
They already have your IDE. The auto updater opens up and lets them download the newest version. Then, in two weeks when some bug is found in version 2.3.3 of their application, they release version 2.3.4 and along with it they automatically get the new extensions because they compiled it with the new IDE.
Desktops...
I don't think anybody is really interested in running Android apps on their desktops -- because if they were, people would just release a desktop version of the same app which uses a desktop UI API instead of a mobile one. And if you really want to, you can always just implement the Android API on whatever OS in the same way as you would write a VM for it and then run Android programs on whatever you want the same as you can run Windows programs under WINE, except that unlike Win32, Android is open source so it would actually work properly.
Last I checked, QT apps have to be recompiled when you're moving from one architecture to another. Basing Android on a VM means you can quickly port Android to MIPS or x86, and most apps can be downloaded from the market and run, unmodified.
That seems like an extremely trivial advantage. All you would have to do is configure the IDE to automatically produce a binary for each hardware platform, put them all in the market, then detect the user's device architecture to give them the right version when they download it. It can be entirely automated so that nobody ever sees any difference.
The only advantage would be if someone created some entirely new and unforeseen ISA which you had failed to produce binaries for, and that hasn't happened in decades (excluding x64, since every x64 processor will run x86 code). Or I suppose that if you make ISA extensions then old code can take advantage of them without a recompile, but that's really not worth very much since the next version of any given app will get them automatically as soon as you put support in the compiler, and the number of apps that simultaneously still have people using them and are entirely unmaintained is pretty inconsequential when all you're worried about is a single digit performance improvement.
In addition, basing it on a subset of java in particular means most platforms already have the basic VM, and unmodified Android apps can be run with just a modest wrapper around them.
What "platforms"? The only significant platform that you would generally want to port an Android application to is iOS and I don't think it uses the same APIs for the UI. Certainly everything there is tooled for Objective-C and C/C++ rather than Java.
Nobody's perfect. The point is that having a single model doesn't save you from problems.
In theory Apple might be able to spend more effort working out all the bugs than would someone with less volume, but there are two troubles there: The first is that the most popular Android handsets have a sales volume within an order of magnitude of the iPhone, which means they can achieve as close as makes no difference to those economies of scale. The second is that diversity has its advantages: You can choose among all the Android handsets that have come out in the last six months and pick the one that has proven to have the least problems, whereas if you only have one option and it has a problem which is a deal breaker for you, you're SOL.
It's possible to do some analytics of apps with Google analytics because you can always get an app to generate a HTML request. And Google will tell you how to do that. But it's a hack.
It is clearly derived from the web-based version, but they have an SDK for it (Android, iOS) that looks a lot more like a traditional API than any sort of HTML hack. I imagine it's making HTTP requests behind the scenes, but what doesn't these days?
Moreover, the point is that it seems reasonable for Android developers to find the Google Analytics SDK more easily than iOS developers, because Google developer docs on Android are naturally more likely to discuss Google APIs like that than the equivalent Apple developer docs on iOS. That would be true even if Flurry is better by some measure; "better" doesn't mean "more popular" as anyone can tell from Microsoft's historical desktop market share.
I think you might have just explained the results without even realizing it.
Is Flurry Analytics not a thing that competes with Google Analytics? Because I could kind of see how Google would be better able to promote Google Analytics to Android developers more easily than to iOS developers, which would take them disproportionally out of Flurry's numbers.
How does that help you when there is no installed base? Even if every user buys your app, when there are no users you make no sales. On top of that, your points are self defeating: If by some miracle they actually gained some market share then other developers would follow the users, and you would immediately lose the advantage of the lack of competition.
There is just no incentive to be an early adopter of WP7, which is why it hasn't (and won't) go anywhere. There need to be users before you can get developers, and there need to be developers before you can get users. They need some actual advantage over the existing competition in order to bootstrap, like Apple had with the original iPhone or Google has by making Android free, but now those are the baseline and Microsoft doesn't have anything that can beat them in a sufficiently drastic way to overcome the lack of apps. Plus, nobody likes Microsoft on general principles.
On top of that, you can throw all of the "Apple is better than Google because diversity sucks" arguments at them: Who wants to promote the establishment of another app store and development platform? All that does is create more work for developers. Why should they promote such wasteful duplication of their own effort by producing apps for a platform that presently has no significant number of users?
I'm the exact opposite. My game engine and various libraries (lua, box2d, etc) are all written in C++ / C, thus I have a single codebase that I build for both iOS and Android (and Windows and OSX). 99.9% of the code is shared - there are literally a few dozen lines of Javascript / Objective C that tie events at the app level into my game engine.
This is really why this article is a gigantic troll. It's true that Google could stand to make some improvements, but there is just no excuse for abandoning more than half the market over the less than one percent of the code you would have to change to port a well-designed app to another platform.
You shouldn't say "mod this up" in your own post. You actually have an excellent idea, and people who might otherwise mod it up without you telling them to do so will be less inclined to because nobody likes to be told what to do.
BUT, in reality, it is simply to expensive to have trials for everyone.
That's true, of course. But the way it's supposed to work is that both sides realize how expensive a trial is and come to a settlement that is better for both parties than paying the expense of a trial only to get a similar outcome.
You might notice how that is different than saying "courts are expensive, so let's make it so that any time there is a dispute between Hollywood and someone else we can save the trial costs by just declaring Hollywood the winner."
I've taken 14kV (what that particular car's coil outputted)
People should keep in mind that the ignition coil on a car is not designed to generate significant current, so you can't use the typical 'volts and ohms determines amps' calculation. By contrast, 14kV generated by, say, an industrial transformer connected to the power grid is pretty firmly on the "this will kill you" list.
Gah, such pedantry. Yes of course the judge doesn't personally put his hand in the corporation's treasury and pull out money to give to you, but is there a relevant and practical difference in effect?
On the other hand, liquid bleach will do wonders over a period of a week
I just want to point out something that should be obvious, but deserves to be pointed out nonetheless: Don't be an idiot. If you don't know what you're doing, don't go around mixing random shit together. It's not very hard to win yourself a Darwin award by mixing oxygen bleach with gasoline or chlorine bleach with any of a long list of things that will release chlorine gas.
If Universal has an automated system producing false positives, I suspect it would be much more understandable to the average Slashdotter.
What makes you think so? The copyright holder is the only party in any position to reduce false positives, which means the copyright holders ought to be the ones that bear the cost of doing so. Otherwise we get overrun with them. YouTube is blatantly the wrong party because they have no stake in it: They'll just do whatever it takes to reduce their legal liability regardless of what's correct, and if you box them in from both sides by requiring there to be no false positives or false negatives then they'll just go out of business.
The correct solution is to put the liability for false positives (i.e. fraudulent take downs) on the copyright holder and the liability for false negatives (i.e. copyright infringement) on the poster. That way both have a strong incentive to minimize the errors, because if they allow errors then they have legal liability but the measures they take to reduce them will come at the cost of their own stake in the matter, so they'll have an incentive to find the most accurate and effective methods to do so, which is the desired outcome.
If you publish on YouTube, you have to live with the eccentricities of YouTube's automated systems, whether or not they are always fair to you.
I hope you can see why you're being particularly unfair to those who can't afford to host their own content, but still have something to say.
Because in the case of arrest you are looking at the possibility severely affecting people's lives. In the case of Youtube you are simply talking about yanking a video from...uh Youtube.
If YouTube is so insignificant then why does it matter if copyrighted videos get posted to it? Either it's unimportant and so if copyrighted works get posted there it doesn't much matter and there is no call for extraordinary minimal-oversight methods to remove them, or it's very important and thereby requires the whole of due process. You can't have it both ways.
It seems to me that you could solve the problem pretty well in the following way: If a copyright holder negligently issues a take down for material that is likely to be fair use, the civil damages are no less than 5% of the total revenues collected with respect to that copyrighted work. If the copyright holder intentionally issues such a take down [like Diebold], the damages are no less than one million dollars.
That would pretty well sort it out, and with no help from any prosecutors office: The victims could collect directly in civil court. And copyright holders who find they are unable to tell whether something is fair use are free to request an injunction in court instead of using the take down process, so that a judge can make that determination in an adversarial proceeding prior to the copyright holder subjecting itself to any liability for issuing a fraudulent take down.
People are talking about policy. What the law should be. You're talking about what the law is, which is the whole problem.
Incidentally, fair use is a bit special because of the first amendment implications. Its sort of like self defense for murder: It's unconstitutional for them to punish you for it. What does that tell you about whether the law should allow "shoot first and ask questions later" on the part of the enforcers?
Slashdot Mirror
If that was the case then the tivoization clause in the GPLv3 is redundant, which seems like a pretty wild argument considering how controversial it was.
Because if you truly want to promote freedom and free code, you also have to let people to profit from it. Freedom isn't picking who gets to enjoy that "freedom" based on some rules.
You're blatantly misinterpreting what he said. The problem isn't that they profit from it -- and there is nothing in the GPL that prohibits profit. The problem is that they "take your work, profit from it, and give nothing back."
I'm sure anyone who has been paying attention has already heard this, but this is the obvious problem with BSD license: You spend a million hours creating a great program, call it Foo, and you release it under the BSD license. Someone like Microsoft comes along, takes Foo, improves it a little bit, calls it FooBar and distributes it as a binary without publishing any of the code. If the improvements are good, they can't be brought back into the main tree because the original developers don't have the source. But now FooBar, being an improved version of Foo, will take all of the Foo user base -- it has every good feature of Foo and a few more. The original developers get no bug reports. There are no longer any developer-users who can think of a great new improvement and submit a patch, because everybody is now using FooBar and nobody has the source to that. It withers as an open source project -- you might as well just assign the copyright to Microsoft for free.
Even where the original community is strong enough that it doesn't completely destroy them, it still gives them a bloody nose. You look at something like Kerberos. Who uses Kerberos? Hardly anybody. Who uses Active Directory, which Microsoft created by integrating Kerberos and LDAP with Windows and making it proprietary? Almost everybody. Which means Kerberos is finished. Everybody is already using AD, so there is no reason to adopt Kerberos, which means no community. And if you don't think so, by all means explain why Linux has a much larger community than BSD.
About the only time that a corporation adopting code licensed under the BSD license doesn't kick the crap out of the community that originally developed it is where the company that adopts it submits their changes back to the original developers -- but if they intend to do that then the developers might as well have used GPLv2.
Your analogy is completely right, but keep in mind that the Farmer is Congress.
DMCA itself is good.
No it isn't. Section 230 of the Communications Decency Act is good. The fact that the CDA doesn't cover "intellectual property" in the same way it does everything else is what the problem is.
I've wondered why there aren't more folks with high powered rifles taking out bankers and the like. Or some Dexter-esque like character stalking congress.
Dexter is fiction. The chances of one guy being able to kill multiple members of Congress on multiple occasions without being caught is extremely low, because as soon as it happens once, it becomes the number one priority for law enforcement. What actually happens is Gabrielle Giffords. And that sort of thing does happen. (Of course, the problem is that the people crazy enough to do something like that are so crazy that you can't count on them to only go after the evil and corrupt. No one is safe from crazy.)
I suppose you could turn off all optimizations in your compiler and get something that'll run on every different generation of a given major architecture, but it'll perform horribly.
You mean kind of like Java does?
You might notice you can't run desktop programs on a x386 CPU these days, even though it's theoretically the same architecture.
You might notice that you can run Debian on a 486, and you can get it to run on a 386 if you mess with it some. Moreover, nobody actually cares about running anything on a 386 anymore. If you release a new application, you don't have to limit yourself to instructions that exist on a 386, because nobody cares to run it on one. And if you make something "limited" to being able to run on a Pentium III then you have something that will run perfectly well on a Core i7.
The only advantage of bytecode is that if you have a program from the 386 era, it will run on modern processors and take advantage of new instructions that are supported by the JVM. But nobody runs 386 era applications any more than they run modern applications on a 386. And the 386 era applications still run without issue on modern x86 processors, they're just a little slower than they would be if you recompiled them. But if it ran with acceptable performance on a 386 then generally speaking nobody is going to complain about how it runs on a Core i7. Or a Pentium III for that matter.
App developers won't mind that compiling their app takes 100X as long. Of course. What was I thinking?
First of all, compiling it a half dozen times, and only on releases to the public, is not a big deal.
But OK, so solve it the right way then: You don't have the app developers compile them at all. They just upload the source code to the marketplace, which the marketplace keeps confidential but can periodically recompile if new architectures should appear.
Whatever world you live in, where major updates take no effort, never introduce any bugs, and everyone just does it for no benefit to themselves, with everyone who has ever written an app just sitting around with everything ready to go, just waiting to recompile their app again and again for no benefit to themselves.
Oh yes, no benefit to themselves. Bug fixes and support for new architectures have no benefits to developers. What happens when I apply your argument against JVM updates for end users? Can't use those new instructions if the JVM didn't support the processor until after the processor was in production and the devices sold with those processors all have the old JVM which never gets updated, can you?
Pretty much anywhere a crappy javascript + flash web page has been turned into an Android apps, there is lots of interest in running it on a desktop. People complain endlessly about how much CPU power is wasted by Youtube, but not an issue if you have a native app. Ditto for Pandora, and many, many others.
How is that in any way better than releasing a native desktop application with a desktop UI that does the same thing? And how do you explain the lack of such things if there is actually real demand for them?
Right... Instead of a Dalvik wrapper to allow android programs to run on any JRE anywhere... you just need to port the entire platform... it's as easy as writing WINE!
To make Android programs run on a desktop platform, all you really have to do is implement the Android APIs, which you don't even have to do from scratch because it's open source and you can use the existing code. WINE is only hard because it has to be implemented from scratch. Compare this with Boost or OpenGL, which runs on everything and shares most of the same code between platforms.
And would you care to explain what universe you live in where you can avoid having to do exactly the same thing and implement the entire Android API in your "wrapper"? Or are you just planning to virtualize the entire OS, which you could do regardless of what kind of language anybody is using?
At the moment it's not too significant, as there's quite a monoculture of hardware. However, should another arch prove to be significantly superior, such as China's Longsoon MIPS CPU, it could be a huge advantage.
Except that MIPS is an existing architecture with existing compilers, so you would already have binaries for it if you check the "make one for everything" box. There hasn't been a new major architecture in like 20 years, and there is little reason for there to be, because anyone who wants to make a new chip can far more easily just license an existing one.
Right, you only have to massively balloon the IDE / SDK with cross-compilers for every single possible architecture out there, keep copies of every single one forever, and hope nobody tries to install the APK from their phone on another device, ever...
Do you know how big a cross compiler is? It's like a couple of megabytes, on a desktop computer where people have 2TB hard drives. BFD. And the IDE can just put the URL where all the different architecture versions are available inside the APK, so that when you try to open it on the wrong architecture, it just downloads the right one from the internet.
Are you even talking about the same subject? How are you planning on forcing 100 million app developers to go download your latest IDE / SDK and recompile all their programs?
They already have your IDE. The auto updater opens up and lets them download the newest version. Then, in two weeks when some bug is found in version 2.3.3 of their application, they release version 2.3.4 and along with it they automatically get the new extensions because they compiled it with the new IDE.
Desktops...
I don't think anybody is really interested in running Android apps on their desktops -- because if they were, people would just release a desktop version of the same app which uses a desktop UI API instead of a mobile one. And if you really want to, you can always just implement the Android API on whatever OS in the same way as you would write a VM for it and then run Android programs on whatever you want the same as you can run Windows programs under WINE, except that unlike Win32, Android is open source so it would actually work properly.
Last I checked, QT apps have to be recompiled when you're moving from one architecture to another. Basing Android on a VM means you can quickly port Android to MIPS or x86, and most apps can be downloaded from the market and run, unmodified.
That seems like an extremely trivial advantage. All you would have to do is configure the IDE to automatically produce a binary for each hardware platform, put them all in the market, then detect the user's device architecture to give them the right version when they download it. It can be entirely automated so that nobody ever sees any difference.
The only advantage would be if someone created some entirely new and unforeseen ISA which you had failed to produce binaries for, and that hasn't happened in decades (excluding x64, since every x64 processor will run x86 code). Or I suppose that if you make ISA extensions then old code can take advantage of them without a recompile, but that's really not worth very much since the next version of any given app will get them automatically as soon as you put support in the compiler, and the number of apps that simultaneously still have people using them and are entirely unmaintained is pretty inconsequential when all you're worried about is a single digit performance improvement.
In addition, basing it on a subset of java in particular means most platforms already have the basic VM, and unmodified Android apps can be run with just a modest wrapper around them.
What "platforms"? The only significant platform that you would generally want to port an Android application to is iOS and I don't think it uses the same APIs for the UI. Certainly everything there is tooled for Objective-C and C/C++ rather than Java.
Nobody's perfect. The point is that having a single model doesn't save you from problems.
In theory Apple might be able to spend more effort working out all the bugs than would someone with less volume, but there are two troubles there: The first is that the most popular Android handsets have a sales volume within an order of magnitude of the iPhone, which means they can achieve as close as makes no difference to those economies of scale. The second is that diversity has its advantages: You can choose among all the Android handsets that have come out in the last six months and pick the one that has proven to have the least problems, whereas if you only have one option and it has a problem which is a deal breaker for you, you're SOL.
It's possible to do some analytics of apps with Google analytics because you can always get an app to generate a HTML request. And Google will tell you how to do that. But it's a hack.
It is clearly derived from the web-based version, but they have an SDK for it (Android, iOS) that looks a lot more like a traditional API than any sort of HTML hack. I imagine it's making HTTP requests behind the scenes, but what doesn't these days?
Moreover, the point is that it seems reasonable for Android developers to find the Google Analytics SDK more easily than iOS developers, because Google developer docs on Android are naturally more likely to discuss Google APIs like that than the equivalent Apple developer docs on iOS. That would be true even if Flurry is better by some measure; "better" doesn't mean "more popular" as anyone can tell from Microsoft's historical desktop market share.
I think you might have just explained the results without even realizing it.
Is Flurry Analytics not a thing that competes with Google Analytics? Because I could kind of see how Google would be better able to promote Google Analytics to Android developers more easily than to iOS developers, which would take them disproportionally out of Flurry's numbers.
How does that help you when there is no installed base? Even if every user buys your app, when there are no users you make no sales. On top of that, your points are self defeating: If by some miracle they actually gained some market share then other developers would follow the users, and you would immediately lose the advantage of the lack of competition.
There is just no incentive to be an early adopter of WP7, which is why it hasn't (and won't) go anywhere. There need to be users before you can get developers, and there need to be developers before you can get users. They need some actual advantage over the existing competition in order to bootstrap, like Apple had with the original iPhone or Google has by making Android free, but now those are the baseline and Microsoft doesn't have anything that can beat them in a sufficiently drastic way to overcome the lack of apps. Plus, nobody likes Microsoft on general principles.
On top of that, you can throw all of the "Apple is better than Google because diversity sucks" arguments at them: Who wants to promote the establishment of another app store and development platform? All that does is create more work for developers. Why should they promote such wasteful duplication of their own effort by producing apps for a platform that presently has no significant number of users?
I'm the exact opposite. My game engine and various libraries (lua, box2d, etc) are all written in C++ / C, thus I have a single codebase that I build for both iOS and Android (and Windows and OSX). 99.9% of the code is shared - there are literally a few dozen lines of Javascript / Objective C that tie events at the app level into my game engine.
This is really why this article is a gigantic troll. It's true that Google could stand to make some improvements, but there is just no excuse for abandoning more than half the market over the less than one percent of the code you would have to change to port a well-designed app to another platform.
You shouldn't say "mod this up" in your own post. You actually have an excellent idea, and people who might otherwise mod it up without you telling them to do so will be less inclined to because nobody likes to be told what to do.
BUT, in reality, it is simply to expensive to have trials for everyone.
That's true, of course. But the way it's supposed to work is that both sides realize how expensive a trial is and come to a settlement that is better for both parties than paying the expense of a trial only to get a similar outcome.
You might notice how that is different than saying "courts are expensive, so let's make it so that any time there is a dispute between Hollywood and someone else we can save the trial costs by just declaring Hollywood the winner."
I've taken 14kV (what that particular car's coil outputted)
People should keep in mind that the ignition coil on a car is not designed to generate significant current, so you can't use the typical 'volts and ohms determines amps' calculation. By contrast, 14kV generated by, say, an industrial transformer connected to the power grid is pretty firmly on the "this will kill you" list.
Gah, such pedantry. Yes of course the judge doesn't personally put his hand in the corporation's treasury and pull out money to give to you, but is there a relevant and practical difference in effect?
So you apply the law in the country where the poster lives. Why is that so hard?
On the other hand, liquid bleach will do wonders over a period of a week
I just want to point out something that should be obvious, but deserves to be pointed out nonetheless: Don't be an idiot. If you don't know what you're doing, don't go around mixing random shit together. It's not very hard to win yourself a Darwin award by mixing oxygen bleach with gasoline or chlorine bleach with any of a long list of things that will release chlorine gas.
Because obviously corporations prefer to be found in contempt of court and then have their assets seized?
If only there was something we could do.
If Universal has an automated system producing false positives, I suspect it would be much more understandable to the average Slashdotter.
What makes you think so? The copyright holder is the only party in any position to reduce false positives, which means the copyright holders ought to be the ones that bear the cost of doing so. Otherwise we get overrun with them. YouTube is blatantly the wrong party because they have no stake in it: They'll just do whatever it takes to reduce their legal liability regardless of what's correct, and if you box them in from both sides by requiring there to be no false positives or false negatives then they'll just go out of business.
The correct solution is to put the liability for false positives (i.e. fraudulent take downs) on the copyright holder and the liability for false negatives (i.e. copyright infringement) on the poster. That way both have a strong incentive to minimize the errors, because if they allow errors then they have legal liability but the measures they take to reduce them will come at the cost of their own stake in the matter, so they'll have an incentive to find the most accurate and effective methods to do so, which is the desired outcome.
If you publish on YouTube, you have to live with the eccentricities of YouTube's automated systems, whether or not they are always fair to you.
I hope you can see why you're being particularly unfair to those who can't afford to host their own content, but still have something to say.
Because in the case of arrest you are looking at the possibility severely affecting people's lives. In the case of Youtube you are simply talking about yanking a video from...uh Youtube.
If YouTube is so insignificant then why does it matter if copyrighted videos get posted to it? Either it's unimportant and so if copyrighted works get posted there it doesn't much matter and there is no call for extraordinary minimal-oversight methods to remove them, or it's very important and thereby requires the whole of due process. You can't have it both ways.
It seems to me that you could solve the problem pretty well in the following way: If a copyright holder negligently issues a take down for material that is likely to be fair use, the civil damages are no less than 5% of the total revenues collected with respect to that copyrighted work. If the copyright holder intentionally issues such a take down [like Diebold], the damages are no less than one million dollars.
That would pretty well sort it out, and with no help from any prosecutors office: The victims could collect directly in civil court. And copyright holders who find they are unable to tell whether something is fair use are free to request an injunction in court instead of using the take down process, so that a judge can make that determination in an adversarial proceeding prior to the copyright holder subjecting itself to any liability for issuing a fraudulent take down.
People are talking about policy. What the law should be. You're talking about what the law is, which is the whole problem.
Incidentally, fair use is a bit special because of the first amendment implications. Its sort of like self defense for murder: It's unconstitutional for them to punish you for it. What does that tell you about whether the law should allow "shoot first and ask questions later" on the part of the enforcers?