The MacBook weighs 5.1 lbs. The ThinkPad X60 weighs 3.1 (small battery; 3.6 with 8-hour battery). That's what you're paying for.
When I was shopping for laptops I wanted to look at Macs, but my weight requirement threw them all out of the running. I ended up getting an X60s which weighs 2.7 lbs (3.3 with big battery), and every time I carry it I'm glad I did. IMHO the long-rumored MacBook Thin can't come soon enough.
You say that as if an energy storage medium with size, weight, and durability, and power to match the gasoline engine wasn't a major breakthrough that could have enormous benefits for society. In fact, energy storage and transport is just as important as generation, but has seen a lot less practical advancement in the last 50 years.
As a society we desperately need improvements to energy storage. Better storage means we can use more efficient and cleaner means of generation. We will probably never have fission reactors in our cars, but with this tech the energy our cars use can come from fission anyway. That's a breakthrough worth celebrating.
Well, up until now just rendering the realistic facial expressions on an in-game model in real time was out of reach. Until now, you couldn't even make a decent game version of Shrek. So it's a big step. Sure, any expressions lip-synced with dialog still need to be hand-animated, but the dialogue itself needs to be pre-recorded as well anyway for the foreseeable future. The days of generated dialogue certainly are a long way off. But that's not what I meant when I said "procedural animation system", I was talking more about basic things like convincing eye and head movements and walking with proper weight transfer and without feet sliding across the floor, which no game has yet gotten completely right. (Walking and especially turning animations are my pet peeve; we ought to be able to do better than linear interpolation between keyframes. We spend so much time making the still screenshots look pretty and then use the same old animation systems that make people walk like retarded robots.)
Just having characters show convincing surprise, fear, and happiness at appropriate times is a huge step forward. As an example, imagine in Halo that after a harrowing fight, one marine breaks down crying over a fallen comrade. That's something that just wouldn't work at all with the generic stoic expression they all share now. A scene like that could add a lot of emotional depth, even if it was completely pre-scripted and randomly-triggered just like the little random quips that they currently make after combat. If you go crazy and start killing your fellow marines, you should see the surprise, fear, and hatred on their faces instead of just hearing it in their voice lines. It would go a long way toward making them seem actually human. It might even make you reluctant to do something crazy like start killing them, and make you feel obligated to protect them. That kind of emotional involvement is something games need.
I think the real problem is that online games are almost exclusively about aggression. In almost all online games, the primary way you interact with the game world is a weapon. Even when you're in a party you're sometimes competing with your own party members. Until we have games that are founded on cooperation instead of competition, where your primary tools are something other than guns and swords, players of online games are going to be aggressive toward each other.
It's the nature of the games themselves, which is of course a side effect of the people who work in the game industry, but also a cause. It's a vicious cycle. However, there is hope on the horizon, and it comes from the (unlikely) direction of Valve software and Team Fortress 2. Have you seen the latest trailer for Team Fortress 2? The facial animation software is nothing short of incredible. This is a key tool that has been missing from games for years. If it can be merged with a procedural animation system, Valve will have finally brought down the barriers to creating movie-quality character development and plots in games.
Team Fortress won't have a movie-worthy in-game plot, to be sure, but the personality and above all *humor* infused into Valve's characters is already a welcome change from typical FPS fare. OTOH, something like Portal could be a breakthrough game.
The absolute fastest way to read text is to stare at a little box without moving your eyes, and have words flash up in quick succession. Completely eliminating eye movement allows you to read much faster (with a little practice). Of course, it's completely unprintable, and it's hard to skip around in the text, so this method is unlikely to get much use. But if you have a large body of text, it's the absolute fastest way to read.
It's something of an interesting experience; after a while of upping the speed it feels almost as if the words are being hammered into your brain. I recommend trying it; it only takes a few minutes to whip up an implementation in XCode or Visual Studio. Put in a speed control and see how many WPM you can get.
The problem is AFAIK stoplights have sensors that can only detect cars when they are stopped. Timing can only help so much (especially when you consider trying to time lights on perpendicular or diagonal streets). Stoplights have no idea about the 10 cars that are going to be crossing the intersection 10 seconds from now; they can only see the one car waiting. If stoplights had better sensors they could make better decisions. What they really need are cameras that can see cars as they approach; unfortunately this is a hard problem in computer vision.
IMHO they should put the "sophisticated sensors" on the traffic lights instead. We're still using the same old "wire loop in the road" traffic sensors that can only sense cars once they are piled up at the intersection. With better sensors you could change lights preemptively to avoid having a giant mass of cars come to a halt only to start again seconds later when the light notices their presence. Plus you could get a lot more information about traffic flow patterns to better coordinate networked lights.
And yet, this problem continues to happen regularly, even on the sites of huge corporations which should know better. For example (just from sites I use regularly), chase.com, sce.com, verizonwireless.com, sprint.com. This vulnerability is *HUGE* and it deserves to be on Slashdot. If I own a public wireless hotspot, or even if I just happen to be *using* the same wireless access point as you, I can *trivially* steal your account when you visit these sites. This article is just as relevant today.
BTW, if your bank does this, an easy way to fix it for yourself is to put in a bogus username/password for the first login attempt. This almost always takes you to a secure page for the second attempt.
That's kinda the point. These sites being talked about actually *do* secure the whole session. Except for the most important part: the logon form! This practice is widespread even today (chase.com, sprint.com, verizonwireless.com, just to name three I happen to use on a monthly basis).
Um... yes, if you want to do it properly, i.e. without race conditions or deadlocks (apartment model threading... [shudder]), memory leaks, or buffer overflows. COM/ActiveX is a nightmare that Microsoft invented.NET to get away from. (what's that function to convert from BSTR to CString again? Or to TCHAR* or wait I need LPTSTR or WCHAR* or plain char* or how about std::string or... argh!) Compare to Firefox, where your extension is likely written entirely in Javascript very similar to the kind everyone writes nowadays for web pages. Plus, example code from every extension at addons.mozilla.org is one unzip operation away; it's all open source just due to the nature of Javascript. The barriers to entry are far lower.
Everyone hates the browser, but nobody can replace it. Instead of denying it, it's time we (as a profession) accept that the browser actually *is* a good platform for applications, and start figuring out why, so that when we try to replace it we don't end up removing its best features.
Here's a list of things browsers do better than any other client application platform out there:
Superlative, lightning fast text layout and reflow, including support for all languages
Sandboxed code from untrusted sources that you can actually trust enough to run routinely without security prompts
Extremely robust and effective yet easy to use transparent caching mechanism makes "installation" irrelevant
Stateless nature forces architecture choices on developers that turn out to be a good idea anyway (despite the kicking and screaming)
Emphasis on declarative content and text instead of procedural code and opaque binary blobs enables automated processing, unintended features: search engines, back button, bookmarking, form autocomplete and spell check, password managers, download managers, tabbed browsing, GreaseMonkey
Easy centralized control using proxies
almost completely platform-agnostic
Free development tools
Practically instant start-up
Tiny runtime size (Firefox is a 5.7 MB install; Java and.NET are how much again?)
"Everything is a hyperlink" user interface simplifies and standardizes user experience
I'm not even counting the installed base as an advantage here, so don't complain that alternatives fail because of user apathy toward installation of alternatives; these are genuine advantages that the browser has over alternatives, ignoring its ubiquity. Now, the implementation of all of these features in browsers have flaws that I'm sure you can name, and browsers have plenty of other faults too. But no other alternative provides all of these features in one package. These are *all* really important features with huge advantages in the real world that any replacement for the browser as an application platform will need to address.
Let's say A goes to send B his key, but it's intercepted by C, and C sends B a modified key (man in the middle attack). Then B will not be able to initiate communication with A because the key won't match.
But if C can intercept and modify communications in both directions, C can send his own keys to both A and B, then decrypt and re-encrypt traffic going in both directions. A and B never see traffic from each other, only from C. And I should not that this situation is more common than you might realize; for example it can often be done on Ethernet networks (yes, just like the one you're using now) with ARP spoofing!
This is why encryption without authentication is useless. B needs some way to verify that the key has come from A and not C. In the real world (SSL) this is done with yet more public key encryption. Before communicating, A and B receive public keys from a Certificate Authority (say, Verisign) through a secure channel (their operating system installation disks). A sends his public key to the Verisign along with proof of identity, and Verisign sends back a message, encrypted with the Verisign's private key, saying "We certify that A's public key is [...]". A (or C, doesn't matter) sends this message to B, B decrypts it with the CA's public key, and now B knows A's public key. C can't send a different public key to B because they don't have Verisign's private key; when B tries to decrypt C's message with Verisign's public key it will fail and B will refuse the connection.
Adobe's open source efforts aren't all talk. They have been quite reasonable at shepherding PDF as an open standard. Also, they have recently open-sourced a JIT engine for JavaScript which Mozilla is adopting for Mozilla 2 (and thus, likely, Firefox 4). In addition to better performance, this could result in better compatibility between Flash's ActionScript and Firefox's JavaScript in the future.
It's true that we'll probably never see open-source Flash from Adobe. But I don't think it's fair to compare Adobe's attitudes toward open source to Microsoft.
The keys will change quite rarely. How often do you update your trusted SSL roots? Plus, this is not an open system like the Internet; it could be tightly controlled. Firmware updates would be a more than sufficient mechanism for updating key lists. Yes, you could compromise some receivers if you were able to steal a private key, but that would be a huge improvement over the current situation, where anyone can compromise all receivers anytime they want with no hurdles at all.
If you were especially worried you could include key revocation in the protocol and periodically broadcast revocations (using a presumed-completely-secure master key) to keep receivers in the field safe from attacks. Even if attackers got that key, they would only be able to DoS by revoking everything, whereupon everyone would have to update their firmware to get new keys. But it is possible to keep single root keys secure; public key encryption relying on secret root keys protects many things today that would be much more disruptive and lucrative to crack than traffic warnings. For example, all Internet commerce, and Windows Update.
With CSS, you don't have to split your code into separate files. CSS can be inline. I see no way to do that with XSL (although if there is one, I'd be happy to know about it). There are pros and cons of both ways of doing things and it's nice to have that flexibility (pretty much every site uses both embedded CSS and separate stylesheets).
You misunderstand about the root element thing. Say I want to write some HTML like this and implement include with an XSL stylesheet:
The included file can't have multiple <li> elements at the top level, because then it's not a well-formed XML document by itself, and XSL can only include complete well-formed xml documents with the document() function. Yes, this can be worked around. But why should we have to? (Personally, I think this is a problem with XML in general. I've never heard the rationale for why XML requires a single root node. I'm sure there is one; I'm not sure that it's good.)
As for incremental rendering being a problem with implementations and not the spec, well, I thought I remembered a Bugzilla discussion about this: tinyurl to avoid the Bugzilla Slashdot ban: https://bugzilla.mozilla.org/show_bug.cgi?id=18333 #c83
Turns out that running XSLT is incremental, but, in the general case, all the input must be available before you can *start* running it, due to XPath. Since the slow part is obtaining the input and not actually running the XSLT, that doesn't really help you. Mozilla may in the future implement incremental rendering when your XPath is simple enough, but it sounds like it won't be trivial, and I'll just bet that even *if* that optimization is ever implemented, it will be easy to defeat with relatively innocuous XPath expressions, resulting in an instant fallback to non-incremental rendering. Boy will that be fun to debug!
Hmm interesting. But XSL has some disadvantages. It's a huge spec to implement and a lot of processing overhead just to get an element. It will never be supported everywhere, it requires splitting code into a separate stylesheet file, it requires XHTML so you have to do your doctype and xmlns incantations just so, you can only include complete well-formed XML documents with a single root element (so you couldn't include multiple paragraphs without wrapping them in one div or span), and perhaps worst of all it disables incremental rendering. An HTML element would be trivial to implement so support would soon become widespread. It would have little runtime overhead and could easily address all of the above limitations.
Then you can take your computer down to your local completely legal DRM-cracking shop, where they will apply epoxy-dissolving solvents, then hook up industrial logic analyzers and bus sniffers or perhaps even electron microscopes, probe the inner workings of your TPM chip and break it. There is no DRM that can stand up to a well-funded and determined opponent, and if a DRM system protects works of any real value, there will be no trouble in finding opponents or funding. The only reason this doesn't happen more often today (though it *does* happen; who do you think develops commercial modchips?) is the fact that DRM is protected by law. Remove that protection, and the best minds in the world will be focused on breaking DRM if that's what it takes.
I like your ideas. I'm especially a fan of encouraging the release of source code in copyright law. Personally, I am of the opinion that many of the worst problems in computing today can be traced back, at their root, to the industry practice of distributing software in an opaque, obfuscated, immutable format.
It would be interesting to apply these principles not only to software, but to other copyrightable works as well. Copyright law could take a page from the GPL and mandate availability of the "preferred form of the work for making modifications". It would be great if you could get a copy of the music you own in uncompressed multi-track format; you could make your own karaoke version or techno remix quite easily. You could get books you own in a word processing format and easily convert them into ebooks, run them through a text-to-speech program, etc. Software is far from the only area where this change would make sense.
I can't believe that people are seriously considering a ban on DRM. I suppose I should have realized that it's natural to try to fix a problem by making a new law, but when the problem *is* the law, you should fix it by repealing the problematic law, not making more.
There is absolutely zero need to ban DRM, for one simple reason: DRM doesn't work, has never worked, can't ever work. All DRM schemes are fundamentally flawed, at a deep technological level. The only course of action necessary is to remove all laws protecting DRM, thus making it completely legal to make, distribute, even sell software and/or hardware for the explicit purpose of breaking DRM. Completely legal copies of DeCSS, FairUse4WM, QTFairUse, BackupHDDVD, etc would be available everywhere. Entire companies could be founded to muster the resources to perform sophisticated attacks on DRM hardware and software (perhaps even a brute force cryptological attack would be feasible in some cases with enough resources). Modchips, firmware hacks, replacement toner cartridges with DRM lockout chips, etc would all be readily available.
In such an environment, all DRM would be futile. After a few more thwarted schemes, even the most stubborn holdouts in the RI/MPAA would have to see the light. DRM would go away of its own accord, and it would all be the result of *repealed* laws instead of new ones. Fewer laws on the books is a good thing.
The only thing I would like is a client side include.
Man, wouldn't that be nice. How is it that we've gone through all these major revisions of [X]HTML and an <include> element has never been added? It seems so obvious. Is there some technical reason?
Perhaps this thing will convince people to point their ads at pages that match instead of generic home pages. I can't count the number of times I've clicked on a very specific Google ad, only to be dumped onto a generic home page from which it would require at least three clicks to get to the specific thing I wanted in the first place, if it even exists at the site. (And that's not even counting the asinine "Find cheap your search terms on EBay!" affiliate ads, since I know better than to click on those...)
When that happens, not only do I leave the site immediately, resulting in wasted advertising money, I also lose faith in the overall relevancy of Google ads, making me less likely to click on any ads in the future. Generic landing pages aren't just a problem for individual advertisers; they hurt Google too.
Protected processes are a terrible idea, and they have no analog in Unix. You have misunderstand the purpose of protected processes. It has nothing to do with protecting processes from each other for better security. It is *only* about protection from the *user* for media. Protected processes cannot be written by anyone but Microsoft and "trusted" partners (theoretically) and are supposed to be immune from tampering by every user, even one with the highest possible administrative rights. No Unix has this concept, because it is retarded. It removes your own control over what your computer is doing and hands it to Microsoft and a few "trusted" companies which are allowed to write protected processes.
There is no per kilobit charge on top of the monthly fee, I don't know where you got that idea. Did you look at Sprint? Their service actually *is* unlimited, as I can attest after being kicked from Verizon and switching over. (I canceled my cable and use the card as my only connection to justify the cost).
Yeah, but Sprint sells exactly the same service, except that they have no cap. Nobody's ever been terminated from Sprint's EV-DO for downloading too much. When Verizon lowered the banhammer on me, I switched to Sprint and have had no problems since. Plus, Sprint's tech is better (Revision A EV-DO instead of Revision 0).
Though I should note that Sprint is hemorrhaging subscribers at the moment, and getting trounced in the stock market because of it. They are probably paranoid about terminating anyone, because even if it would save them money it lowers their subscriber numbers and makes them look bad. It may be that as soon as their little crisis is over, they'll start terminating people again. But I like to think that Sprint is just more broadband-friendly in general. They are investing the most in next-gen wireless (EV-DO, WiMAX), and of all the carriers they seem to be the most conscious of the fact that in the not-so-far future, they (along with everyone else) will be relegated to dumb bit pipes by the inevitable rise of mobile IP services.
Slashdot Mirror
The MacBook weighs 5.1 lbs. The ThinkPad X60 weighs 3.1 (small battery; 3.6 with 8-hour battery). That's what you're paying for.
When I was shopping for laptops I wanted to look at Macs, but my weight requirement threw them all out of the running. I ended up getting an X60s which weighs 2.7 lbs (3.3 with big battery), and every time I carry it I'm glad I did. IMHO the long-rumored MacBook Thin can't come soon enough.
You say that as if an energy storage medium with size, weight, and durability, and power to match the gasoline engine wasn't a major breakthrough that could have enormous benefits for society. In fact, energy storage and transport is just as important as generation, but has seen a lot less practical advancement in the last 50 years.
As a society we desperately need improvements to energy storage. Better storage means we can use more efficient and cleaner means of generation. We will probably never have fission reactors in our cars, but with this tech the energy our cars use can come from fission anyway. That's a breakthrough worth celebrating.
Well, up until now just rendering the realistic facial expressions on an in-game model in real time was out of reach. Until now, you couldn't even make a decent game version of Shrek. So it's a big step. Sure, any expressions lip-synced with dialog still need to be hand-animated, but the dialogue itself needs to be pre-recorded as well anyway for the foreseeable future. The days of generated dialogue certainly are a long way off. But that's not what I meant when I said "procedural animation system", I was talking more about basic things like convincing eye and head movements and walking with proper weight transfer and without feet sliding across the floor, which no game has yet gotten completely right. (Walking and especially turning animations are my pet peeve; we ought to be able to do better than linear interpolation between keyframes. We spend so much time making the still screenshots look pretty and then use the same old animation systems that make people walk like retarded robots.)
Just having characters show convincing surprise, fear, and happiness at appropriate times is a huge step forward. As an example, imagine in Halo that after a harrowing fight, one marine breaks down crying over a fallen comrade. That's something that just wouldn't work at all with the generic stoic expression they all share now. A scene like that could add a lot of emotional depth, even if it was completely pre-scripted and randomly-triggered just like the little random quips that they currently make after combat. If you go crazy and start killing your fellow marines, you should see the surprise, fear, and hatred on their faces instead of just hearing it in their voice lines. It would go a long way toward making them seem actually human. It might even make you reluctant to do something crazy like start killing them, and make you feel obligated to protect them. That kind of emotional involvement is something games need.
I think the real problem is that online games are almost exclusively about aggression. In almost all online games, the primary way you interact with the game world is a weapon. Even when you're in a party you're sometimes competing with your own party members. Until we have games that are founded on cooperation instead of competition, where your primary tools are something other than guns and swords, players of online games are going to be aggressive toward each other.
It's the nature of the games themselves, which is of course a side effect of the people who work in the game industry, but also a cause. It's a vicious cycle. However, there is hope on the horizon, and it comes from the (unlikely) direction of Valve software and Team Fortress 2. Have you seen the latest trailer for Team Fortress 2? The facial animation software is nothing short of incredible. This is a key tool that has been missing from games for years. If it can be merged with a procedural animation system, Valve will have finally brought down the barriers to creating movie-quality character development and plots in games.
Team Fortress won't have a movie-worthy in-game plot, to be sure, but the personality and above all *humor* infused into Valve's characters is already a welcome change from typical FPS fare. OTOH, something like Portal could be a breakthrough game.
The absolute fastest way to read text is to stare at a little box without moving your eyes, and have words flash up in quick succession. Completely eliminating eye movement allows you to read much faster (with a little practice). Of course, it's completely unprintable, and it's hard to skip around in the text, so this method is unlikely to get much use. But if you have a large body of text, it's the absolute fastest way to read.
It's something of an interesting experience; after a while of upping the speed it feels almost as if the words are being hammered into your brain. I recommend trying it; it only takes a few minutes to whip up an implementation in XCode or Visual Studio. Put in a speed control and see how many WPM you can get.
The problem is AFAIK stoplights have sensors that can only detect cars when they are stopped. Timing can only help so much (especially when you consider trying to time lights on perpendicular or diagonal streets). Stoplights have no idea about the 10 cars that are going to be crossing the intersection 10 seconds from now; they can only see the one car waiting. If stoplights had better sensors they could make better decisions. What they really need are cameras that can see cars as they approach; unfortunately this is a hard problem in computer vision.
IMHO they should put the "sophisticated sensors" on the traffic lights instead. We're still using the same old "wire loop in the road" traffic sensors that can only sense cars once they are piled up at the intersection. With better sensors you could change lights preemptively to avoid having a giant mass of cars come to a halt only to start again seconds later when the light notices their presence. Plus you could get a lot more information about traffic flow patterns to better coordinate networked lights.
And yet, this problem continues to happen regularly, even on the sites of huge corporations which should know better. For example (just from sites I use regularly), chase.com, sce.com, verizonwireless.com, sprint.com. This vulnerability is *HUGE* and it deserves to be on Slashdot. If I own a public wireless hotspot, or even if I just happen to be *using* the same wireless access point as you, I can *trivially* steal your account when you visit these sites. This article is just as relevant today.
BTW, if your bank does this, an easy way to fix it for yourself is to put in a bogus username/password for the first login attempt. This almost always takes you to a secure page for the second attempt.
That's kinda the point. These sites being talked about actually *do* secure the whole session. Except for the most important part: the logon form! This practice is widespread even today (chase.com, sprint.com, verizonwireless.com, just to name three I happen to use on a monthly basis).
Here's a list of things browsers do better than any other client application platform out there:
- Superlative, lightning fast text layout and reflow, including support for all languages
- Sandboxed code from untrusted sources that you can actually trust enough to run routinely without security prompts
- Extremely robust and effective yet easy to use transparent caching mechanism makes "installation" irrelevant
- Stateless nature forces architecture choices on developers that turn out to be a good idea anyway (despite the kicking and screaming)
- Emphasis on declarative content and text instead of procedural code and opaque binary blobs enables automated processing, unintended features: search engines, back button, bookmarking, form autocomplete and spell check, password managers, download managers, tabbed browsing, GreaseMonkey
- Easy centralized control using proxies
- almost completely platform-agnostic
- Free development tools
- Practically instant start-up
- Tiny runtime size (Firefox is a 5.7 MB install; Java and
.NET are how much again?)
- "Everything is a hyperlink" user interface simplifies and standardizes user experience
I'm not even counting the installed base as an advantage here, so don't complain that alternatives fail because of user apathy toward installation of alternatives; these are genuine advantages that the browser has over alternatives, ignoring its ubiquity. Now, the implementation of all of these features in browsers have flaws that I'm sure you can name, and browsers have plenty of other faults too. But no other alternative provides all of these features in one package. These are *all* really important features with huge advantages in the real world that any replacement for the browser as an application platform will need to address.Let's say A goes to send B his key, but it's intercepted by C, and C sends B a modified key (man in the middle attack). Then B will not be able to initiate communication with A because the key won't match.
But if C can intercept and modify communications in both directions, C can send his own keys to both A and B, then decrypt and re-encrypt traffic going in both directions. A and B never see traffic from each other, only from C. And I should not that this situation is more common than you might realize; for example it can often be done on Ethernet networks (yes, just like the one you're using now) with ARP spoofing!
This is why encryption without authentication is useless. B needs some way to verify that the key has come from A and not C. In the real world (SSL) this is done with yet more public key encryption. Before communicating, A and B receive public keys from a Certificate Authority (say, Verisign) through a secure channel (their operating system installation disks). A sends his public key to the Verisign along with proof of identity, and Verisign sends back a message, encrypted with the Verisign's private key, saying "We certify that A's public key is [...]". A (or C, doesn't matter) sends this message to B, B decrypts it with the CA's public key, and now B knows A's public key. C can't send a different public key to B because they don't have Verisign's private key; when B tries to decrypt C's message with Verisign's public key it will fail and B will refuse the connection.
Adobe's open source efforts aren't all talk. They have been quite reasonable at shepherding PDF as an open standard. Also, they have recently open-sourced a JIT engine for JavaScript which Mozilla is adopting for Mozilla 2 (and thus, likely, Firefox 4). In addition to better performance, this could result in better compatibility between Flash's ActionScript and Firefox's JavaScript in the future.
It's true that we'll probably never see open-source Flash from Adobe. But I don't think it's fair to compare Adobe's attitudes toward open source to Microsoft.
The keys will change quite rarely. How often do you update your trusted SSL roots? Plus, this is not an open system like the Internet; it could be tightly controlled. Firmware updates would be a more than sufficient mechanism for updating key lists. Yes, you could compromise some receivers if you were able to steal a private key, but that would be a huge improvement over the current situation, where anyone can compromise all receivers anytime they want with no hurdles at all.
If you were especially worried you could include key revocation in the protocol and periodically broadcast revocations (using a presumed-completely-secure master key) to keep receivers in the field safe from attacks. Even if attackers got that key, they would only be able to DoS by revoking everything, whereupon everyone would have to update their firmware to get new keys. But it is possible to keep single root keys secure; public key encryption relying on secret root keys protects many things today that would be much more disruptive and lucrative to crack than traffic warnings. For example, all Internet commerce, and Windows Update.
You misunderstand about the root element thing. Say I want to write some HTML like this and implement include with an XSL stylesheet: The included file can't have multiple <li> elements at the top level, because then it's not a well-formed XML document by itself, and XSL can only include complete well-formed xml documents with the document() function. Yes, this can be worked around. But why should we have to? (Personally, I think this is a problem with XML in general. I've never heard the rationale for why XML requires a single root node. I'm sure there is one; I'm not sure that it's good.)
As for incremental rendering being a problem with implementations and not the spec, well, I thought I remembered a Bugzilla discussion about this:
tinyurl to avoid the Bugzilla Slashdot ban: https://bugzilla.mozilla.org/show_bug.cgi?id=1833
Turns out that running XSLT is incremental, but, in the general case, all the input must be available before you can *start* running it, due to XPath. Since the slow part is obtaining the input and not actually running the XSLT, that doesn't really help you. Mozilla may in the future implement incremental rendering when your XPath is simple enough, but it sounds like it won't be trivial, and I'll just bet that even *if* that optimization is ever implemented, it will be easy to defeat with relatively innocuous XPath expressions, resulting in an instant fallback to non-incremental rendering. Boy will that be fun to debug!
Hmm interesting. But XSL has some disadvantages. It's a huge spec to implement and a lot of processing overhead just to get an element. It will never be supported everywhere, it requires splitting code into a separate stylesheet file, it requires XHTML so you have to do your doctype and xmlns incantations just so, you can only include complete well-formed XML documents with a single root element (so you couldn't include multiple paragraphs without wrapping them in one div or span), and perhaps worst of all it disables incremental rendering. An HTML element would be trivial to implement so support would soon become widespread. It would have little runtime overhead and could easily address all of the above limitations.
Then you can take your computer down to your local completely legal DRM-cracking shop, where they will apply epoxy-dissolving solvents, then hook up industrial logic analyzers and bus sniffers or perhaps even electron microscopes, probe the inner workings of your TPM chip and break it. There is no DRM that can stand up to a well-funded and determined opponent, and if a DRM system protects works of any real value, there will be no trouble in finding opponents or funding. The only reason this doesn't happen more often today (though it *does* happen; who do you think develops commercial modchips?) is the fact that DRM is protected by law. Remove that protection, and the best minds in the world will be focused on breaking DRM if that's what it takes.
I like your ideas. I'm especially a fan of encouraging the release of source code in copyright law. Personally, I am of the opinion that many of the worst problems in computing today can be traced back, at their root, to the industry practice of distributing software in an opaque, obfuscated, immutable format.
It would be interesting to apply these principles not only to software, but to other copyrightable works as well. Copyright law could take a page from the GPL and mandate availability of the "preferred form of the work for making modifications". It would be great if you could get a copy of the music you own in uncompressed multi-track format; you could make your own karaoke version or techno remix quite easily. You could get books you own in a word processing format and easily convert them into ebooks, run them through a text-to-speech program, etc. Software is far from the only area where this change would make sense.
I can't believe that people are seriously considering a ban on DRM. I suppose I should have realized that it's natural to try to fix a problem by making a new law, but when the problem *is* the law, you should fix it by repealing the problematic law, not making more.
There is absolutely zero need to ban DRM, for one simple reason: DRM doesn't work, has never worked, can't ever work. All DRM schemes are fundamentally flawed, at a deep technological level. The only course of action necessary is to remove all laws protecting DRM, thus making it completely legal to make, distribute, even sell software and/or hardware for the explicit purpose of breaking DRM. Completely legal copies of DeCSS, FairUse4WM, QTFairUse, BackupHDDVD, etc would be available everywhere. Entire companies could be founded to muster the resources to perform sophisticated attacks on DRM hardware and software (perhaps even a brute force cryptological attack would be feasible in some cases with enough resources). Modchips, firmware hacks, replacement toner cartridges with DRM lockout chips, etc would all be readily available.
In such an environment, all DRM would be futile. After a few more thwarted schemes, even the most stubborn holdouts in the RI/MPAA would have to see the light. DRM would go away of its own accord, and it would all be the result of *repealed* laws instead of new ones. Fewer laws on the books is a good thing.
Perhaps this thing will convince people to point their ads at pages that match instead of generic home pages. I can't count the number of times I've clicked on a very specific Google ad, only to be dumped onto a generic home page from which it would require at least three clicks to get to the specific thing I wanted in the first place, if it even exists at the site. (And that's not even counting the asinine "Find cheap your search terms on EBay!" affiliate ads, since I know better than to click on those...)
When that happens, not only do I leave the site immediately, resulting in wasted advertising money, I also lose faith in the overall relevancy of Google ads, making me less likely to click on any ads in the future. Generic landing pages aren't just a problem for individual advertisers; they hurt Google too.
Protected processes are a terrible idea, and they have no analog in Unix. You have misunderstand the purpose of protected processes. It has nothing to do with protecting processes from each other for better security. It is *only* about protection from the *user* for media. Protected processes cannot be written by anyone but Microsoft and "trusted" partners (theoretically) and are supposed to be immune from tampering by every user, even one with the highest possible administrative rights. No Unix has this concept, because it is retarded. It removes your own control over what your computer is doing and hands it to Microsoft and a few "trusted" companies which are allowed to write protected processes.
There is no per kilobit charge on top of the monthly fee, I don't know where you got that idea. Did you look at Sprint? Their service actually *is* unlimited, as I can attest after being kicked from Verizon and switching over. (I canceled my cable and use the card as my only connection to justify the cost).
Did you look at Sprint? Sprint's service actually *is* unlimited. Verizon cut me off; I switched to Sprint and haven't looked back.
Yeah, but Sprint sells exactly the same service, except that they have no cap. Nobody's ever been terminated from Sprint's EV-DO for downloading too much. When Verizon lowered the banhammer on me, I switched to Sprint and have had no problems since. Plus, Sprint's tech is better (Revision A EV-DO instead of Revision 0).
Though I should note that Sprint is hemorrhaging subscribers at the moment, and getting trounced in the stock market because of it. They are probably paranoid about terminating anyone, because even if it would save them money it lowers their subscriber numbers and makes them look bad. It may be that as soon as their little crisis is over, they'll start terminating people again. But I like to think that Sprint is just more broadband-friendly in general. They are investing the most in next-gen wireless (EV-DO, WiMAX), and of all the carriers they seem to be the most conscious of the fact that in the not-so-far future, they (along with everyone else) will be relegated to dumb bit pipes by the inevitable rise of mobile IP services.