How about a design where you have three CPUs, each running the same software on the same data, and if one gives a different answer, that CPU gets taken offline and support paged automatically to replace it?
Build it at a higher level. Three separate PCs, each running the same software on the same data, and if one gives a different answer, the entire machine gets taken offline and support paged.
The difference is, three PCs can be had for less than three thousand dollars, new, even with monitors and such. How much will one mainframe cost you?
How about a design that lets you run applications 24 hours a day, 7 days a week, with no downtime required for system upgrades?
Does Google qualify? How about Amazon?
There are areas where mainframes eat Unix systems for lunch.
Only if there's an irrational need for it to be exactly one machine.
Which, if it is, what happens if, say, that building explodes?
Disclaimer: I work for IBM
I'll add a disclaimer, too: I work on a project which is currently deployed via Amazon EC2.
Mainframes are used for high-throughput/high availability/high RELIABILITY as well as high-INTEGRITY operations.
For what it's worth, Amazon uses the same model for shopping carts and payment. Both are a requirement -- you don't want to accidentally charge someone twice, or not at all.
Take a look at Amazon's Dynamo paper, if you can find it -- it's a paper on how they built a system on which they can actually dial up and down parameters like availability and integrity.
First, it can run through millions and millions of records very quickly.
A quick Google search of "sex" returns about 849 million results in 0.42 seconds.
So it depends very much what you want to do with those millions of records. If speed wasn't a problem, which language would you rather write that part in?
Throw a few dozen (hundred? thousand?) cheap PCs at it and use MapReduce, and it doesn't matter.
I expect that most payroll systems are done in COBOL. I can't imagine anyone doing it one in C or Java.
I can imagine doing it in Ruby, but that's just me.
What, exactly, is a Payroll system meant to do? And what about that, other than raw speed, is COBOL good at?
As far as the general principle of operation is concerned, your average nuclear (or coal/natural gas/oil, for that matter) power plant is a huge steam engine attached to a generator.
And as far as the general principle of operation is concerned, I'm sure I could find something more modern to replace a mainframe. It wouldn't run COBOL, though.
And those gigantic nuclear reactors aren't burning wood or coal.
So using FTP verses SFTP would be like walking around all day mumbling the combination to your locker and expecting no one to attempted to get it.
If, when they do, they find a locked safe, I'm really not all that worried. In fact, I'm probably more secure than the locker next to me, who relies entirely on the locker itself, and the lock.
I'm not sure why you want to argue that braodcasting a user name and password to a server storing the information is in the least but secure.
Because, as I've demonstrated above, my username and password to that site don't have to be secure.
First, there is no guarantee that someone can crack the SSH.
There is no guarantee that someone can crack the files.
Second, it requires a skill set a little more in depth then running a sniffer program.
So does cracking AES256-encrypted files.
By running SSH, you have effectivly excluded a good portion of potential attackers.
By encrypting my files, I think I'd exclude the same portion.
So, in summary, encrypting my files is no worse than using SSH with unencrypted files -- and probably a bit better.
If I store something important that needs to be secure, it isn't going to be on an insecure server. Period, end of story.
In other words, "I read your argument, and couldn't find anything wrong with it, except the conclusion."
I don't want something discovered by a Romanian, Chinese, or Russian hacker that gets around any encryption out there...
Hey, here's a tinfoil hat. It protects you from aliens and their brain scanners.
You know what else doesn't exist? Romanian, Chinese, or Russian hackers who can get around other encryption.
We have encrypted codings that get broke every year for fun and profit.
With what algorithm? Single DES?
anyone can open and view it just because you used FTP which broadcasted your username and password effectivly allowing someone easy access if they are sniffing either side of the connection?
Whoops, looks like you still haven't figured out about SSH -- which broadcasts the contents of your files to everyone. It just happens to encrypt them first.
If you have to rely on stumbling across the key, you are 1.5 million times more likely to get the right key on the first try.
Correct. 1.5 million times the probability that every atom in your body will jump a foot to the right is still a stupidly small number.
The example I gave...
You mean the one I tore to pieces?
I don't need to try all possible keys.
You're right. You've also failed to read why this doesn't matter:
the probability of a hit in the first 100 years, assuming that the key could be anywhere in the keyspace, is approximately 0.00000000000000000000000000000000000000000000000000189216 -- percent.
No, you're not trying the entire keyspace. The point is that the probability that the key is within the area that you've tried in 100 years is still ridiculously, absurdly, impossibly small.
I'm not sure more likely is the question that should be asked.
Actually, yes, it is, and that's the question you seem to be asking here:
We all know that the web browser can be exploited to compromise a local system.... It is an entirely different story when a man in the middle can take information gained and then gain this access.
Erm, how so?
What, exactly, is stopping the man in the middle from be
While I personally might like to do some of things you mention above I do not make my own choices at work.
Neither do I, though I am listened to.
However, management here does "get it" about standards, and, more importantly, about cross-platform support -- as I've mentioned before on Slashdot, I was allowed to spend roughly an hour tracking down and fixing a bug which is only apparent on Linux.
Management even writes some code of their own, occasionally.
Also note that I went to slaphack.com (your site) and it fails validation due to lack of doctype.
You'll also note that slaphack.com was Last-Modified almost two years ago. I keep looking for a new domain, but I haven't found one I like. I mostly use it these days as something to SSH and VPN to.
If you want to look at a place we're trying to do right, try 3mix.com -- that's where I work. Just ran it through the validator (having never tried before), and it looks like the only place where it's invalid is done by a third-party plugin (the script tags in the body).
If I get time, I'll see what that plugin is doing, and try to fix it. Shouldn't be too difficult. Keep in mind, though, this is under fairly heavy development.
browsers that support application/xhtml+xml already send it in the Accept header with every request.
Actually, no, they don't.
I remember trying this awhile ago. Firefox sent it, but it required some weird parsing rules to detect it. I also seem to remember that Firefox didn't give it any higher a priority than it gave straight html, meaning that with things like Apache, it would just fall back to the default. I suppose I could write an app and detect any mention of it in the Accept header...
However, Safari did not send it. I remember Safari sending something more like "Accept: */*". This was a long time ago, so I may not be remembering right, and they might be sending something else by now...
Which, by the way, is the other problem with the Accept header: every browser has to accept */*, because they can always download the file, or pass it off to another application. But that */* still has meaning -- if I wrote a client that was designed to scrape it for something, I'd probably have a very limited number of content-types listed in my Accept header (if I sent one at all).
I haven't found a reliable way to detect XHTML support this other than to send it to the browser, and see if it renders, or if it presents me with a "Save As" dialog -- and then to maintain a list of known-good User-Agents. I really don't want to do User-Agent detection.
Nope. He has a few good bits, but I thought he was much better on the Daily Show. I find that the best part of both shows is when Stewart calls ahead to Colbert.
Using latin makes it easier to know when you're talking about the "scientific name", since most people don't use latin for talking about other stuff.
They use Latin for praying. Even if you say that science and religion aren't mutually-exclusive, I think you'll agree that they are different enough that people really shouldn't confuse them.
That, and other fields do have interesting names -- software has adopted pretty much every non-proper noun it could get its hand on, and even some proper ones (Python); Physics has all kinds of weird stuff (Boson) plus all kinds of adjectives (Charmed, Strange); Math has all kinds of weird names used to name theorums, but they're actually used as names, not bastardized to be Latin-sounding.
As far as I'm aware, those tasks still exist today, probably moreso than in the 1970's and 1980's, so why would the Mainframe be dying out? Have regular desktop/server processors advanced faster than demand for this data calculation
Pretty much.
Additionally, we've figured out how to network a bunch of regular desktop/server machines to do the job of a mainframe -- and to partition our data among a bunch of smaller machines.
After all...
Mainframes are a bit like supercomputers but better suited to tasks where there's a LOT of input/output data, but not a lot of calculation involved. Payrolls and such.
Is there ever a time when you actually need to look at the payroll at once?
And if you said "yes", there's a fair chance you're wrong -- there's very likely some small subset of the payroll, that just happens to be spread across all records (for example, the sum of all values in a particular column) -- so techniques like map/reduce can still parallize that task.
I'm going to guess there's not a single mainframe at Google. And I'm also going to guess that Google's cluster could easily handle the tasks you've proposed. The only question would be whether two mainframes would be cheaper -- two, of course, because you need redundancy.
The ol' yellow number 2 pencil is still around as well, as is shoe-making, wine-barrel repair, and of course the oldest tool in the book... the tool.
Of these, shoe-making and wine-barrel repair deal with things which are not yet obsolete, and the number 2 pencil has the advantage that it's eraseable, machine-readable, cheap, and requires no batteries.
Like humans all technologies find their place in the universe.
Not really. Seen any steam engines lately?
You see, unlike the things you've listed, the mainframe really provides (as far as I know) no advantage over a modern Linux system (or cluster) other than that people already know it, and that it will run these old COBOL apps.
I do -- mostly because if it sells well enough, economies of scale means it can be made cheaper and faster. It means that the ratio of price to performance drops, as Moore's law says it should.
or that even Apple moved to it
It also means that even if PowerPC was a more elegant architecture, slightly better performance at a given clock speed, with Intel, I'll get dual 2 ghz instead of a single 1.6 ghz chip.
We need Cpus that don't use any power at all unless there is an active operation being performed.
Clockless. Yes, it's been discussed. It's not as trivial as you're pretending.
we'd have superfast computers with very very low power utilization.
Well, let's see: "Superfast". How do you slow them down before they melt, if there's no clock?
"Very low power utilization" -- my laptop CPU slows down to 1 ghz, and I can stop it to put the system on standby. It's kind of klunky, but it works. And it buys me absolutely nothing when I need to slam it up to 100% for some reason.
And by the way: If this is really so easy, go right ahead. If it's as much better as you seem to be claiming, maybe you can make it emulate x86, and thus actually beat Intel and AMD?
It sounds cool, but I don't think you've thought about it enough to know whether it's practical. This:
If we can just make sure that the cpus are basically a series of tubes to carry data
...is not the language of someone who knows what they're talking about.
Disclaimer: I don't know what I'm talking about either, but I at least know the word "clockless", and I know that x86 is lowercase.
XHTML is only needed if you're using another XML-based language on the page,
Doesn't mean it's a bad idea otherwise.
and is very susceptible to errors.
On purpose. That was a design feature -- so people would stop making horribly twisted and downright broken code.
HTML, on the other hand, is less prone to errors, and the page will at least render.
It does, however, require a hell of a lot more complex of a parsing engine, let alone rendering engine.
XHTML, you can just throw through any old dumb XML parser.
Which means that XHTML is more prone to you making a typo (or something like that), that you'll catch immediately, because any browser that supports XHTML will refuse to render it. HTML, on the other hand, will be prone to subtle errors in your document that the browser will silently correct.
So, additionally, HTML is much more prone to errors in the browser's parsing code, as well as subtle errors in the document, so a document may stop working after awhile.
If you have a XHTML1.0 Strict or XHTML1.1 page out there being served as HTML, you have basically served badly formed HTML4.
Except you can make an XHTML document also appear as well-formed HTML4. Meaning you get all of the above benefits, but your users don't have to upgrade their browsers, as long as you can still serve it as text/html.
The only problem is, how do you serve it as XML to supporting browsers, and HTML to nonsupporting browsers, given that there's no way to tell (short of testing every browser) which is which?
Use of database storage, there can be SQL injection against the local database.
Depends where the SQL is coming from. And a properly designed framework should make it difficult to do this.
I'm not convinced SQL was a good choice, but SQLite is probably the simplest thing that could be implemented in all browsers that fills the requirements: decently fast, embeddable, and optimized for lots of small chunks of data.
and there is no UI to manage this.
Is there any standard that requires a UI to manage cookies?
I can't speak for him, but I do, and I'll endorse that statement.
Develop to standards first. Target Firefox first, Safari second, then worry about IE. Put IE-specific hacks in separate stylesheets, and don't even let non-IE browsers see them.
And throw "GetFirefox" links around where you're allowed to.
"I had thought it would be rather nice to call it Mindarus ebayi," said Dr Harrington. "Unfortunately using flippant names to describe new species is rather frowned upon these days."
Quantum physicists have all the fun. When properties of subatomic particles can have names like "Charmed" or "Strange", why can't a species have a fun name, too?
I'm still fairly sure this is true, but I don't remember enough about what they looked like at launch. I doubt they had much more than simply embedded video, which could have been done as easily with an object tag.
and still doesn't
I'm basing this mostly on the fact that if YouTube isn't in the dictionary already, it's likely to be. If they did switch entirely to what I'm proposing, which does work in a few browsers, I imagine it would be other browsers rushing to support YouTube, rather than the other way around.
Now, of course, you just need to find a reason why they'd want to do that.
Not if it only provides low power, enough to read the memory.
So I provide the high power (battery), and short out the entire USB system, and everything it's attached to.
Perhaps risk of significant loss of life isn't that high... but if one of them did go off during flight? There'd be outrage!
Yeah, from the one Nano owner. It's doubtful anyone else would notice.
But you know what else? People already have outrage about not being able to bring stuff on planes.
if the concept of flying without an ipod nano scares you
Nice strawman.
I don't have a nano. I don't have any iPod, or, in fact, an iAnything.
But I do think it's pretty unreasonable to start banning portable electronics because they might explode... inside their plastic case, possibly causing slight burns on the hands of the person holding it! Oh no!
More generally, I think safety theater is just as stupid as security theater.
You can use iframe to make clicking the video go to youtube and show transparent interactive overlay interactive advertisements?
No, I can use an iframe to include HTML, CSS, and JavaScript -- the tools needed for AJAX.
I can then hover some AJAX controls over the video, and make clicking the video do whatever I want -- or show whatever I want on top of the video, translucently if that's better...
Slashdot Mirror
How about a design where you have three CPUs, each running the same software on the same data, and if one gives a different answer, that CPU gets taken offline and support paged automatically to replace it?
Build it at a higher level. Three separate PCs, each running the same software on the same data, and if one gives a different answer, the entire machine gets taken offline and support paged.
The difference is, three PCs can be had for less than three thousand dollars, new, even with monitors and such. How much will one mainframe cost you?
How about a design that lets you run applications 24 hours a day, 7 days a week, with no downtime required for system upgrades?
Does Google qualify? How about Amazon?
There are areas where mainframes eat Unix systems for lunch.
Only if there's an irrational need for it to be exactly one machine.
Which, if it is, what happens if, say, that building explodes?
Disclaimer: I work for IBM
I'll add a disclaimer, too: I work on a project which is currently deployed via Amazon EC2.
Mainframes are used for high-throughput/high availability/high RELIABILITY as well as high-INTEGRITY operations.
For what it's worth, Amazon uses the same model for shopping carts and payment. Both are a requirement -- you don't want to accidentally charge someone twice, or not at all.
Take a look at Amazon's Dynamo paper, if you can find it -- it's a paper on how they built a system on which they can actually dial up and down parameters like availability and integrity.
First, it can run through millions and millions of records very quickly.
A quick Google search of "sex" returns about 849 million results in 0.42 seconds.
So it depends very much what you want to do with those millions of records. If speed wasn't a problem, which language would you rather write that part in?
Throw a few dozen (hundred? thousand?) cheap PCs at it and use MapReduce, and it doesn't matter.
I expect that most payroll systems are done in COBOL. I can't imagine anyone doing it one in C or Java.
I can imagine doing it in Ruby, but that's just me.
What, exactly, is a Payroll system meant to do? And what about that, other than raw speed, is COBOL good at?
As far as the general principle of operation is concerned, your average nuclear (or coal/natural gas/oil, for that matter) power plant is a huge steam engine attached to a generator.
And as far as the general principle of operation is concerned, I'm sure I could find something more modern to replace a mainframe. It wouldn't run COBOL, though.
And those gigantic nuclear reactors aren't burning wood or coal.
words like "Charmed" and "Strange" may have a diffrent meaning a century or two from now.
I'm not sure they could get worse than they are for describing what's actually going on.
So using FTP verses SFTP would be like walking around all day mumbling the combination to your locker and expecting no one to attempted to get it.
If, when they do, they find a locked safe, I'm really not all that worried. In fact, I'm probably more secure than the locker next to me, who relies entirely on the locker itself, and the lock.
I'm not sure why you want to argue that braodcasting a user name and password to a server storing the information is in the least but secure.
Because, as I've demonstrated above, my username and password to that site don't have to be secure.
First, there is no guarantee that someone can crack the SSH.
There is no guarantee that someone can crack the files.
Second, it requires a skill set a little more in depth then running a sniffer program.
So does cracking AES256-encrypted files.
By running SSH, you have effectivly excluded a good portion of potential attackers.
By encrypting my files, I think I'd exclude the same portion.
So, in summary, encrypting my files is no worse than using SSH with unencrypted files -- and probably a bit better.
If I store something important that needs to be secure, it isn't going to be on an insecure server. Period, end of story.
In other words, "I read your argument, and couldn't find anything wrong with it, except the conclusion."
I don't want something discovered by a Romanian, Chinese, or Russian hacker that gets around any encryption out there...
Hey, here's a tinfoil hat. It protects you from aliens and their brain scanners.
You know what else doesn't exist? Romanian, Chinese, or Russian hackers who can get around other encryption.
We have encrypted codings that get broke every year for fun and profit.
With what algorithm? Single DES?
anyone can open and view it just because you used FTP which broadcasted your username and password effectivly allowing someone easy access if they are sniffing either side of the connection?
Whoops, looks like you still haven't figured out about SSH -- which broadcasts the contents of your files to everyone. It just happens to encrypt them first.
If you have to rely on stumbling across the key, you are 1.5 million times more likely to get the right key on the first try.
Correct. 1.5 million times the probability that every atom in your body will jump a foot to the right is still a stupidly small number.
The example I gave...
You mean the one I tore to pieces?
I don't need to try all possible keys.
You're right. You've also failed to read why this doesn't matter:
the probability of a hit in the first 100 years, assuming that the key could be anywhere in the keyspace, is approximately 0.00000000000000000000000000000000000000000000000000189216 -- percent.
No, you're not trying the entire keyspace. The point is that the probability that the key is within the area that you've tried in 100 years is still ridiculously, absurdly, impossibly small.
The math is nothing but an illusion.
Actually, math is hard fact -- the only hard fact.
I'm not sure more likely is the question that should be asked.
Actually, yes, it is, and that's the question you seem to be asking here:
We all know that the web browser can be exploited to compromise a local system.... It is an entirely different story when a man in the middle can take information gained and then gain this access.
Erm, how so?
What, exactly, is stopping the man in the middle from be
While I personally might like to do some of things you mention above I do not make my own choices at work.
Neither do I, though I am listened to.
However, management here does "get it" about standards, and, more importantly, about cross-platform support -- as I've mentioned before on Slashdot, I was allowed to spend roughly an hour tracking down and fixing a bug which is only apparent on Linux.
Management even writes some code of their own, occasionally.
Also note that I went to slaphack.com (your site) and it fails validation due to lack of doctype.
You'll also note that slaphack.com was Last-Modified almost two years ago. I keep looking for a new domain, but I haven't found one I like. I mostly use it these days as something to SSH and VPN to.
If you want to look at a place we're trying to do right, try 3mix.com -- that's where I work. Just ran it through the validator (having never tried before), and it looks like the only place where it's invalid is done by a third-party plugin (the script tags in the body).
If I get time, I'll see what that plugin is doing, and try to fix it. Shouldn't be too difficult. Keep in mind, though, this is under fairly heavy development.
browsers that support application/xhtml+xml already send it in the Accept header with every request.
Actually, no, they don't.
I remember trying this awhile ago. Firefox sent it, but it required some weird parsing rules to detect it. I also seem to remember that Firefox didn't give it any higher a priority than it gave straight html, meaning that with things like Apache, it would just fall back to the default. I suppose I could write an app and detect any mention of it in the Accept header...
However, Safari did not send it. I remember Safari sending something more like "Accept: */*". This was a long time ago, so I may not be remembering right, and they might be sending something else by now...
Which, by the way, is the other problem with the Accept header: every browser has to accept */*, because they can always download the file, or pass it off to another application. But that */* still has meaning -- if I wrote a client that was designed to scrape it for something, I'd probably have a very limited number of content-types listed in my Accept header (if I sent one at all).
I haven't found a reliable way to detect XHTML support this other than to send it to the browser, and see if it renders, or if it presents me with a "Save As" dialog -- and then to maintain a list of known-good User-Agents. I really don't want to do User-Agent detection.
Do you watch the colbert report?
Nope. He has a few good bits, but I thought he was much better on the Daily Show. I find that the best part of both shows is when Stewart calls ahead to Colbert.
Using latin makes it easier to know when you're talking about the "scientific name", since most people don't use latin for talking about other stuff.
They use Latin for praying. Even if you say that science and religion aren't mutually-exclusive, I think you'll agree that they are different enough that people really shouldn't confuse them.
That, and other fields do have interesting names -- software has adopted pretty much every non-proper noun it could get its hand on, and even some proper ones (Python); Physics has all kinds of weird stuff (Boson) plus all kinds of adjectives (Charmed, Strange); Math has all kinds of weird names used to name theorums, but they're actually used as names, not bastardized to be Latin-sounding.
As far as I'm aware, those tasks still exist today, probably moreso than in the 1970's and 1980's, so why would the Mainframe be dying out? Have regular desktop/server processors advanced faster than demand for this data calculation
Pretty much.
Additionally, we've figured out how to network a bunch of regular desktop/server machines to do the job of a mainframe -- and to partition our data among a bunch of smaller machines.
After all...
Mainframes are a bit like supercomputers but better suited to tasks where there's a LOT of input/output data, but not a lot of calculation involved. Payrolls and such.
Is there ever a time when you actually need to look at the payroll at once?
And if you said "yes", there's a fair chance you're wrong -- there's very likely some small subset of the payroll, that just happens to be spread across all records (for example, the sum of all values in a particular column) -- so techniques like map/reduce can still parallize that task.
I'm going to guess there's not a single mainframe at Google. And I'm also going to guess that Google's cluster could easily handle the tasks you've proposed. The only question would be whether two mainframes would be cheaper -- two, of course, because you need redundancy.
The ol' yellow number 2 pencil is still around as well, as is shoe-making, wine-barrel repair, and of course the oldest tool in the book ... the tool.
Of these, shoe-making and wine-barrel repair deal with things which are not yet obsolete, and the number 2 pencil has the advantage that it's eraseable, machine-readable, cheap, and requires no batteries.
Like humans all technologies find their place in the universe.
Not really. Seen any steam engines lately?
You see, unlike the things you've listed, the mainframe really provides (as far as I know) no advantage over a modern Linux system (or cluster) other than that people already know it, and that it will run these old COBOL apps.
Should be: I didn't read TFA.
Ok, I'm not going to post before 10 AM... ever again.
I don't know, it struck me as more an Aussie thing -- but then, I didn't read the summary, and I think I've actually managed to make it worse.
I don't care how well it's selling
I do -- mostly because if it sells well enough, economies of scale means it can be made cheaper and faster. It means that the ratio of price to performance drops, as Moore's law says it should.
or that even Apple moved to it
It also means that even if PowerPC was a more elegant architecture, slightly better performance at a given clock speed, with Intel, I'll get dual 2 ghz instead of a single 1.6 ghz chip.
We need Cpus that don't use any power at all unless there is an active operation being performed.
Clockless. Yes, it's been discussed. It's not as trivial as you're pretending.
we'd have superfast computers with very very low power utilization.
Well, let's see: "Superfast". How do you slow them down before they melt, if there's no clock?
"Very low power utilization" -- my laptop CPU slows down to 1 ghz, and I can stop it to put the system on standby. It's kind of klunky, but it works. And it buys me absolutely nothing when I need to slam it up to 100% for some reason.
And by the way: If this is really so easy, go right ahead. If it's as much better as you seem to be claiming, maybe you can make it emulate x86, and thus actually beat Intel and AMD?
It sounds cool, but I don't think you've thought about it enough to know whether it's practical. This:
If we can just make sure that the cpus are basically a series of tubes to carry data
...is not the language of someone who knows what they're talking about.
Disclaimer: I don't know what I'm talking about either, but I at least know the word "clockless", and I know that x86 is lowercase.
I run Firefox for NoScript and AdBlock...I could care less about rendering a page .002 picoseconds faster.
And WTF did that have to do with this article?
XHTML is only needed if you're using another XML-based language on the page,
Doesn't mean it's a bad idea otherwise.
and is very susceptible to errors.
On purpose. That was a design feature -- so people would stop making horribly twisted and downright broken code.
HTML, on the other hand, is less prone to errors, and the page will at least render.
It does, however, require a hell of a lot more complex of a parsing engine, let alone rendering engine.
XHTML, you can just throw through any old dumb XML parser.
Which means that XHTML is more prone to you making a typo (or something like that), that you'll catch immediately, because any browser that supports XHTML will refuse to render it. HTML, on the other hand, will be prone to subtle errors in your document that the browser will silently correct.
So, additionally, HTML is much more prone to errors in the browser's parsing code, as well as subtle errors in the document, so a document may stop working after awhile.
If you have a XHTML1.0 Strict or XHTML1.1 page out there being served as HTML, you have basically served badly formed HTML4.
Except you can make an XHTML document also appear as well-formed HTML4. Meaning you get all of the above benefits, but your users don't have to upgrade their browsers, as long as you can still serve it as text/html.
The only problem is, how do you serve it as XML to supporting browsers, and HTML to nonsupporting browsers, given that there's no way to tell (short of testing every browser) which is which?
Use of database storage, there can be SQL injection against the local database.
Depends where the SQL is coming from. And a properly designed framework should make it difficult to do this.
I'm not convinced SQL was a good choice, but SQLite is probably the simplest thing that could be implemented in all browsers that fills the requirements: decently fast, embeddable, and optimized for lots of small chunks of data.
and there is no UI to manage this.
Is there any standard that requires a UI to manage cookies?
If HTML5 gets popular, there will be a UI.
I can't speak for him, but I do, and I'll endorse that statement.
Develop to standards first. Target Firefox first, Safari second, then worry about IE. Put IE-specific hacks in separate stylesheets, and don't even let non-IE browsers see them.
And throw "GetFirefox" links around where you're allowed to.
Do all names have to sound latin?
Apparently, yes:
"I had thought it would be rather nice to call it Mindarus ebayi," said Dr Harrington.
"Unfortunately using flippant names to describe new species is rather frowned upon these days."
Quantum physicists have all the fun. When properties of subatomic particles can have names like "Charmed" or "Strange", why can't a species have a fun name, too?
For 20 bucks
Sounds like you need to do the currency conversion.
Do all names have to sound latin?
YouTube never needed Flash
I'm still fairly sure this is true, but I don't remember enough about what they looked like at launch. I doubt they had much more than simply embedded video, which could have been done as easily with an object tag.
and still doesn't
I'm basing this mostly on the fact that if YouTube isn't in the dictionary already, it's likely to be. If they did switch entirely to what I'm proposing, which does work in a few browsers, I imagine it would be other browsers rushing to support YouTube, rather than the other way around.
Now, of course, you just need to find a reason why they'd want to do that.
"Don't be evil."
Not if it only provides low power, enough to read the memory.
So I provide the high power (battery), and short out the entire USB system, and everything it's attached to.
Perhaps risk of significant loss of life isn't that high... but if one of them did go off during flight? There'd be outrage!
Yeah, from the one Nano owner. It's doubtful anyone else would notice.
But you know what else? People already have outrage about not being able to bring stuff on planes.
if the concept of flying without an ipod nano scares you
Nice strawman.
I don't have a nano. I don't have any iPod, or, in fact, an iAnything.
But I do think it's pretty unreasonable to start banning portable electronics because they might explode... inside their plastic case, possibly causing slight burns on the hands of the person holding it! Oh no!
More generally, I think safety theater is just as stupid as security theater.
You can use iframe to make clicking the video go to youtube and show transparent interactive overlay interactive advertisements?
No, I can use an iframe to include HTML, CSS, and JavaScript -- the tools needed for AJAX.
I can then hover some AJAX controls over the video, and make clicking the video do whatever I want -- or show whatever I want on top of the video, translucently if that's better...