Remember that industrially productive bees on which we rely for farming are routinely transported under stress from site to site, often via major public roads with good cell phone service. As we know from other examples of radiation exposure, the effects of exposure need not be instant to be substantial.
The small cults make the news, while most members of most spiritualities do not. Islam is not unique.
OKC was done by a small cult of Christians. Waco was by two. The threats against the Danish cartoonist and South Park were made by a small group out of 1.6 billion Moslems who may have been offended, but not enough to take action. The entire Israel situation is explicitly state-sponsored religious violence, as was Northern Ireland. Tibet, India, and Pakistan have shown that the Eastern faiths can get into it as well.
All this has occurred in the last 20 years, spanning faiths in which over 80 per cent of the world's population participate. And yet all the actively violent faith-mongers from all faiths worldwide at any one time would probably not fill a professional football stadium.
I don't think it is at all unreasonable to expect that a lawyer SHOULD be able to definitively answer the question "is it legal if I...". It's also reasonable to expect the law to at least be self consistent.
As long as contradictions exist in the explicitly defined rules, it would be possible to construct many circumstances in which a particular action would be legal, and many circumstances in which that same action would not be legal. And then you add ethics which rules may not be possible to formally specify.
You've identified a difference in scope, not a difference in kind. Even with a complete copy of source code for all software on something as simple as a graphing calculator, the algorithms encoded therein need to be interpreted by some human or non-human hardware having various degrees of ambiguity about the accuracy and precision. Only at very small scales is the upkeep cost of keeping a full working conceptual model recouped by the benefits since the number of possible interactions and unanticipated interactions between rules grows approximately as the factorial of the number of rules in the system.
As with laws, once you connect sets of algorithms and interpretations, models quickly become hairy. Once you add networks whose nodes have states and rules varying with external conditions and the condition of the network itself, you wouldn't be able to observe the system at any instant (start with clock skew and speed of light issues) in any comprehensive way, let alone "say exactly what it is"./Heisenberg'ed
Public and private broadcasters and publishers have exercised self-censorship on religious or other grounds for as long as independent media have existed. To legislatively forbid broadcasters and publishers from exercising editorial control over their content would entitle any entity to exercise their speech at another's expense.
It would not be generally desirable for me to be able to force all broadcasters and publishers to carry my message that "buy my used cars, time shares, and discount penis enlargement creams because the gods are offended by the ill-thought arguments by people named Imrik and their friends" etc. for the only reason that I namedropped a religious element into my speech.
Schools teach many skills which aren't explicitly on any syllabi or assignment, not the least of which are copy and paste, and ethanol appreciation. I'm sure a plurality of universities produce high quality CS graduates, but most of the A and A- graduates from the five major universities within 200 miles in the last decade or so did not appear to be of that variety. There were a few gems, to be sure, but they had unremarkable academic careers.
I've mostly retired from IT in the last two years, but the recent graduates I run into at the usual industry groups and events still complain about being forced to choose in fourth year one of: their first experience with LDAP, their first experience with SQL, "system administration", how to write malware, or history of computing. They admit that the majority of their cohort have graduated without any substantial exposure to some major concepts and basic tools of the trade.
I'd be glad to introduce any good resources you may know of with respect to "how to recruit talent" to the local and regional industry groups since everyone from 10-person consultancies up to the local branches of the big three letter global services companies are all hurting for skilled grads.
I never said that I was annoyed with teaching. (Unlike some people in *-dev) I find it quite enjoyable to ensure that the people coming up have the skills not just to take over the current operations, but to build and improve on it to meet future needs, especially if they don't blindly accept the current paradigms.
It's a good thing that the remains of my pile of undocumented code and wonky infrastructure configurations built on best (and worst) practices from a few generations of technology and knowledge ago inspires the young ones to do it better using what we know now. And in 30 years, their mistakes (whatever those will be*) will in turn teach the next generation.
* My guesses: you won't know what good parallelized/distributed/cloud code looks like for another 5-10 years; you will URIs (and their shorteners) as foreign keys to the bazillion local stores when things like BigTable top out; and you will regret sacrificing any-to-any connectivity for big pipes to favored content of little to no new information value.
(Authentication, authorization and accounting: Basic security that, if learned and implemented consistently by people working with computers, would make the Interwebs a much safer place.)
In a previous career, one of our hardware/software bundles unexpectedly sold well to the military. Although AAA would normally have no reason to go through our product, some of our SENGs and EEs had to quickly learn to troubleshoot and design for bad things that can happen to computing devices with the military in physically hostile environments.
Bringing this back to the Linux kernel, I'm glad that LM78 support finally works better for some real-time applications than external instruments feeding serial data...
> Maybe it's because there are basically ZERO jobs in most places for real hard-core CS.
There are close to zero jobs for hard-core anything, but that's not the goal of earning or producing a BA/BSc in CS.
The most important goal of a university degree program is to teach students how to think critically, how to evaluate and apply information, and how to perceive and act professionally outside themselves. Theoretical knowledge is helpful not because industry does a lot of relational algebra or computability analysis directly, but because CS graduates should be able to make a critical business case that an Oracle implementation would be better/worse than a Sybase implementation for a particular use.
Local technical/trade school graduates can and should easily out implement degree holders in identical fields. If the post-secondary education market is segmented ideally, CS graduates should be have the knowledge and conceptual tools to run rings around technical graduates in terms of understanding and designing principles and solutions in a broader corporate or societal context. As it stands, recent crops of technical graduates seem to understand more about both what they're doing locally, how they got there, and why they're doing it in the community, than the CS graduates who seem weak with both theory and implementation. Some of my colleagues have been seeking out CCNAs, biologists, and ex-military officers, and training them to program because they have better tools to understand systems and business context than recent CS graduates (who/should/ be able to apply the "science" part of their tools to figure it out).
Relating this back to the Linux kernel, good luck finding a recent CS graduate who understands that MPLS exists, let alone one who can grok the concept (let alone specifications) well enough to understand why Linux will want to support MPLS if it wants not to be locked out of an important part of the enterprise market relating to the current network neutrality debate. (Incidentally, I've pointed some international relations friends at the Wikipedia page who understood the consequences immediately.)
Perhaps there should be a return from quantity to quality in undergraduate CS programs.
The unfortunate reality is that a graduate who only knows Java or previous flavours of the week (I've seen resumes where the candidate was apparently able to do an entire CS program in Pascal...) but not how to program will get shoved into a helpdesk position. But neither the graduate nor the company wants that since individuals smart enough to grok enough of the mechanics of one language to get a degree usually want more stimulation shortly after they've received 3-6 months of (expensive to the company) training. My preference has always been to throw demonstrated adaptable individuals (not necessarily CS or any kind of graduate) into situations where their main challenge is to learn and grow the business as opposed to having to struggle to think outside their previous tools. But YMMV since headhunters and HR seek specific, often meaningless to actual business, words on paper for CYA purposes.
Separately, I have a dream where CS departments stop teaching industry tools from a decade ago, and where industry doesn't have to teach information theory, BA, maths, and computability.
The bigger problem appears that CS programs now focus on teaching tools and how to Google as opposed to thinking or problem solving, in order to meet perceived industry demand. In industry, I've had to teach too many youngling graduates about basic data structure and database concepts, memory and hardware addressing, protocol encapsulation, AAA, synchronous vs asynchronous operation, and other fundamentals which would be needed to understand why things such as kernels are implemented as they are. The way in which FOSS support forums and listservs generally respond to noob developer and user questions--some variation of RTFS without providing a way of understanding which documentation to read--does not invite exploration of concepts embedded in the current software architecture, let alone ways to identify entry points into interesting sub-components. This is a barrier since popular CS program tools to which students are exposed, such as RHEL, gcc, etc. are provided as finished products in the same way as Access or BOS.
Separately, I have a dream where all of the Alans Cox get together to write an operating system.
You are, ReactOS, the core of wine, do you think you know me? So I, ReactOS, Linux will, Linux training centers, wine, or: Please refer to the translated version. It shows how to return. What should I do? Seems like a waste of time. English Harry Potter is a favorite to qualify for a return to Japan. It may be interesting, it loses something in translation.
I my applications are "originally written in" in neurons, which requires the use of intermediate code being expressed in various languages on whiteboards, notebooks, conversations, etc. before any code reaches C or other language. I guess I won't be writing any iPhone apps.
Alternatively, i could interpret the clause in the new agreement to mean that they don't want runtime translation/compilation to avoid sucking battery power when (their) tools are available to correctly compile once against the target.
At any rate, I don't imagine that it will be long before someone distributes the Flash player as a bunch of (obfuscated) C classes or libraries or some such (perhaps as an on-line service) which a developer could then paste into Apple's developer tools, along with a byte-code or other pastable representation of the Flash program which would then be compiled by the allowed Apple tools into a native binary.
You've provided a reasonable explanation of the how some (most?) users perceive the features of the product, and yet, it was marked 'Troll' because the perspective apparently disagrees with the Firefox groupthink. That's interesting, and possibly ultimately fatally wounding, if Firefox doesn't start to understand how the market has shifted since its glory days.
History has shown that visionaries rarely lead beyond the first revolution in any field, so it will be interesting to see for how long Mozilla drags on in ignorance or defiance of dissenting market signals such as those you've provided.
Java, JavaScript, HTML, XML, C++, C, Tcl, CSS, Visual C++ (never again), Postscript, Pascal, Perl, sh, Visual Basic, PHP, SmallTalk, SQL, REXX, WSH, AppleScript, regular expressions/enabled 11x growth in client base, 2x increase in customer satisfaction, 0.5x deployment and support costs as ex-product manager for a multinational software/hardware concern, but I wouldn't necessarily hire myself as a programmer
On your next call, notice the lengths of dead air on both sides. Or, maybe you've already noticed the cuts to dead silence on calls through poorly-configured VoIP trunks.
The stuff that everyone knows about or can anticipate will not be ineffective for long, but those in the industry who actually do basic science research have to keep the free-riders at bay, or better yet, to keep goading them sinking more capital into old tech. That's how those who know what they're doing can keep charging extortionate premiums for the next big undeployed things, even though we all know what they will be. Strategic information disclosures (perhaps not unlike this one) and behind the curtain help from some advertisers to some ad block software developers are all part of the game.
The next on-line advertising paradigm is designed to decrease the social and cognitive distance between content and advertising, to the extent that the response rates in trials so far are being called the next best thing to word of mouth advertising. It ignores the part of the infrastructure to which ad blockers are ttached, but also insidiously takes advantage of the lowered guard of individuals who choose to use ad blockers and think they're effective. Of course, the new tech won't be deployed until we've watched the current players on both sides invest many more millions to deeply screw themselves into the last five percent of the current obsolete and decreasingly effective model.
In other words, if you're still fighting on either side of ad blockers, you're either not seriously in the game, or have otherwise already lost.
I don't think that I disclosed anything that was not already anticipated to occur within 18 months in any competent strategic plan on either side. I could understand you being upset had I posted in public about interleaving.
> But, with this script, everything is happening on the user's computer, and Facebook has no jurisdiction over that.
Not everything is happening on the users' computers since the script may determine what is or is not requested from the Facebook servers.
I think the essential difference between this and WoW would be a requirement that the user must actively meet (downloading ads and other cruft) vs. a prohibition against what the user may do (run auto-aim scripts) with their computers in conjunction with the service. A good number of universities contractually require users of private computers to run anti-virus software when connected to the campus network.
If Facebook is like a publisher, they should have no control over how users retain or discard parts of the bundle (like TiVO). If Facebook is like a retailer, an argument might be that a user stripping out arbitrary content, like paying for an entire newspaper but only taking the front section, leaves the retailer with the burden of disposing of unsalable product at the retailer's expense. Users who do not receive ads or app notifications are in some ways unsalable for Facebook. Based on the almost absolute lack of amputated newspapers being left behind in unattended newspaper boxes, consumers do not appear to believe that its good practice to burden retailers or other customers in that manner.
Since Facebook is neither strictly a publisher, nor strictly a retailer, considering a broader class might be instructive.
In general, software and interfaces are designed to permit only actions which are explicitly intended, rather than denying specific actions although denying kinds of actions is common. We've accepted that terms of service should contain restrictions like "use for work-related purposes only, do not use for illegal purposes", but not exhaustive exclusions like "do not use for pornsite1..n, spamming software1..n, botnet control software1..n". This makes sense from the sysadmin perspective and need not be further argued. But as users, we may sometimes enjoy pushing the limits in the TOS and seek exceptions, but we rarely concentrate to change policies despite being afforded the opportunity to do so.
Generally, then, Facebook's position is rational and reasonable given our societal norms, as is the position to oppose Facebook's actions without seeking to materially harm Facebook.
Yes, mod_rewrite, dynamic resource URIs, and stupid proxy tricks to serve ads out of the same directories as content etc. would still allow load balancing and other technical performance management and scalability, but that's when we all pretend to be mobile or other kinds of browsers which screws up the metrics and hence reduces the value of ad placements.
The same solution applies even without the special sensors since client software would have to be retrofitted or spywared to capture and transmit whatever new data they're collecting about keypresses. In addition, if their method claims to identify particular individuals, such measures would encounter regulatory hurdles and disclosures around collecting/using/sharing/storing additional PII non-essential to the competent operation of messaging services.
Slashdot Mirror
Remember that industrially productive bees on which we rely for farming are routinely transported under stress from site to site, often via major public roads with good cell phone service. As we know from other examples of radiation exposure, the effects of exposure need not be instant to be substantial.
The small cults make the news, while most members of most spiritualities do not. Islam is not unique.
OKC was done by a small cult of Christians. Waco was by two. The threats against the Danish cartoonist and South Park were made by a small group out of 1.6 billion Moslems who may have been offended, but not enough to take action. The entire Israel situation is explicitly state-sponsored religious violence, as was Northern Ireland. Tibet, India, and Pakistan have shown that the Eastern faiths can get into it as well.
All this has occurred in the last 20 years, spanning faiths in which over 80 per cent of the world's population participate. And yet all the actively violent faith-mongers from all faiths worldwide at any one time would probably not fill a professional football stadium.
I don't think it is at all unreasonable to expect that a lawyer SHOULD be able to definitively answer the question "is it legal if I...". It's also reasonable to expect the law to at least be self consistent.
As long as contradictions exist in the explicitly defined rules, it would be possible to construct many circumstances in which a particular action would be legal, and many circumstances in which that same action would not be legal. And then you add ethics which rules may not be possible to formally specify.
You've identified a difference in scope, not a difference in kind. Even with a complete copy of source code for all software on something as simple as a graphing calculator, the algorithms encoded therein need to be interpreted by some human or non-human hardware having various degrees of ambiguity about the accuracy and precision. Only at very small scales is the upkeep cost of keeping a full working conceptual model recouped by the benefits since the number of possible interactions and unanticipated interactions between rules grows approximately as the factorial of the number of rules in the system.
As with laws, once you connect sets of algorithms and interpretations, models quickly become hairy. Once you add networks whose nodes have states and rules varying with external conditions and the condition of the network itself, you wouldn't be able to observe the system at any instant (start with clock skew and speed of light issues) in any comprehensive way, let alone "say exactly what it is". /Heisenberg'ed
In fairness, the graph pictured in NYT is only 10% of the size of Google's roadmap:
http://www.freedomlab.org/wp-content/uploads/2007/06/google_whiteboard.jpg
it might actually be illegal to censor it...
No.
Public and private broadcasters and publishers have exercised self-censorship on religious or other grounds for as long as independent media have existed. To legislatively forbid broadcasters and publishers from exercising editorial control over their content would entitle any entity to exercise their speech at another's expense.
It would not be generally desirable for me to be able to force all broadcasters and publishers to carry my message that "buy my used cars, time shares, and discount penis enlargement creams because the gods are offended by the ill-thought arguments by people named Imrik and their friends" etc. for the only reason that I namedropped a religious element into my speech.
Schools teach many skills which aren't explicitly on any syllabi or assignment, not the least of which are copy and paste, and ethanol appreciation. I'm sure a plurality of universities produce high quality CS graduates, but most of the A and A- graduates from the five major universities within 200 miles in the last decade or so did not appear to be of that variety. There were a few gems, to be sure, but they had unremarkable academic careers.
I've mostly retired from IT in the last two years, but the recent graduates I run into at the usual industry groups and events still complain about being forced to choose in fourth year one of: their first experience with LDAP, their first experience with SQL, "system administration", how to write malware, or history of computing. They admit that the majority of their cohort have graduated without any substantial exposure to some major concepts and basic tools of the trade.
I'd be glad to introduce any good resources you may know of with respect to "how to recruit talent" to the local and regional industry groups since everyone from 10-person consultancies up to the local branches of the big three letter global services companies are all hurting for skilled grads.
I never said that I was annoyed with teaching. (Unlike some people in *-dev) I find it quite enjoyable to ensure that the people coming up have the skills not just to take over the current operations, but to build and improve on it to meet future needs, especially if they don't blindly accept the current paradigms.
It's a good thing that the remains of my pile of undocumented code and wonky infrastructure configurations built on best (and worst) practices from a few generations of technology and knowledge ago inspires the young ones to do it better using what we know now. And in 30 years, their mistakes (whatever those will be*) will in turn teach the next generation.
* My guesses: you won't know what good parallelized/distributed/cloud code looks like for another 5-10 years; you will URIs (and their shorteners) as foreign keys to the bazillion local stores when things like BigTable top out; and you will regret sacrificing any-to-any connectivity for big pipes to favored content of little to no new information value.
More importantly there are plenty of unexplored function libraries in the 1 billion marine microbial species waiting to activate.
http://en.wikipedia.org/wiki/AAA_protocol
(Authentication, authorization and accounting: Basic security that, if learned and implemented consistently by people working with computers, would make the Interwebs a much safer place.)
In a previous career, one of our hardware/software bundles unexpectedly sold well to the military. Although AAA would normally have no reason to go through our product, some of our SENGs and EEs had to quickly learn to troubleshoot and design for bad things that can happen to computing devices with the military in physically hostile environments.
Bringing this back to the Linux kernel, I'm glad that LM78 support finally works better for some real-time applications than external instruments feeding serial data...
> Maybe it's because there are basically ZERO jobs in most places for real hard-core CS.
There are close to zero jobs for hard-core anything, but that's not the goal of earning or producing a BA/BSc in CS.
The most important goal of a university degree program is to teach students how to think critically, how to evaluate and apply information, and how to perceive and act professionally outside themselves. Theoretical knowledge is helpful not because industry does a lot of relational algebra or computability analysis directly, but because CS graduates should be able to make a critical business case that an Oracle implementation would be better/worse than a Sybase implementation for a particular use.
Local technical/trade school graduates can and should easily out implement degree holders in identical fields. If the post-secondary education market is segmented ideally, CS graduates should be have the knowledge and conceptual tools to run rings around technical graduates in terms of understanding and designing principles and solutions in a broader corporate or societal context. As it stands, recent crops of technical graduates seem to understand more about both what they're doing locally, how they got there, and why they're doing it in the community, than the CS graduates who seem weak with both theory and implementation. Some of my colleagues have been seeking out CCNAs, biologists, and ex-military officers, and training them to program because they have better tools to understand systems and business context than recent CS graduates (who /should/ be able to apply the "science" part of their tools to figure it out).
Relating this back to the Linux kernel, good luck finding a recent CS graduate who understands that MPLS exists, let alone one who can grok the concept (let alone specifications) well enough to understand why Linux will want to support MPLS if it wants not to be locked out of an important part of the enterprise market relating to the current network neutrality debate. (Incidentally, I've pointed some international relations friends at the Wikipedia page who understood the consequences immediately.)
Perhaps there should be a return from quantity to quality in undergraduate CS programs.
The unfortunate reality is that a graduate who only knows Java or previous flavours of the week (I've seen resumes where the candidate was apparently able to do an entire CS program in Pascal...) but not how to program will get shoved into a helpdesk position. But neither the graduate nor the company wants that since individuals smart enough to grok enough of the mechanics of one language to get a degree usually want more stimulation shortly after they've received 3-6 months of (expensive to the company) training. My preference has always been to throw demonstrated adaptable individuals (not necessarily CS or any kind of graduate) into situations where their main challenge is to learn and grow the business as opposed to having to struggle to think outside their previous tools. But YMMV since headhunters and HR seek specific, often meaningless to actual business, words on paper for CYA purposes.
Separately, I have a dream where CS departments stop teaching industry tools from a decade ago, and where industry doesn't have to teach information theory, BA, maths, and computability.
The bigger problem appears that CS programs now focus on teaching tools and how to Google as opposed to thinking or problem solving, in order to meet perceived industry demand. In industry, I've had to teach too many youngling graduates about basic data structure and database concepts, memory and hardware addressing, protocol encapsulation, AAA, synchronous vs asynchronous operation, and other fundamentals which would be needed to understand why things such as kernels are implemented as they are. The way in which FOSS support forums and listservs generally respond to noob developer and user questions--some variation of RTFS without providing a way of understanding which documentation to read--does not invite exploration of concepts embedded in the current software architecture, let alone ways to identify entry points into interesting sub-components. This is a barrier since popular CS program tools to which students are exposed, such as RHEL, gcc, etc. are provided as finished products in the same way as Access or BOS.
Separately, I have a dream where all of the Alans Cox get together to write an operating system.
Via:
http://translationparty.com/#7203078
http://translationparty.com/#7203083
http://translationparty.com/#7203094
Apple's marketing fodder claims the iPad creates a new market...
I my applications are "originally written in" in neurons, which requires the use of intermediate code being expressed in various languages on whiteboards, notebooks, conversations, etc. before any code reaches C or other language. I guess I won't be writing any iPhone apps.
Alternatively, i could interpret the clause in the new agreement to mean that they don't want runtime translation/compilation to avoid sucking battery power when (their) tools are available to correctly compile once against the target.
At any rate, I don't imagine that it will be long before someone distributes the Flash player as a bunch of (obfuscated) C classes or libraries or some such (perhaps as an on-line service) which a developer could then paste into Apple's developer tools, along with a byte-code or other pastable representation of the Flash program which would then be compiled by the allowed Apple tools into a native binary.
You've provided a reasonable explanation of the how some (most?) users perceive the features of the product, and yet, it was marked 'Troll' because the perspective apparently disagrees with the Firefox groupthink. That's interesting, and possibly ultimately fatally wounding, if Firefox doesn't start to understand how the market has shifted since its glory days.
History has shown that visionaries rarely lead beyond the first revolution in any field, so it will be interesting to see for how long Mozilla drags on in ignorance or defiance of dissenting market signals such as those you've provided.
As neither an engineer nor a programmer:
DOS, Windows, Linux, OS X, AIX, OS/2, BeOS
Java, JavaScript, HTML, XML, C++, C, Tcl, CSS, Visual C++ (never again), Postscript, Pascal, Perl, sh, Visual Basic, PHP, SmallTalk, SQL, REXX, WSH, AppleScript, regular expressions /enabled 11x growth in client base, 2x increase in customer satisfaction, 0.5x deployment and support costs as ex-product manager for a multinational software/hardware concern, but I wouldn't necessarily hire myself as a programmer
So why didn't you submit more patches to, or fork, Songbird to make it better?
On your next call, notice the lengths of dead air on both sides. Or, maybe you've already noticed the cuts to dead silence on calls through poorly-configured VoIP trunks.
The stuff that everyone knows about or can anticipate will not be ineffective for long, but those in the industry who actually do basic science research have to keep the free-riders at bay, or better yet, to keep goading them sinking more capital into old tech. That's how those who know what they're doing can keep charging extortionate premiums for the next big undeployed things, even though we all know what they will be. Strategic information disclosures (perhaps not unlike this one) and behind the curtain help from some advertisers to some ad block software developers are all part of the game.
The next on-line advertising paradigm is designed to decrease the social and cognitive distance between content and advertising, to the extent that the response rates in trials so far are being called the next best thing to word of mouth advertising. It ignores the part of the infrastructure to which ad blockers are ttached, but also insidiously takes advantage of the lowered guard of individuals who choose to use ad blockers and think they're effective. Of course, the new tech won't be deployed until we've watched the current players on both sides invest many more millions to deeply screw themselves into the last five percent of the current obsolete and decreasingly effective model.
In other words, if you're still fighting on either side of ad blockers, you're either not seriously in the game, or have otherwise already lost.
I don't think that I disclosed anything that was not already anticipated to occur within 18 months in any competent strategic plan on either side. I could understand you being upset had I posted in public about interleaving.
> But, with this script, everything is happening on the user's computer, and Facebook has no jurisdiction over that.
Not everything is happening on the users' computers since the script may determine what is or is not requested from the Facebook servers.
I think the essential difference between this and WoW would be a requirement that the user must actively meet (downloading ads and other cruft) vs. a prohibition against what the user may do (run auto-aim scripts) with their computers in conjunction with the service. A good number of universities contractually require users of private computers to run anti-virus software when connected to the campus network.
If Facebook is like a publisher, they should have no control over how users retain or discard parts of the bundle (like TiVO). If Facebook is like a retailer, an argument might be that a user stripping out arbitrary content, like paying for an entire newspaper but only taking the front section, leaves the retailer with the burden of disposing of unsalable product at the retailer's expense. Users who do not receive ads or app notifications are in some ways unsalable for Facebook. Based on the almost absolute lack of amputated newspapers being left behind in unattended newspaper boxes, consumers do not appear to believe that its good practice to burden retailers or other customers in that manner.
Since Facebook is neither strictly a publisher, nor strictly a retailer, considering a broader class might be instructive.
In general, software and interfaces are designed to permit only actions which are explicitly intended, rather than denying specific actions although denying kinds of actions is common. We've accepted that terms of service should contain restrictions like "use for work-related purposes only, do not use for illegal purposes", but not exhaustive exclusions like "do not use for pornsite1..n, spamming software1..n, botnet control software1..n". This makes sense from the sysadmin perspective and need not be further argued. But as users, we may sometimes enjoy pushing the limits in the TOS and seek exceptions, but we rarely concentrate to change policies despite being afforded the opportunity to do so.
Generally, then, Facebook's position is rational and reasonable given our societal norms, as is the position to oppose Facebook's actions without seeking to materially harm Facebook.
Yes, mod_rewrite, dynamic resource URIs, and stupid proxy tricks to serve ads out of the same directories as content etc. would still allow load balancing and other technical performance management and scalability, but that's when we all pretend to be mobile or other kinds of browsers which screws up the metrics and hence reduces the value of ad placements.
The same solution applies even without the special sensors since client software would have to be retrofitted or spywared to capture and transmit whatever new data they're collecting about keypresses. In addition, if their method claims to identify particular individuals, such measures would encounter regulatory hurdles and disclosures around collecting/using/sharing/storing additional PII non-essential to the competent operation of messaging services.