I'm actually fairly indifferent towards Verizon -- more outraged that they charge $350 to anyone for termination, but that seems to be the norm in that industry.
What I was specifically responding to was the comment of "So he died. Get over it." That is not an OK thing to say to a grieving widow.
So how long after a spouse dies is the surviving spouse exempt from service fees for their own services?
I realize that's a rhetorical question, but let's see...
"The remote detonated IED, one of those went off, and he took full force," explained Michaela surrounded by pictures of her husband and flowers, still fresh, from his recent funeral. "He died on the chopper on the way to the field hospital."
I'm going to say, longer than that.
I suppose it's technically possible that this is being spun, since she's not specifically talking about the termination fee here, and it doesn't say how long ago he died. Then again...
The reason that she is canceling is NOT because her husband died. It is because she is moving. That part is a choice.
She is moving because her husband died. Sure, she could choose to stay, but it's not unreasonable.
But all of this is beside the point. I'm not saying that Verizon should have to do anything...
I know that when a death is involved, most companies are going to make exceptions to rules.
I realize it would be an exception. I might even concede that this particular case isn't necessarily clear. (For example: Whose fault is it that she went with a plan and a provider that charges $350 early-termination fees?)
But I was replying to an AC who said this:
So he died. Get over it.
That is not an OK thing to say. Not now, not in ten years. If it's tangential, it's tangential, but you do not tell a grieving widow to "get over it."
Or, to be more precise: It is allowed (freedom of speech), but incredibly insensitive.
I'd be surprised if it wasn't from some document template they've been using anytime anyone dies and they need to express condolences.
That much I was sure of, I'd just never really noticed it before... Just two points: First, the fact that it's common doesn't preclude it being odd. And second, I think it says something that they copy and paste that. Think about it -- in my spare time, I tend to type Slashdot posts from scratch which, I'd like to think, show more sensitivity than they have here, and they can't find someone to take two minutes and write something authentic, instead of copying and pasting PR bullshit?
I do still find it odd, though, partly because we know it's not true, in many ways. First, we know that the person who copied and pasted it isn't going to pray. Second, we know that most of the company wouldn't have even known this had happened without it being a PR scandal, so we know that if they pray at all, the cause of that prayer is (indirectly) bad PR. And finally, this would annoy the hell out of me if I worked there -- it means either they're doing prayers in an official capacity, or they're assuming to speak for the employees...
Yeah, I'm overanalyzing. Yeah, I really should pick my battles... I just thought it was... odd.
Congratulations! That's about the most insensitive thing you could say to a grieving widow. From TFA:
Michaela's father, a veteran himself, is outraged. "It's not about the money. I don't care about the money. It's the principle. The man was overseas fighting for our country and lost his life doing so," said Kevin Gause. "It's heartless what Verizon is doing."
And you've suggested that "peter" and "paul" are a good idea to use as column names.
No, you don't build a framework for any one thing. Even if you decided that an ORM is a good thing -- and it is, for reasons other than security -- that's just one piece.
But see, it's not just SQL injection. It's SQL injection, session management (scalability, protection from forgery), cross-site request forgery protection, cross-site scripting protection (have you escaped all your output?)... combined with, how many times have you written pagination? How many times have you written a login system?
No one needs a framework for any one thing, but when starting with the bare metal, you do tend to find yourself adding one thing after another until you've got a mini-framework of your own -- one which is far less well tested and maintained than an open source one.
I was wrong to say that you need a framework just for SQL injection, full stop.
I was getting my points confused -- I was arguing that PHP is not a good choice for security or maintainability, and SQL injection is one example. I was also attempting to counter anyone's suggestion of something like CakePHP -- if you're going to go the full framework route with PHP, you may as well use Rails.
And "resource intensive" is relative. I don't think Rails is slow, but there is that perception, and if I recall, Cake is slower than Rails.
What Rails does isn't terribly difficult to figure out.
Even if it was, I'm not sure how much it matters to me. I don't muck around in the framework often (though it's not bad), but I do like it when my application code is pretty -- in particular, I like it to say what I want it to say, as much as possible.
This is the wrong way to go about things. Don't move to a technology because it protects you from making silly mistakes.
That isn't what I was suggesting. I'm saying that you should move to a technology because it makes it easier to do things the right way, not necessarily because it makes it harder to do things the wrong way.
For example, many people argue against Ruby because it's possible to do things like this:
class NilClass
def nil?
false
end end
This tends to crash the interpreter. But why would you ever do that? It's not about keeping bad/evil/clever programmers at bay, that should be HR's job. No, you choose a technology because of what you can do with it.
I don't use the Rails stack by itself, generally -- I use DataMapper for an ORM -- but in either DataMapper or ActiveRecord, it's still easier for me to write good, maintainable, SQL-injection-free code than it is for me to do the same in PHP.
even when you choose a language/framework that offers protections like those above, you're still not exempted from checking your inputs and outputs.
That depends what they're being used for. If you stick to a framework which is mostly designed for storing data, there's not much to check -- just use the data as, well, data, and you're not vulnerable.
It's the weird edge cases that keep cropping up, like clickjacking, but that's hardly about "checking inputs and outputs". So I agree with this statement:
No matter what language you choose, you still need to secure your code base.
I just don't think it means "checking inputs and outputs".
It has to be said: Don't use PHP if you value security or maintainability.
Yes, you can build a decent framework on top of PHP, so that you won't be vulnerable to SQL injections. By the time you do, you lose any speed advantage (or "ease-of-use" advantage) PHP had over Ruby on Rails. Given that, if you think Rails is too slow, your only real alternative is something like Java, and I'm not even sure Java with a full stack is any better.
Yes, you need to know what you're doing. The question is whether the platform makes it easier or harder for you to do it right. Rails has built-in countermeasures to request forgery, and even the built-in ORM makes it rare that you have to (or want to) write raw SQL, let alone use string interpolation. HTML-escaping in your templates is a single keystroke, and you can get template engines that make it the default.
That said, depending how much of this game has been written, porting to another language may be out of the question. But let's put it this way: Would you write a web app in a language that makes it possible for you to implement a buffer overflow? That is, would you use C?
Would you feel better if I said "User data, corresponding to savegames, preferences, and other stuff that needs to be backed up"?
The only difference between what it stores and what an HTTP cache stores is that an HTTP cache can only store resources that would be accessed through a URL. Of course, what resources could be accessed through a URL is purely a function of how the application is designed, so that's not really a fundamental difference.
And, with a properly-designed REST service, that should be everything.
There are legitimate uses for local storage -- browser extensions, user scripts, user preferences, machine-specific user preferences, etc. Think of them as cookies on steroids -- that is their purpose. And I don't like to clean out my cookies, so I certainly don't like to clean out my local storage, but I do like my caches to expire.
Let me put it this way: Many apps are now storing caches in ~/.cache, including Chrome. Other apps are doing things to deliberately identify a cache folder from within the cache itself, like VLC's CACHEDIR.TAG.
That means if I'm getting low on disk space, I can just blow away the caches. If I want to ensure cache gets stored on a separate partition or device, maybe something tuned for high write throughput and low data integrity, I can do that. If I want to exclude cache from backup, saving tons of storage (since it's way more variable than any data I care about), I can do that. One project I have planned for "someday" is to make the filesystem itself provide some sort of cache API, so that I can have caches just use my free space in much the same way as Linux's disk caches use my free RAM.
In the case of HTTP caches, I can take it a step further -- I can put a caching proxy in front of everything, or at least ensure that the same resource is cached for all applications so long as it's available at the same URL. It also makes it trivial to turn it into an offline app -- just add a manifest, no need to have your app run some lengthy "installation" process, and as a bonus, I can uncache your app when I don't need it offline (yet retain any data that I should actually care about).
Asshats who are going to cache things to HTML5's local storage (not many yet, I hope) are much like asshats who cache things in RAM just because Windows' memory management sucks. It means I now have a bloated bunch of space that the browser thinks is needed. If it starts taking too much space, I have no way, as a user, to blow it away -- you have to add that to your app, which is duplicating functionality that's already in my browser (the "empty cache" button). As a bonus, if your app has a decent REST API with the appropriate headers set to allow caching, I now have two cached copies -- so you're now wasting twice the disk space until the HTTP cache expires.
Which is, of course, exactly like what happens when you cache things in RAM instead of using memory maps, etc -- ok, yes, it makes sense if it's a text format on disk, so you cache the parsed version in RAM. But if you're caching it in RAM just because you assume you'd otherwise be reading it from disk, you're likely decreasing performance. Trust the filesystem cache -- even Windows is getting better at this. Then, when I'm actually using close to all my RAM, it'll be able to figure out that it's cache and just remove it to make way for something I need -- which is way faster than having to swap out chunks of your application to disk.
Imagine the worst-case scenario here, where I don't have enough RAM to reliably cache the file you're reading -- chances are, as you read it, it'll be swapping something else out to disk. If it's really bad, it might be swapping out the very bits of RAM you're reading into, so you're now copying from a file into swap, so you can then read out of very-fragmented swap instead of the file. Bravo.
And it's easy to do that already: Just install a browser with HTML5's geolocation support, and enable it, click "yes" when something wants to know where you are.
Contrast that with your ISP injecting a header into your HTTP traffic, which should be considered a violation of Net Neutrality.
Seems to be a minor thing simply wrong in every single point...
Point #1 is flat wrong on this count:
If drawing images is your goal, then the Canvas object may be powerful enough. But if you want to build specialized 3-D worlds like the ones found in the more sophisticated Flash and Shockwave games, you may be pining for the old days...
Erm... Maybe WebGL isn't officially part of HTML5, but it's there, and Chrome is implementing it. And personally, I'd much rather force people to download a decent open source browser than a decent proprietary plug-in -- there's alway Chrome Frame if you really need it.
Point #2:
some developers deliberately disabled the Flash plug-in to avoid the headaches and overhead of rendering heavy Flash content. That won't be an option in the future.
Bullshit. It'd take less than ten minutes to put this jQuery in a Chrome extension: $('canvas').remove();
Point #3:
Game programmers might store descriptions and artwork locally, saving the time of downloading the information again and again.
That's what HTTP caches are for, and they work for XHR, too!
Please, no one do this. Ever. HTML5 storage is for storing data. When you use it for caches, you add that much more stuff we might inadvertently back up, that much more cache we can't automatically purge (to claim disk space) or expire (from disuse), and you're doing more work to duplicate functionality HTTP already has.
Point #4:
The so-called microformats in HTML5
I'm confused... microformats don't require HTML5, do they?
Point #5 is fine, though it doesn't mention potential privacy concerns.
Point #6:
Google's new format will see some usage, for example in YouTube, but will never reach anywhere close to the ubiquity of H.264.
Erm, do you know something we don't? Last I checked, YouTube is still H.264 -- in a Flash container, no less.
Point #7, I don't care about.
Point #8:
This claim of better security, though, is a bit of a wild guess. The devious minds may use their malice aforethought to take advantage of the nice integration, perhaps drawing PayPal logos with the Canvas object...
So phishing will be easier? Big deal. Hasn't Flash been the biggest vector for actual client-side pwnage for awhile?
Point #9:
Now, if only HTML5 came with the nice collection of tools that Adobe makes for Flash.
Absolutely, but you need a balance. 8+ hours of Hotdog Stand doesn't replace, say, history.
If your argument is that given the right games, computers could entirely replace studying, I'd say that just becomes the new studying -- and again, the problem becomes that kids will be wasting time on Facebook or WoW instead of the more educational uses of a computer.
The point is that they are not in the "real" (as in, physical) world, but that belief is not required -- mathematical truths are true or not, regardless of what people think.
it's not like people will need to use on a frequent basis, and anyone with an iPhone is likely to have access to a computer.
It's more that it needs network access of some sort anyway, and the iPhone has a web browser. So even if you were targeting an iPhone, I don't get why you'd bother to make it an iPhone app.
Just like with Flash, I go out of my way to avoid PDFs.
Flash is theoretically open, though I'm skeptical how much of the spec is open, and what the quality of that spec is, given that there are no workable replacements for it yet. So I'm with you on that -- Flash is not open, and I avoid it when I can, and I consider it a threat to the open Web.
It's also trivial to remove.
PDF, however, I happily view with Okular, and KPDF before that, and gv before that. I wish Chrome would embed Okular instead, but I have to ask, what's your problem with PDFs? They've long since stopped being Adobe's baby and have become an open standard.
No. Remember, this is Chrome, where the contents of a given tab use a separate process from other tabs, and all of the tabs use a separate process from the tab bar and URL bar itself...
Why would you want the PDF rendering to happen in the same OS process?
I'm guessing it's less that the computer itself is dumbing anyone down, and more that they're doing it instead of other things. 8+ hours a day doesn't leave a lot of time to study.
rote learning is an invaluable method of retaining facts,
And why's that useful? You present it as though it's useful for its own sake. We now live in an age when we have machines to retain facts for us -- the more important skill is relating those facts.
It's also the only way you're really going to learn an extensive list of things like important dates and events.
Well, no. Nothing is important about a date. Events -- even dates -- are important in how they fit into a larger picture, or they're really not important at all.
In particular, rote learning without that larger picture is not only useless, it's ineffective next to learning a system. I couldn't tell you offhand what date the Shot Heard Round the World was fired, nor the date of the original Tea Party, the Stamp Act, the Boston Massacre, etc. What I can tell you is that a bunch of otherwise well-off colonists, who certainly had it better than many much more oppressed (but much more obedient) people today, revolted against the British crown and formed a new, deliberately secular republic.
That's the difference between rote learning and actual learning. Random facts don't add up to anything useful unless you can integrate them, and if you can, they're easier to memorize and even easier to look up when needed.
Slashdot Mirror
There are millions of other people out there who have had close relatives or spouses die recently too. Should we bend to their demands?
I didn't say that. All I said is that it was pretty damned insensitive.
She should take some personal responsibility and present a normal facade to the rest of the world. That's what society is all about.
Maybe to you -- and I wish you posted this non-anonymously, so I would know who I should never trust.
But some of us would like to be authentic, and actually give a damn.
How do you know I'm outraged?
I'm actually fairly indifferent towards Verizon -- more outraged that they charge $350 to anyone for termination, but that seems to be the norm in that industry.
What I was specifically responding to was the comment of "So he died. Get over it." That is not an OK thing to say to a grieving widow.
So how long after a spouse dies is the surviving spouse exempt from service fees for their own services?
I realize that's a rhetorical question, but let's see...
"The remote detonated IED, one of those went off, and he took full force," explained Michaela surrounded by pictures of her husband and flowers, still fresh, from his recent funeral. "He died on the chopper on the way to the field hospital."
I'm going to say, longer than that.
I suppose it's technically possible that this is being spun, since she's not specifically talking about the termination fee here, and it doesn't say how long ago he died. Then again...
The reason that she is canceling is NOT because her husband died. It is because she is moving. That part is a choice.
She is moving because her husband died. Sure, she could choose to stay, but it's not unreasonable.
But all of this is beside the point. I'm not saying that Verizon should have to do anything...
I know that when a death is involved, most companies are going to make exceptions to rules.
I realize it would be an exception. I might even concede that this particular case isn't necessarily clear. (For example: Whose fault is it that she went with a plan and a provider that charges $350 early-termination fees?)
But I was replying to an AC who said this:
So he died. Get over it.
That is not an OK thing to say. Not now, not in ten years. If it's tangential, it's tangential, but you do not tell a grieving widow to "get over it."
Or, to be more precise: It is allowed (freedom of speech), but incredibly insensitive.
I'd be surprised if it wasn't from some document template they've been using anytime anyone dies and they need to express condolences.
That much I was sure of, I'd just never really noticed it before... Just two points: First, the fact that it's common doesn't preclude it being odd. And second, I think it says something that they copy and paste that. Think about it -- in my spare time, I tend to type Slashdot posts from scratch which, I'd like to think, show more sensitivity than they have here, and they can't find someone to take two minutes and write something authentic, instead of copying and pasting PR bullshit?
I do still find it odd, though, partly because we know it's not true, in many ways. First, we know that the person who copied and pasted it isn't going to pray. Second, we know that most of the company wouldn't have even known this had happened without it being a PR scandal, so we know that if they pray at all, the cause of that prayer is (indirectly) bad PR. And finally, this would annoy the hell out of me if I worked there -- it means either they're doing prayers in an official capacity, or they're assuming to speak for the employees...
Yeah, I'm overanalyzing. Yeah, I really should pick my battles... I just thought it was... odd.
So he died. Get over it.
Congratulations! That's about the most insensitive thing you could say to a grieving widow. From TFA:
Michaela's father, a veteran himself, is outraged. "It's not about the money. I don't care about the money. It's the principle. The man was overseas fighting for our country and lost his life doing so," said Kevin Gause. "It's heartless what Verizon is doing."
...they break out whatever BS they think we want to hear, in the name of good publicity.
In other words, bring out the religion:
the company responded saying, " Verizon Wireless has long supported our troops.... Our thoughts and prayers are with Mrs. Brummund and her family."
Huh. So Verizon, as a company, now has a public opinion, not only on supporting our troops, but on the effectiveness of prayer?
Am I being overly sensitive, or is that just a bit odd?
And you've suggested that "peter" and "paul" are a good idea to use as column names.
No, you don't build a framework for any one thing. Even if you decided that an ORM is a good thing -- and it is, for reasons other than security -- that's just one piece.
But see, it's not just SQL injection. It's SQL injection, session management (scalability, protection from forgery), cross-site request forgery protection, cross-site scripting protection (have you escaped all your output?)... combined with, how many times have you written pagination? How many times have you written a login system?
No one needs a framework for any one thing, but when starting with the bare metal, you do tend to find yourself adding one thing after another until you've got a mini-framework of your own -- one which is far less well tested and maintained than an open source one.
I was wrong to say that you need a framework just for SQL injection, full stop.
I was getting my points confused -- I was arguing that PHP is not a good choice for security or maintainability, and SQL injection is one example. I was also attempting to counter anyone's suggestion of something like CakePHP -- if you're going to go the full framework route with PHP, you may as well use Rails.
And "resource intensive" is relative. I don't think Rails is slow, but there is that perception, and if I recall, Cake is slower than Rails.
What Rails does isn't terribly difficult to figure out.
Even if it was, I'm not sure how much it matters to me. I don't muck around in the framework often (though it's not bad), but I do like it when my application code is pretty -- in particular, I like it to say what I want it to say, as much as possible.
This is the wrong way to go about things. Don't move to a technology because it protects you from making silly mistakes.
That isn't what I was suggesting. I'm saying that you should move to a technology because it makes it easier to do things the right way, not necessarily because it makes it harder to do things the wrong way.
For example, many people argue against Ruby because it's possible to do things like this:
This tends to crash the interpreter. But why would you ever do that? It's not about keeping bad/evil/clever programmers at bay, that should be HR's job. No, you choose a technology because of what you can do with it.
I don't use the Rails stack by itself, generally -- I use DataMapper for an ORM -- but in either DataMapper or ActiveRecord, it's still easier for me to write good, maintainable, SQL-injection-free code than it is for me to do the same in PHP.
even when you choose a language/framework that offers protections like those above, you're still not exempted from checking your inputs and outputs.
That depends what they're being used for. If you stick to a framework which is mostly designed for storing data, there's not much to check -- just use the data as, well, data, and you're not vulnerable.
It's the weird edge cases that keep cropping up, like clickjacking, but that's hardly about "checking inputs and outputs". So I agree with this statement:
No matter what language you choose, you still need to secure your code base.
I just don't think it means "checking inputs and outputs".
It has to be said: Don't use PHP if you value security or maintainability.
Yes, you can build a decent framework on top of PHP, so that you won't be vulnerable to SQL injections. By the time you do, you lose any speed advantage (or "ease-of-use" advantage) PHP had over Ruby on Rails. Given that, if you think Rails is too slow, your only real alternative is something like Java, and I'm not even sure Java with a full stack is any better.
Yes, you need to know what you're doing. The question is whether the platform makes it easier or harder for you to do it right. Rails has built-in countermeasures to request forgery, and even the built-in ORM makes it rare that you have to (or want to) write raw SQL, let alone use string interpolation. HTML-escaping in your templates is a single keystroke, and you can get template engines that make it the default.
That said, depending how much of this game has been written, porting to another language may be out of the question. But let's put it this way: Would you write a web app in a language that makes it possible for you to implement a buffer overflow? That is, would you use C?
Uh, what is stored in a cache is also data.
Would you feel better if I said "User data, corresponding to savegames, preferences, and other stuff that needs to be backed up"?
The only difference between what it stores and what an HTTP cache stores is that an HTTP cache can only store resources that would be accessed through a URL. Of course, what resources could be accessed through a URL is purely a function of how the application is designed, so that's not really a fundamental difference.
And, with a properly-designed REST service, that should be everything.
There are legitimate uses for local storage -- browser extensions, user scripts, user preferences, machine-specific user preferences, etc. Think of them as cookies on steroids -- that is their purpose. And I don't like to clean out my cookies, so I certainly don't like to clean out my local storage, but I do like my caches to expire.
Let me put it this way: Many apps are now storing caches in ~/.cache, including Chrome. Other apps are doing things to deliberately identify a cache folder from within the cache itself, like VLC's CACHEDIR.TAG.
That means if I'm getting low on disk space, I can just blow away the caches. If I want to ensure cache gets stored on a separate partition or device, maybe something tuned for high write throughput and low data integrity, I can do that. If I want to exclude cache from backup, saving tons of storage (since it's way more variable than any data I care about), I can do that. One project I have planned for "someday" is to make the filesystem itself provide some sort of cache API, so that I can have caches just use my free space in much the same way as Linux's disk caches use my free RAM.
In the case of HTTP caches, I can take it a step further -- I can put a caching proxy in front of everything, or at least ensure that the same resource is cached for all applications so long as it's available at the same URL. It also makes it trivial to turn it into an offline app -- just add a manifest, no need to have your app run some lengthy "installation" process, and as a bonus, I can uncache your app when I don't need it offline (yet retain any data that I should actually care about).
Asshats who are going to cache things to HTML5's local storage (not many yet, I hope) are much like asshats who cache things in RAM just because Windows' memory management sucks. It means I now have a bloated bunch of space that the browser thinks is needed. If it starts taking too much space, I have no way, as a user, to blow it away -- you have to add that to your app, which is duplicating functionality that's already in my browser (the "empty cache" button). As a bonus, if your app has a decent REST API with the appropriate headers set to allow caching, I now have two cached copies -- so you're now wasting twice the disk space until the HTTP cache expires.
Which is, of course, exactly like what happens when you cache things in RAM instead of using memory maps, etc -- ok, yes, it makes sense if it's a text format on disk, so you cache the parsed version in RAM. But if you're caching it in RAM just because you assume you'd otherwise be reading it from disk, you're likely decreasing performance. Trust the filesystem cache -- even Windows is getting better at this. Then, when I'm actually using close to all my RAM, it'll be able to figure out that it's cache and just remove it to make way for something I need -- which is way faster than having to swap out chunks of your application to disk.
Imagine the worst-case scenario here, where I don't have enough RAM to reliably cache the file you're reading -- chances are, as you read it, it'll be swapping something else out to disk. If it's really bad, it might be swapping out the very bits of RAM you're reading into, so you're now copying from a file into swap, so you can then read out of very-fragmented swap instead of the file. Bravo.
You play a great game for an hour, then bam, two minutes downtime.
Haven't tried this with Steam, but I'd guess it would handle it gracefully. Are you sure you're not confusing this with Ubi?
And it's easy to do that already: Just install a browser with HTML5's geolocation support, and enable it, click "yes" when something wants to know where you are.
Contrast that with your ISP injecting a header into your HTTP traffic, which should be considered a violation of Net Neutrality.
Seems to be a minor thing simply wrong in every single point...
Point #1 is flat wrong on this count:
If drawing images is your goal, then the Canvas object may be powerful enough. But if you want to build specialized 3-D worlds like the ones found in the more sophisticated Flash and Shockwave games, you may be pining for the old days...
Erm... Maybe WebGL isn't officially part of HTML5, but it's there, and Chrome is implementing it. And personally, I'd much rather force people to download a decent open source browser than a decent proprietary plug-in -- there's alway Chrome Frame if you really need it.
Point #2:
some developers deliberately disabled the Flash plug-in to avoid the headaches and overhead of rendering heavy Flash content. That won't be an option in the future.
Bullshit. It'd take less than ten minutes to put this jQuery in a Chrome extension: $('canvas').remove();
Point #3:
Game programmers might store descriptions and artwork locally, saving the time of downloading the information again and again.
That's what HTTP caches are for, and they work for XHR, too!
Please, no one do this. Ever. HTML5 storage is for storing data. When you use it for caches, you add that much more stuff we might inadvertently back up, that much more cache we can't automatically purge (to claim disk space) or expire (from disuse), and you're doing more work to duplicate functionality HTTP already has.
Point #4:
The so-called microformats in HTML5
I'm confused... microformats don't require HTML5, do they?
Point #5 is fine, though it doesn't mention potential privacy concerns.
Point #6:
Google's new format will see some usage, for example in YouTube, but will never reach anywhere close to the ubiquity of H.264.
Erm, do you know something we don't? Last I checked, YouTube is still H.264 -- in a Flash container, no less.
Point #7, I don't care about.
Point #8:
This claim of better security, though, is a bit of a wild guess. The devious minds may use their malice aforethought to take advantage of the nice integration, perhaps drawing PayPal logos with the Canvas object...
So phishing will be easier? Big deal. Hasn't Flash been the biggest vector for actual client-side pwnage for awhile?
Point #9:
Now, if only HTML5 came with the nice collection of tools that Adobe makes for Flash.
Adobe has said they plan to target HTML5.
If the child does not have the self control to study instead of being on Facebook all day, then it's the parents' responsibility to correct that.
Absolutely -- well, also, the child's own responsibility.
I think we agree, I just wanted to put some emphasis on your original post:
It could be that using the computer can replace some studying.
OS X and BSD, maybe. Or OS X and iPhoneOS.
Linux really doesn't share much with OS X. Not the kernel, not the userland tools, not the UI.
Absolutely, but you need a balance. 8+ hours of Hotdog Stand doesn't replace, say, history.
If your argument is that given the right games, computers could entirely replace studying, I'd say that just becomes the new studying -- and again, the problem becomes that kids will be wasting time on Facebook or WoW instead of the more educational uses of a computer.
The point is that they are not in the "real" (as in, physical) world, but that belief is not required -- mathematical truths are true or not, regardless of what people think.
Apparently not. Certainly not more limited than Gmail.
GMailFS was cool, but ultimately a brutal hack compared to a service that's actually designed to offer storage.
Actually, these are irrelevant:
it's not like people will need to use on a frequent basis, and anyone with an iPhone is likely to have access to a computer.
It's more that it needs network access of some sort anyway, and the iPhone has a web browser. So even if you were targeting an iPhone, I don't get why you'd bother to make it an iPhone app.
Just like with Flash, I go out of my way to avoid PDFs.
Flash is theoretically open, though I'm skeptical how much of the spec is open, and what the quality of that spec is, given that there are no workable replacements for it yet. So I'm with you on that -- Flash is not open, and I avoid it when I can, and I consider it a threat to the open Web.
It's also trivial to remove.
PDF, however, I happily view with Okular, and KPDF before that, and gv before that. I wish Chrome would embed Okular instead, but I have to ask, what's your problem with PDFs? They've long since stopped being Adobe's baby and have become an open standard.
render it in-place,
Yes.
in-process
No. Remember, this is Chrome, where the contents of a given tab use a separate process from other tabs, and all of the tabs use a separate process from the tab bar and URL bar itself...
Why would you want the PDF rendering to happen in the same OS process?
using native pdf rendering code
Maybe. Why does it have to be native?
I'm guessing it's less that the computer itself is dumbing anyone down, and more that they're doing it instead of other things. 8+ hours a day doesn't leave a lot of time to study.
Here's the problem:
rote learning is an invaluable method of retaining facts,
And why's that useful? You present it as though it's useful for its own sake. We now live in an age when we have machines to retain facts for us -- the more important skill is relating those facts.
It's also the only way you're really going to learn an extensive list of things like important dates and events.
Well, no. Nothing is important about a date. Events -- even dates -- are important in how they fit into a larger picture, or they're really not important at all.
In particular, rote learning without that larger picture is not only useless, it's ineffective next to learning a system. I couldn't tell you offhand what date the Shot Heard Round the World was fired, nor the date of the original Tea Party, the Stamp Act, the Boston Massacre, etc. What I can tell you is that a bunch of otherwise well-off colonists, who certainly had it better than many much more oppressed (but much more obedient) people today, revolted against the British crown and formed a new, deliberately secular republic.
That's the difference between rote learning and actual learning. Random facts don't add up to anything useful unless you can integrate them, and if you can, they're easier to memorize and even easier to look up when needed.
Can you find 10^100 anywhere? Can you hold it in your hands?
But 10^100 doesn't stop existing, to the extent that it does exist, simply because you stopped thinking about it.