IANAL, so correct me if I'm wrong. The justice system is designed to fail safe: it intentionally (and rightly) prefers the guilty going free to the innocent being punished. The ability of a judge to override a jury is confined to changing "guilty" or "liable" verdicts into "not guilty" or "not liable" verdicts, and so provides an additional safeguard against wrongful conviction.
By keeping TCP connections open at the kernel level, a faulting application can be restarted without the user knowing.
That's not likely to be useful. First of all, a faulting application might have already sent data to the user. Restarting the request from scratch is just going to send nonsense HTML in that case. Second, chances are that if an application faults for a given request once, it's going to fault the second, third, and fourth times you try that request. Most bugs are not sporadic.
Furthermore, if you really wanted to do restarts, you could do it just as well in userland by using a top-level exception handler or equivalent.
By keeping TCP connections open in the kernel, new connection requests can keep coming in while an application restarts
Either an application comes up quickly or it doesn't. If it comes up quickly, the requests that come in during a restart can be handled by other servers in a cluster. If you don't have a cluster, you don't care enough about uptime for this to apply to you.
If it doesn't come up quickly, then your HTTP queue is going to fill up anyway, and you're in the same boat you started with.
Kernel-mode caching
I concede that there might be some performance gain with the approach given. However, I believe it would be lost in the noise, especially considering a dynamic web application. The page cache I described will give you almost all the performance of this GET cache, and without any of the risks of kernel-mode code.
Likewise, I enjoy a good discussion that doesn't devolve into a flamewar.
Let's establish some objective benchmarks for general-purpose programming languages. Can we agree that it's better for a language to be consistent than not? That it's better to be expressive (as opposed to requiring verbose constructs for simple ideas)? Can we agree that separating code into separate namespaces and modules is a fundamentally good idea? Can we say that "spooky action at a distance" is generally bad? Of course, we should include the each with which a language is learned there too.
A language can't optimize for all these at once, so there's always a tradeoff. Perl trades virtually everything else for expressiveness. Java focuses on consistency. Python, a balance of consistency and expressiveness that you could call aesthetic.
PHP's focus is on being as easy as possible to pick up for the inexperienced programmer who just wants to get his personal task done without having to learn too much about the language.
Consider two animals: animal A reproduces by spawning, and easily has 10,000 offspring. Let's say 0.01% of these offspring go on to reproduce, for an average of 10 offspring per animal A. Now consider an animal B that rears 3 offspring, 90% of which survive to have offspring of their own. In the same niche, animal A will have a huge reproductive advantage over animal B, and animal A will drive B out of its niche in a few generations, ignoring other considerations.
Despite each B being better (say, more intelligent, stronger, faster, etc.), the niche A and B are competing in doesn't require the animal to be better. A is better off, since it devotes its resources to reproducing faster instead of being better individually. If that niche were more demanding, B might be better off.
Now translate that idea into programming language terms. PHP is very easy to pick up for the "n00b", giving it a huge reproductive advantage over other languages. Since PHP is so easy to pick up for mediocre programmers, the typical programmer using PHP will be mediocre. It's not that good people don't use PHP, but that these good people are vastly outnumbered.
Yet PHP is astoundingly successful. What does that tell us?
Most web programming is not hard. The niche is not demanding. PHP, the meme, is better off sacrificing being a "good" language so it can spread, and even in its weakened form, it's more than up for the task. PHP is a more fit language for web programming in an overall sense, if not an individual one.
I'm not arguing that the language designers consciously designed it that way, by the way. I'm merely arguing that that's how it happened. When I say that PHP "wants" this or that, I'm just drawing a metaphor.
Other programming niches, by the way, are more demanding. You'd be hard-pressed to find a language like PHP in, say, compiler-writing. There, the task is harder, so the language, and thus the programmers, are hardier. "Better" languages are more fit for these more demanding niches.
We don't look down on PHP because we secretly desire to be esoteric code-wizards. Instead, we look down on PHP because it's like using a rock to pound in a nail: there are objectively better ways to do what it does, and people who use PHP almost universally use it only out of ignorance.
We try to combat ignorance, but when the people you attempt to educate do nothing but resist new notions, the only response that's left is pity.
You're arguing by assertion. You tell us that it's faster to do these things in the kernel. I asked how that is, and you're now responding by saying, again, that it's faster in the kernel.
URL parsing is string manipulation, and that's going to happen at the same speed in userspace.
"Queuing" seems a little vague, but if it's TCP connection queuing you're talking about, that's always been done in kernel space. "TCP/IP interfacing," likewise, has always been done in kernel space too. See the listen man page (or MSDN documentation section -- winsock works the same way.)
Caching is a function of the page cache. The most recently used disk blocks are already in kernel memory, and are already cached. The kernel will send that cached data using open, then write, splice, sendfile, etc. Did you have a different meaning of "caching" in mind?
What's the benefit of doing basic HTTP in kernel mode then? You still have to hand the data off to userspace before actually handling the request, and parsing headers won't go any faster in kernelspace than in userspace.
The benefit of running in the kernel is that system call overhead is nil. If what you're doing in the kernel doesn't save on syscalls, then you're better off moving it to userspace for safety. Doing bare-bones HTTP in the kernel smells to me like either a gimmick or some kind of nasty scheduler workaround, not a bona fide performance technique.
What TUX does is do the whole thing in kernel space, at least for static content.
I'm still not sure what you're after that the free software world. If it's raw performance you're after (even though it's not really necessary), there are alternatives to Apache, like lighttpd. If it's GUI management, well, just try the config file. It's much easier to work with than any GUI tool I've worked with.
Please, man, realize that plenty of people use languages other than PHP and database engines other than MySQL. I suspect a lower fraction of people use PHP on Apache than use ASP.NET with IIS. I wish I had numbers to back this up though.
When I use mod_rewrite, I always make sure to turn on maximum logging for the first couple minutes so I can make sure my configuration is sane. With that logging on, I haven't found a mod_rewrite problem I couldn't figure out in a few minutes: the logging tells you every step the thing takes, and it's pretty easy to figure out what rule is problematic.
That said, the configuration file syntax for mod_rewrite sucks. But that's life. Personally, I prefer just letting a single base script parse PATH_INFO on its own rather instead of going through mod_rewrite. Then again, I like Tapestry, so take my opinions with a grain of salt.:-)
Performance isn't really a problem when using Apache.
Okay, when you serve a request, you're either running a program (in some way) to generate the content, or you're serving something already on disk, using the webserver itself.
In the first case, dynamic content, the specifics of the server are going to be lost in the noise. We benchmarked my company's webserver overhead at 3ms on a 100ms request, and that's pretty typical of web applications. Getting that down to 2ms is not going to increase overall performance much.
In the second case, that of static content, there are much better servers than Apache anyway. For the sake of argument, I'll grant that IIS is twice as fast as Apache at serving static content. But it doesn't matter! Serving static content is still much faster than serving those dynamically-generated pages. A client is likely to spend far more time waiting for dynamic page generation and actual HTTP transfers than waiting for the server to start sending a static file.
And static content is instantly clusterable as well, since there's no state. logo2.png doesn't need to hit the database, I imagine, and if you're big enough to care about static content performance, you're big enough to get more than one machine anyway.
What is boils down to is that Apache is free, Free, and flexible. IIS may have improved in the latter lately, but it's hard to imagine something that can't be accomplished with Apache's module system. You can even strip it down to being able to serve bare HTTP requests, if you'd like, but why would you ever want to?
Roughly, because PHP manages to do less with more.
Two articles:
Experiences of using PHP in Large Websites: from 2002, but the basic PHP philosophy hasn't changed since then (although some specifics have). Oversimplification and pandering to less experienced developers hurts the language as a whole.
Arguments and return values are extremely inconsistent
PHP has separate functions for case insensitive operations
PHP has inconsistent function naming
PHP has no lexical scope
PHP has too many functions in the core
PHP lacks abstraction and takes TIMTOWTDI to bad extremes
It's not that PHP is that bad. VB, COBOL and PL/1 were all much worse. It's that there are better languages out there that people never learn because they learned PHP as "n00bs" (you can almost detect a PHP developer by his use of that word) and are complacent with it.
Incidentally, I think it's a lot more mind-expanding to learn two programming languages than to learn one. I see single-language people all the time confusing possibility with possibility in a particular language, or confusing overall algorithms and data structures with particular idioms from their pet language. It's sad.
During the middle ages and the renaissance, small professional armies fought pre-arranged battles with minimal collateral damage (ignoring the effects of sieges, of course). But before that period, Rome and the ancient Greeks often practiced total war: look at what happened to the Celts and the Trojans.
There's no overall cycle. Who knows whether we'll swing back into a phase of total war? This time, however, it might be the end of us -- the one trend I do see is that every time we try total war, it gets more destructive.
Joe: For the last time, I'm pretty sure what's killing the crops is this Brawndo stuff. Secretary of State: But Brawndo's got what plants crave. It's got electrolytes. Attorney General: So wait a minute. What you're saying is, you want us to put WATER on the crops? Joe: Yes. Attorney General: Water?? Like, outta the toilet? Joe: Well, I mean... It doesn't have to be out of the toilet. But yeah, that's the idea. Secretary of State: But Brawndo's got what plants crave. Attorney General: Yeah, it's got electrolytes. Joe: Okay, look. The plants aren't growing. So I'm pretty sure that this Brawndo stuff's not working. Now I'm no botanist, but I do know that if you put water on plants they grow. Secretary of Energy: Well, I never seen no plants grow outta no toilet. Secretary of State: Hey, that's good! You sure *you* ain't the smartest guy in the world?! Joe: Okay, look. You want to solve this problem and I want to get my pardon. So - why don't we just try it, okay, and not worry about what plants crave? Attorney General: But Brawndo's got what plants crave. Secretary of Energy: Yeah. It's got electrolytes. Joe: What are electrolytes? Do any of you even know? Secretary of State: It's what they use to make Brawndo. Joe: Yeah, but, why do they use them to make Brawndo?! Secretary of Defense: Cuz Brawndo's got electrolytes.
Correct me if I'm wrong, but I don't think Fluendo's codec is the right approach. It comes in source form, covered under the BSD license, and a binary blob, covered under Fluendo's proprietary EULA, and according to Fluendo's site, but not any legal document I can find, the patent license only applies to the binary version.
That claim raises some interesting questions:
What interest does Fraunhofer have in granting a patent license for the binary version, but not the source? There's no difference in terms of how available the software would become, in principle. The number of installations is bounded by the number of GStreamer installations regardless of whether the package is proprietary or not, since it's freely redistributable (after signing a contract).
Given that, realistically, every Linux user in the US can already get a free mp3 decoder, what advantage does Fraunhofer gain by not granting a blanket MP3 patent license for free software?
What's going on with the redistribution contract? It seems to have some interesting interactions with the BSD source license.
1.4
The Distributor might at some point want to make changes and improvements to the Plug-in Source Code used to generate the Plug-in. Such changes shall automatically be copyrighted to Fluendo and Fluendo shall be notified of these changes, so that Fluendo can include them in the official Plug-in Source Code if they so choose. Any such changes will have to be approved in writing by Fluendo or included in the official Plug-in Source code from Fluendo, before a binary incorporating the changes can be shipped by Distributor.
Uh, so a distributor can't modify the codec without signing the copyrights over to Fluendo?
1.5
Distributor shall not license or grant any right on the Plug-in or the Plug-in Source Code in a different way than as described in the corresponding licenses made by Fluendo for each of them.
Doesn't that make it some weird viral BSD license instead of the BSD itself?
Okay, say I live-blog a game. The MLB (or the stadium owners, or whoever) can eject me, but what I'm doing is not illegal, and the MLB has no legal recourse other than ejection.
Yes, an ad hominem attack based on an omitted word is clearly the mark of seasoned maturity. Applying your standards to LKML posts, Linus must be three.
Now, getting back to the substance of the argument, I'm not advocating the abolition of copyright; I don't think many are. However, quite a few people are beginning to see the harm caused by excessively long copyright terms and brutal restrictions on personal use, and I suspect they'll change copyright law sooner or later.
As far as Hollywood goes, reducing copyright terms and allowing personal, not-for-profit sharing will not result in a decline in the number of films created. The de facto situation today is that anyone interested can find almost any film he wants online. Yet, people still pay for theater tickets and DVDs. I certainly do.
In a larger sense, it doesn't matter whether weakening copyright will result in changes (or even a decline) in the commercial arts. An entire generation has grown up believing that file sharing is not wrong; more people know about our outrageously long copyright terms than ever before. Those who depend on excessive copyright will have to adapt or perish.
Rant all you want, but society has spoken. I'm 22. Damn near everybody in my generation doesn't file trading wrong. Assuming that we maintain our republic, the government will eventually respond to democratic opinion and weaken copyright. Corporate content creators will have to adapt or perish.
Really, the only thieves are the powerful corporations who maintain an ironclad, if weakening, grip on what ought to be in the public domain by now anyway.
Google is already complying with the letter of the DMCA. What right does any other organization have to compel Google to go beyond that and spend a fortune creating a video fingerprinting system? Google ought to be fighting this, not bending over and doing whatever large media companies demand.
Doing this is manifestly against the interest of the people who made Google what it is today. What happened to doing no evil?
Under what law? It sounds insane that simply telling somebody a non-top-secret fact is a felony -- and I don't imagine that bank tellers get security clearances when they're hired.
So, again, what law makes it a felony to tell a bank customer what will trigger reporting? More generally, where can one find a complete list of things tellers may and may not do and say?
Which is why the ACLU defended neo-nazis. Riiiight. The fact is that, these days, it's not about liberals versus conservatives, about the left versus the right.
Today, the battle is between authoritarianism and liberty, and the ACLU is firmly on the side of the latter. It's not a problem that the authoritarians are masquerading as the party of conservative thought and traditional values, when in fact they support neither. Today, being on the left means simply being against authoritarianism, and for basic human rights. The ACLU having a left-leaning bias is laudable, not lamentable.
Slashdot Mirror
IANAL, so correct me if I'm wrong. The justice system is designed to fail safe: it intentionally (and rightly) prefers the guilty going free to the innocent being punished. The ability of a judge to override a jury is confined to changing "guilty" or "liable" verdicts into "not guilty" or "not liable" verdicts, and so provides an additional safeguard against wrongful conviction.
That's not likely to be useful. First of all, a faulting application might have already sent data to the user. Restarting the request from scratch is just going to send nonsense HTML in that case. Second, chances are that if an application faults for a given request once, it's going to fault the second, third, and fourth times you try that request. Most bugs are not sporadic.
Furthermore, if you really wanted to do restarts, you could do it just as well in userland by using a top-level exception handler or equivalent.
Either an application comes up quickly or it doesn't. If it comes up quickly, the requests that come in during a restart can be handled by other servers in a cluster. If you don't have a cluster, you don't care enough about uptime for this to apply to you.
If it doesn't come up quickly, then your HTTP queue is going to fill up anyway, and you're in the same boat you started with.
I concede that there might be some performance gain with the approach given. However, I believe it would be lost in the noise, especially considering a dynamic web application. The page cache I described will give you almost all the performance of this GET cache, and without any of the risks of kernel-mode code.
Likewise, I enjoy a good discussion that doesn't devolve into a flamewar.
Let's establish some objective benchmarks for general-purpose programming languages. Can we agree that it's better for a language to be consistent than not? That it's better to be expressive (as opposed to requiring verbose constructs for simple ideas)? Can we agree that separating code into separate namespaces and modules is a fundamentally good idea? Can we say that "spooky action at a distance" is generally bad? Of course, we should include the each with which a language is learned there too.
A language can't optimize for all these at once, so there's always a tradeoff. Perl trades virtually everything else for expressiveness. Java focuses on consistency. Python, a balance of consistency and expressiveness that you could call aesthetic.
PHP's focus is on being as easy as possible to pick up for the inexperienced programmer who just wants to get his personal task done without having to learn too much about the language.
Consider two animals: animal A reproduces by spawning, and easily has 10,000 offspring. Let's say 0.01% of these offspring go on to reproduce, for an average of 10 offspring per animal A. Now consider an animal B that rears 3 offspring, 90% of which survive to have offspring of their own. In the same niche, animal A will have a huge reproductive advantage over animal B, and animal A will drive B out of its niche in a few generations, ignoring other considerations.
Despite each B being better (say, more intelligent, stronger, faster, etc.), the niche A and B are competing in doesn't require the animal to be better. A is better off, since it devotes its resources to reproducing faster instead of being better individually. If that niche were more demanding, B might be better off.
Now translate that idea into programming language terms. PHP is very easy to pick up for the "n00b", giving it a huge reproductive advantage over other languages. Since PHP is so easy to pick up for mediocre programmers, the typical programmer using PHP will be mediocre. It's not that good people don't use PHP, but that these good people are vastly outnumbered.
Yet PHP is astoundingly successful. What does that tell us?
Most web programming is not hard. The niche is not demanding. PHP, the meme, is better off sacrificing being a "good" language so it can spread, and even in its weakened form, it's more than up for the task. PHP is a more fit language for web programming in an overall sense, if not an individual one.
I'm not arguing that the language designers consciously designed it that way, by the way. I'm merely arguing that that's how it happened. When I say that PHP "wants" this or that, I'm just drawing a metaphor.
Other programming niches, by the way, are more demanding. You'd be hard-pressed to find a language like PHP in, say, compiler-writing. There, the task is harder, so the language, and thus the programmers, are hardier. "Better" languages are more fit for these more demanding niches.
We don't look down on PHP because we secretly desire to be esoteric code-wizards. Instead, we look down on PHP because it's like using a rock to pound in a nail: there are objectively better ways to do what it does, and people who use PHP almost universally use it only out of ignorance.
We try to combat ignorance, but when the people you attempt to educate do nothing but resist new notions, the only response that's left is pity.
You're arguing by assertion. You tell us that it's faster to do these things in the kernel. I asked how that is, and you're now responding by saying, again, that it's faster in the kernel.
URL parsing is string manipulation, and that's going to happen at the same speed in userspace.
"Queuing" seems a little vague, but if it's TCP connection queuing you're talking about, that's always been done in kernel space. "TCP/IP interfacing," likewise, has always been done in kernel space too. See the listen man page (or MSDN documentation section -- winsock works the same way.)
Caching is a function of the page cache. The most recently used disk blocks are already in kernel memory, and are already cached. The kernel will send that cached data using open, then write, splice, sendfile, etc. Did you have a different meaning of "caching" in mind?
What's the benefit of doing basic HTTP in kernel mode then? You still have to hand the data off to userspace before actually handling the request, and parsing headers won't go any faster in kernelspace than in userspace.
The benefit of running in the kernel is that system call overhead is nil. If what you're doing in the kernel doesn't save on syscalls, then you're better off moving it to userspace for safety. Doing bare-bones HTTP in the kernel smells to me like either a gimmick or some kind of nasty scheduler workaround, not a bona fide performance technique.
What TUX does is do the whole thing in kernel space, at least for static content.
I'm still not sure what you're after that the free software world. If it's raw performance you're after (even though it's not really necessary), there are alternatives to Apache, like lighttpd. If it's GUI management, well, just try the config file. It's much easier to work with than any GUI tool I've worked with.
That depends on whether he has co-workers.
Please, man, realize that plenty of people use languages other than PHP and database engines other than MySQL. I suspect a lower fraction of people use PHP on Apache than use ASP.NET with IIS. I wish I had numbers to back this up though.
When I use mod_rewrite, I always make sure to turn on maximum logging for the first couple minutes so I can make sure my configuration is sane. With that logging on, I haven't found a mod_rewrite problem I couldn't figure out in a few minutes: the logging tells you every step the thing takes, and it's pretty easy to figure out what rule is problematic.
:-)
That said, the configuration file syntax for mod_rewrite sucks. But that's life. Personally, I prefer just letting a single base script parse PATH_INFO on its own rather instead of going through mod_rewrite. Then again, I like Tapestry, so take my opinions with a grain of salt.
Performance isn't really a problem when using Apache.
Okay, when you serve a request, you're either running a program (in some way) to generate the content, or you're serving something already on disk, using the webserver itself.
In the first case, dynamic content, the specifics of the server are going to be lost in the noise. We benchmarked my company's webserver overhead at 3ms on a 100ms request, and that's pretty typical of web applications. Getting that down to 2ms is not going to increase overall performance much.
In the second case, that of static content, there are much better servers than Apache anyway. For the sake of argument, I'll grant that IIS is twice as fast as Apache at serving static content. But it doesn't matter! Serving static content is still much faster than serving those dynamically-generated pages. A client is likely to spend far more time waiting for dynamic page generation and actual HTTP transfers than waiting for the server to start sending a static file.
And static content is instantly clusterable as well, since there's no state. logo2.png doesn't need to hit the database, I imagine, and if you're big enough to care about static content performance, you're big enough to get more than one machine anyway.
What is boils down to is that Apache is free, Free, and flexible. IIS may have improved in the latter lately, but it's hard to imagine something that can't be accomplished with Apache's module system. You can even strip it down to being able to serve bare HTTP requests, if you'd like, but why would you ever want to?
Two articles:
Experiences of using PHP in Large Websites: from 2002, but the basic PHP philosophy hasn't changed since then (although some specifics have). Oversimplification and pandering to less experienced developers hurts the language as a whole.
PHP in Contrast to Perl. From the table of contents:
It's not that PHP is that bad. VB, COBOL and PL/1 were all much worse. It's that there are better languages out there that people never learn because they learned PHP as "n00bs" (you can almost detect a PHP developer by his use of that word) and are complacent with it.
Incidentally, I think it's a lot more mind-expanding to learn two programming languages than to learn one. I see single-language people all the time confusing possibility with possibility in a particular language, or confusing overall algorithms and data structures with particular idioms from their pet language. It's sad.
During the middle ages and the renaissance, small professional armies fought pre-arranged battles with minimal collateral damage (ignoring the effects of sieges, of course). But before that period, Rome and the ancient Greeks often practiced total war: look at what happened to the Celts and the Trojans.
There's no overall cycle. Who knows whether we'll swing back into a phase of total war? This time, however, it might be the end of us -- the one trend I do see is that every time we try total war, it gets more destructive.
Read A Canticle for Liebowitz .
Joe: For the last time, I'm pretty sure what's killing the crops is this Brawndo stuff.
Secretary of State: But Brawndo's got what plants crave. It's got electrolytes.
Attorney General: So wait a minute. What you're saying is, you want us to put WATER on the crops?
Joe: Yes.
Attorney General: Water?? Like, outta the toilet?
Joe: Well, I mean... It doesn't have to be out of the toilet. But yeah, that's the idea.
Secretary of State: But Brawndo's got what plants crave.
Attorney General: Yeah, it's got electrolytes.
Joe: Okay, look. The plants aren't growing. So I'm pretty sure that this Brawndo stuff's not working. Now I'm no botanist, but I do know that if you put water on plants they grow.
Secretary of Energy: Well, I never seen no plants grow outta no toilet.
Secretary of State: Hey, that's good! You sure *you* ain't the smartest guy in the world?!
Joe: Okay, look. You want to solve this problem and I want to get my pardon. So - why don't we just try it, okay, and not worry about what plants crave?
Attorney General: But Brawndo's got what plants crave.
Secretary of Energy: Yeah. It's got electrolytes.
Joe: What are electrolytes? Do any of you even know?
Secretary of State: It's what they use to make Brawndo.
Joe: Yeah, but, why do they use them to make Brawndo?!
Secretary of Defense: Cuz Brawndo's got electrolytes.
Of course we're dorks. After all, that's why we're here!
Sure: to provide justification for your own job.
Are you saying that anyone not an "anal security type" is running as root? What the hell? Do you drive a car without brakes too?
Interesting. What were the intended provisions then?
Okay, say I live-blog a game. The MLB (or the stadium owners, or whoever) can eject me, but what I'm doing is not illegal, and the MLB has no legal recourse other than ejection.
Yes, an ad hominem attack based on an omitted word is clearly the mark of seasoned maturity. Applying your standards to LKML posts, Linus must be three.
Now, getting back to the substance of the argument, I'm not advocating the abolition of copyright; I don't think many are. However, quite a few people are beginning to see the harm caused by excessively long copyright terms and brutal restrictions on personal use, and I suspect they'll change copyright law sooner or later.
As far as Hollywood goes, reducing copyright terms and allowing personal, not-for-profit sharing will not result in a decline in the number of films created. The de facto situation today is that anyone interested can find almost any film he wants online. Yet, people still pay for theater tickets and DVDs. I certainly do.
In a larger sense, it doesn't matter whether weakening copyright will result in changes (or even a decline) in the commercial arts. An entire generation has grown up believing that file sharing is not wrong; more people know about our outrageously long copyright terms than ever before. Those who depend on excessive copyright will have to adapt or perish.
Rant all you want, but society has spoken. I'm 22. Damn near everybody in my generation doesn't file trading wrong. Assuming that we maintain our republic, the government will eventually respond to democratic opinion and weaken copyright. Corporate content creators will have to adapt or perish.
Really, the only thieves are the powerful corporations who maintain an ironclad, if weakening, grip on what ought to be in the public domain by now anyway.
Google is already complying with the letter of the DMCA. What right does any other organization have to compel Google to go beyond that and spend a fortune creating a video fingerprinting system? Google ought to be fighting this, not bending over and doing whatever large media companies demand.
Doing this is manifestly against the interest of the people who made Google what it is today. What happened to doing no evil?
Under what law? It sounds insane that simply telling somebody a non-top-secret fact is a felony -- and I don't imagine that bank tellers get security clearances when they're hired.
So, again, what law makes it a felony to tell a bank customer what will trigger reporting? More generally, where can one find a complete list of things tellers may and may not do and say?
Which is why the ACLU defended neo-nazis. Riiiight. The fact is that, these days, it's not about liberals versus conservatives, about the left versus the right.
Today, the battle is between authoritarianism and liberty, and the ACLU is firmly on the side of the latter. It's not a problem that the authoritarians are masquerading as the party of conservative thought and traditional values, when in fact they support neither. Today, being on the left means simply being against authoritarianism, and for basic human rights. The ACLU having a left-leaning bias is laudable, not lamentable.
What's to stop the user from running an arbitrary number of these helper processes?