Look the reality is that you CAN'T put privacy issues aside. That is the entire argument. Privacy issues exist and while they are not technical in nature they are of the legal nature, and that trumps technical!
Which privacy issues are you talking about? Have you actually looked into how to deal with these things?
For example, you could cloud-source some of your basic data processing while keeping the personally-identifiable data on those cloud services encrypted. All the cloud service is going to know is that it's a bunch of bits that it can't look inside. Only once you bring the data back inside your organization do you let the key to unlock it get anywhere close. And the technology to do this is mature. (OK, so you can't index the private fields on the remote service. That's just a reason why not everything belongs in the cloud...)
Yes, they've got to be careful. How is that so different from what happened before? Even then they should have been just as careful. (Not all were, but that might actually mean that the rise of cloud computing will encourage the take-up of a few more best practices.)
Those that can pay for it namely enterprises will not take advantage of cloud computing since many questions are left unanswered.
The evidence seems to be pointing in the opposite direction; enterprises love cloud computing because it reduces their datacenter costs so much. But they are also very careful about how they move critical things onto such systems; not all SLAs of cloud computing services are as asymmetric as Amazon's, and many enterprises (both small and large) think this is a good trade...
Amazon does use some kind of virtual machine images (just running the stuff under Xen I think?). They *should* make it so VMWare, qemu, etc. images could be converted to AMI (Amazon Machine Image) files though, I certianly agree.
Scope for someone to write some OSS to do the transformation? Why wait for Amazon to do it for you?
That of course assumes the extrapolation is meaningful, but it might give a rough indication of what to expect with very little expenditure.
That's been done I bet, but you still need to run the experiment to check whether that extrapolation really is meaningful. There isn't really any substitute, because the fundamental problem with all models (and theories and extrapolations) is that they leave out details, and if you push the model far out of where it was designed for you can get other effects dominating.
For example, you can extrapolate gravitation down to the nanometer scale, but that doesn't mean that it lets you fully understand the behavior of matter in that domain. Electrostatic effects tend to rule at that level instead, yet they're not part of any (sane) model of gravitation that I've heard of. Overall, this just tells you to beware of taking models too far.
Even that's recent - when I went to school the only thing we did was an hour on WW1, and that was just that someone shot Archduke Ferdinand and Britain went to war over it.. which doesn't even make sense (but as a child you don't question, and this was pre-internet and definately pre-history channel so we didn't have any other sources).
The roots of WW1 are rather complicated, but it seems to have been an outcome of a complex system (european imperial politics) that was just a catastrophe (in a mathematical sense) waiting to happen. The shooting of the Archduke was just the trigger that set it all off.
If nonprofits have too much money at the end of the year, I guess they have to pay it out in bonuses and retro-active benefits to their executives, right?
You're being way too cynical there. The profit (after reinvestment) will/should be used to increase the amount of reserves to help tide over the years when there really is no profit at all. Indeed, of the non-profit orgs where I know the financials, a profitable year is rather too rare to be a big problem...
But now that I actually understand what you wrote (heh): what areas does a real database system have a huge speed advantage? Concurrency, certainly, is a big weakness of SQLite (though it isn't bad in the small scale).
Curiously, the SQLite devs say that the point when you should be switching up to something like Postgres or Oracle is when you are getting real problems with concurrent writes. In other words, they acknowledge this as an issue and say that it is a non-goal. (On the other hand, the other DB engines listed are a lot more heavyweight in administration terms, so you really are paying for this additional power. That is good and proper...)
Every day we start looking more and more like soviet russia. Just look at the slippery slope that the British have fallen down. They are getting ever so close to the bottom.
You should be aware that, in terms of asshat-ery in schools, there is a lot worse going on in the US than in the UK. IIRC, in UK schools they're much more likely to get the official process involved sooner which is at least less open to these sorts of abuses.
I used to live in California. They may not discriminate on ethnicity or religion, but go visit the Bay Area with an NRA teeshirt and a rifle to hunt some deer and see how nice everyone is to you.
You're doing it wrong; not enough gadgets there for the Valley. If you instead take a rifle-mount laser capable of killing deer, you'll get a much better reception.
It's better to have specifically declared shared memory with inherently limited access. At the very least, analysis could catch unlocked accesses to known-shared memory.
You're better off going to a message-passing model; they're theoretically much more tractable (there are several schemes that have had decades of work done and even spawned programming languages) and they scale up to multi-machine computing (e.g. cluster-scale) much more easily.
Shared memory parallelism is just plain nasty. Occasionally useful, but always nasty. Use with care and good taste.
Why break into quadrants if you have 8 or 16 cores available?
Because it's often impolite to assume that nothing else is going on on the machine at the same time? (This actually means that the video encoder needs to know how many cores are assigned to it so that it knows how many ways to partition the data. Let the OS worry about keeping some resources back for other activity...)
Just print off reflective duplicates of politician's plates, and those of their friends, relatives, and supporters, then tape them over yours (if you have a common make, model & color of vehicle with no distinguishing characterstics), then run lots of red lights late at night in disreputable districts when there is no traffic.
See how long the cameras last.
Of course, if the cops catch you doing that sort of thing then you'll have guaranteed that you do jail time. Congratulations! (Nobody likes a fraudster.)
You have the right to travel on it, but noone said we can't prevent you from DRIVING YOURSELF. We provide busses...
There are also taxis available for people who prefer the private-enterprise approach. Or you can hire a chauffeur. Or hitch-hike. Or get a friend to give you a lift. etc.
So many choices that don't involve you being an ass. If you're going to drive, at least be nice and do so safely and with at least some insurance. That's better for everyone, you included!
3. A corollary to #2 - Lots of companies are "discovering" they don't need an IT department anymore. Most of the programming jobs will be for vendors, if the whole "cloud computing" fad turns out to be more than a fad.
Cloud computing will be a fad. As we've seen outages with both Google and Amazon, several vendors closing doors and leaving their customers high and dry I think soon somebody in management is either going to take attention or fail miserably. Either way the risk and costs are greater in all my calculations and unless the price goes down and reliability up, no serious user is going to trust their company to a 'cloud'
Well, it is a fad for sure, but it looks like it will keep on going and companies will put their data and code on it. But with decent SLAs; not the crap ones that some firms seem to think are a good idea. Yes, the buyers will have to pay extra for that, but it's not really a bad deal.
OTOH, bringing stuff in-house won't necessarily make things better either. I've seen supposedly enterprise-grade critical services where they were expensive, slow and struggling to even achieve 90% uptime, with fairly frequent interruptions to service during peak times. Because it was an in-house service, the manager in charge of the service's main method of getting custom was to try to apply political (note, not as in political parties) pressure to stop people from going to cheaper and better alternatives (whether internal or external). This has been the source of a lot of pain for many people (curiously not myself BTW; it wasn't a service I needed).
In short, my advice to anyone thinking about going to the Cloud is to think very hard about how much you really value the service that you will be getting and what the consequences of downtime or unavailability will be. Once you know that, write the contract, the SLA, etc. so that the service provider puts appropriate value on providing the service to you. If they won't negotiate on the SLA, they're a bunch of cheap-ass cowboys; would you want to entrust something really important to a low-bidder who doesn't care?
Ghosts are not SciFi. Vampires are not SciFi. Magic is not SciFi. Wrestling is not SciFi. Horror can be SciFi, but not if it includes ghosts and/or magic and/or wrestling.
SciFi is simple - put the story in the future or on another planet or in space. Done.
I've got this idea for a show involving wrestling magical vampire ghosts on Mars with the losers turned into blue cheese. How would you categorize it? (I put the blue cheese in for horror effect; that stuff horrifies me...)
Genius developers like that should be employed as designers, not coders. By the time you start writing code, there should be no problems left that take even an afternoon, much less a month, to solve.
This just ain't so. The notion that everything should be in design and code should be done by interchangeable monkeys doesn't work. It is really popular with people who want a more predictable world, but wishing don't make it so. In the real world, the programming work can be genuinely hard, not because the design is flawed, but because the underlying task requires some amount of coherent thought.
Or rather, if it is true, the program is really already written at the design level and what you've got below that is - or ought to be - mechanical translation. I don't normally worry myself over how my compiler works, after all.
Your assumption that "brilliant" code is badly-written is unsupported. Brilliant code need not be hard to understand; in fact, it's often simple to understand. What's hard is realizing that there's an easy-to-understand way to do something complicated.
Well, depends on whether you're talking about brilliant code or "brilliant" code. The former makes a tough job trivial and clear and can even change how other people think about the original problem, and it will either be well documented or so clear that it doesn't need it. The latter is what the Joshes of the world produce...
Basically, it sounds to me like you've either never seen, or never understood, actual genius-level work. It isn't the same stuff, only faster. While the factor of 160 sounds a bit high, there are certainly plenty of cases of brilliant developers being able to trim days or weeks off of project schedules by finding elegant solutions to problems which looked like they would require a long and painful slog.
The other indicator of real genius-level stuff is that it enables something previously thought impossible or utterly impractical. The first compiler was an example of a genius-level change, no matter how obvious it seems now.
He has no choice but to honor the contract they've made with customers.
Why? The customers don't have a contract with the sysadmin, but rather with the ISP as an organization. Which isn't to say that the sysadmin should not make technical suggestions for how to introduce some sort of "fair-use" policies, but it's not his ass that is personally on the line here and bandwidth-throttling is hardly the sort of grand crime that justifies not doing it.
And in any case, the contracts probably say (or damn well should say!) that customers agree to not use the service in a way that significantly degrades it for others.
What, you mean I can't make every shmuck that comes in my hospital click on an EULA that says that they can't sue me even if I kill them?
Sure you can! But the courts will ignore it I bet; some types of clause are generally reckoned to be unconscionable and "can't sue me if I kill you" would be a prime candidate for that sort of thing.
The only reason the text of a page doesn't load first today is that web browsers are badly behaved. Firefox will often refuse to render a page until it gets all the content.
Firefox (and, to be fair, all other modern browsers) loads content asynchronously just fine, though with modern networks and HTTP pipelining it's not much of an issue for the textual parts. The real issue is that much javascript is still synchronous and hooked into locations where it hinders all page rendering until it has been loaded and executed in full. Advertisers are particularly bad this way, but are not the only villains.
There were Gopher clients that didn't need external viewers for images [...] Adding HTML to Gopher would have solved a lot of Gopher's problems, but the real problem was that the Gopher protocol wasn't very flexible.
The first time I encountered Mosaic was with HTTP/HTML, but the performance even for content within the same institution was terrible; trying to view the help pages (online at NCSA) was a recipe for effectively hanging the client. When I started actually using Mosaic, it was as a more-usable Gopher client. It sucked so much less than xgopher. Then one of the other students figured out how to make the university gopher server provide pages that were interpreted as HTML by hacking the title by which the page was stored so it appeared to end with ".html"; the lower overhead of the Gopher protocol really helped on the slow networks of that time. (Once you've got delivery of HTML, you can ignore Gopher's crappy hierarchical model.)
It wasn't long after that before networking upgrades meant that we could use HTTP practically; the modern world had arrived. Since then, the big changes have been Netscape (asynch loading of content) and Google (a reasonable chance at finding something useful) - nothing else compares with those two, though pipelining perhaps comes closest - but they are as nothing when stood next to going from hierarchic data to webs of hypertext.
"The final solution, is we need properly written applications and desktop libraries. The proper way of doing this sort of thing is not to have hundreds of tiny files in private ~/.gnome2* and ~/.kde2* directories. Instead, the answer is to use a proper small database like sqllite for application registries, but fixed up so that it allocates and releases space for its database in chunks, and that it uses fdatawrite() instead of fsync() to guarantee that data is written on disk. If sqllite had been properly written so that it grabbed new space for its database storage in chunks of 16k or 64k, and released space when it was no longer needed in similar large chunks via truncate(), and if it used fdatasync() instead of fsync(), the performance problems with FireFox 3 wouldn't have taken place."
The issue with Ted's comment is... sqlite3 does just that; I grepped the source, and it's certainly using fdatasync(). If it's getting anything wrong, that's a bug report that should be filed.
If you want a masterclass in just how nasty data integrity can get, read the file in sqlite3 that implements these things (for unix). I'm not sure if the parts dealing with synchronization are as scary as the portions on file locking...
What exactly does Godel's theorem have to do with what you just said? The incompleteness theorem deals with axiomatized systems. This leads me to think that you might be confusing the popular meaning of "language" with the mathematical definition. People (at least normal people) do not communicate with mathematical languages.
If you have an unambiguous system, that means it must be possible to give an exact translation from it into mathematics. After all, that's what mathematical notation really is, a way of unambiguously saying things.
But wait! Goedel says that there are no interesting complete mathematical systems (yeah, I do know what axiomatization is, thankyouverymuch). From that we can then deduce that the language that is being translated from must either be able to describe paradoxical entities whose interpretation/valuation must be necessarily ambiguous (that's what Goedel actually did, it's the heart of his proof) or that the originating language is unutterably trivial - that it can't even talk about simple arithmetic for example, let alone actual complex concepts.
The heart of my real argument though was that most people prefer ambiguity. If someone writes "my love is like a red, red rose", it shouldn't have to include a frequency profile of the reflected light off the rose or a precise description of the variety. (More seriously, many poets explicitly want the ambiguity; the reader is supposed to have to work to extract the correct meaning(s) of the poem.)
I don't think this can be examined without language issues. Lojban attempts to make a parsable constructed language (currently undergoing a few grammar issues, but mostly locked down). As we get closer to the Singularity, with regards to infant-style general AI and perhaps even transhuman implants (thought detector or such), we'll see perhaps a myriad of unambiguous languages.
Any language that is truly unambiguous is uninteresting. Firstly, you've got Goedel incompleteness to worry about (which stems from statements that are fundamentally ambiguous as to their interpretation, such as "this statement is false"). Secondly, languages are there for people to communicate with, and people seem to prefer ambiguity. Ask a poet if you need proof of that.
You forgot another big reason for a company to disappear instead of shrink: Governmental involvement.
That's almost always a result of bad management though, and bad management will make the results of governmental involvement worse. If the management is rubbish, the company is in trouble.
Slashdot Mirror
The stream of bullshit never ends.
From the way you're going on about it, I presume you must be a member of the committee that designed the STL?
Privacy issues aside
Look the reality is that you CAN'T put privacy issues aside. That is the entire argument. Privacy issues exist and while they are not technical in nature they are of the legal nature, and that trumps technical!
Which privacy issues are you talking about? Have you actually looked into how to deal with these things?
For example, you could cloud-source some of your basic data processing while keeping the personally-identifiable data on those cloud services encrypted. All the cloud service is going to know is that it's a bunch of bits that it can't look inside. Only once you bring the data back inside your organization do you let the key to unlock it get anywhere close. And the technology to do this is mature. (OK, so you can't index the private fields on the remote service. That's just a reason why not everything belongs in the cloud...)
Yes, they've got to be careful. How is that so different from what happened before? Even then they should have been just as careful. (Not all were, but that might actually mean that the rise of cloud computing will encourage the take-up of a few more best practices.)
Those that can pay for it namely enterprises will not take advantage of cloud computing since many questions are left unanswered.
The evidence seems to be pointing in the opposite direction; enterprises love cloud computing because it reduces their datacenter costs so much. But they are also very careful about how they move critical things onto such systems; not all SLAs of cloud computing services are as asymmetric as Amazon's, and many enterprises (both small and large) think this is a good trade...
Amazon does use some kind of virtual machine images (just running the stuff under Xen I think?). They *should* make it so VMWare, qemu, etc. images could be converted to AMI (Amazon Machine Image) files though, I certianly agree.
Scope for someone to write some OSS to do the transformation? Why wait for Amazon to do it for you?
That of course assumes the extrapolation is meaningful, but it might give a rough indication of what to expect with very little expenditure.
That's been done I bet, but you still need to run the experiment to check whether that extrapolation really is meaningful. There isn't really any substitute, because the fundamental problem with all models (and theories and extrapolations) is that they leave out details, and if you push the model far out of where it was designed for you can get other effects dominating.
For example, you can extrapolate gravitation down to the nanometer scale, but that doesn't mean that it lets you fully understand the behavior of matter in that domain. Electrostatic effects tend to rule at that level instead, yet they're not part of any (sane) model of gravitation that I've heard of. Overall, this just tells you to beware of taking models too far.
Even that's recent - when I went to school the only thing we did was an hour on WW1, and that was just that someone shot Archduke Ferdinand and Britain went to war over it.. which doesn't even make sense (but as a child you don't question, and this was pre-internet and definately pre-history channel so we didn't have any other sources).
The roots of WW1 are rather complicated, but it seems to have been an outcome of a complex system (european imperial politics) that was just a catastrophe (in a mathematical sense) waiting to happen. The shooting of the Archduke was just the trigger that set it all off.
Even worse, it's state subsidized tax evasion.
If nonprofits have too much money at the end of the year, I guess they have to pay it out in bonuses and retro-active benefits to their executives, right?
You're being way too cynical there. The profit (after reinvestment) will/should be used to increase the amount of reserves to help tide over the years when there really is no profit at all. Indeed, of the non-profit orgs where I know the financials, a profitable year is rather too rare to be a big problem...
But now that I actually understand what you wrote (heh): what areas does a real database system have a huge speed advantage? Concurrency, certainly, is a big weakness of SQLite (though it isn't bad in the small scale).
Curiously, the SQLite devs say that the point when you should be switching up to something like Postgres or Oracle is when you are getting real problems with concurrent writes. In other words, they acknowledge this as an issue and say that it is a non-goal. (On the other hand, the other DB engines listed are a lot more heavyweight in administration terms, so you really are paying for this additional power. That is good and proper...)
Every day we start looking more and more like soviet russia. Just look at the slippery slope that the British have fallen down. They are getting ever so close to the bottom.
You should be aware that, in terms of asshat-ery in schools, there is a lot worse going on in the US than in the UK. IIRC, in UK schools they're much more likely to get the official process involved sooner which is at least less open to these sorts of abuses.
I used to live in California. They may not discriminate on ethnicity or religion, but go visit the Bay Area with an NRA teeshirt and a rifle to hunt some deer and see how nice everyone is to you.
You're doing it wrong; not enough gadgets there for the Valley. If you instead take a rifle-mount laser capable of killing deer, you'll get a much better reception.
It's better to have specifically declared shared memory with inherently limited access. At the very least, analysis could catch unlocked accesses to known-shared memory.
You're better off going to a message-passing model; they're theoretically much more tractable (there are several schemes that have had decades of work done and even spawned programming languages) and they scale up to multi-machine computing (e.g. cluster-scale) much more easily.
Shared memory parallelism is just plain nasty. Occasionally useful, but always nasty. Use with care and good taste.
Why break into quadrants if you have 8 or 16 cores available?
Because it's often impolite to assume that nothing else is going on on the machine at the same time? (This actually means that the video encoder needs to know how many cores are assigned to it so that it knows how many ways to partition the data. Let the OS worry about keeping some resources back for other activity...)
Just print off reflective duplicates of politician's plates, and those of their friends, relatives, and supporters, then tape them over yours (if you have a common make, model & color of vehicle with no distinguishing characterstics), then run lots of red lights late at night in disreputable districts when there is no traffic.
See how long the cameras last.
Of course, if the cops catch you doing that sort of thing then you'll have guaranteed that you do jail time. Congratulations! (Nobody likes a fraudster.)
You have the right to travel on it, but noone said we can't prevent you from DRIVING YOURSELF. We provide busses...
There are also taxis available for people who prefer the private-enterprise approach. Or you can hire a chauffeur. Or hitch-hike. Or get a friend to give you a lift. etc.
So many choices that don't involve you being an ass. If you're going to drive, at least be nice and do so safely and with at least some insurance. That's better for everyone, you included!
3. A corollary to #2 - Lots of companies are "discovering" they don't need an IT department anymore. Most of the programming jobs will be for vendors, if the whole "cloud computing" fad turns out to be more than a fad.
Cloud computing will be a fad. As we've seen outages with both Google and Amazon, several vendors closing doors and leaving their customers high and dry I think soon somebody in management is either going to take attention or fail miserably. Either way the risk and costs are greater in all my calculations and unless the price goes down and reliability up, no serious user is going to trust their company to a 'cloud'
Well, it is a fad for sure, but it looks like it will keep on going and companies will put their data and code on it. But with decent SLAs; not the crap ones that some firms seem to think are a good idea. Yes, the buyers will have to pay extra for that, but it's not really a bad deal.
OTOH, bringing stuff in-house won't necessarily make things better either. I've seen supposedly enterprise-grade critical services where they were expensive, slow and struggling to even achieve 90% uptime, with fairly frequent interruptions to service during peak times. Because it was an in-house service, the manager in charge of the service's main method of getting custom was to try to apply political (note, not as in political parties) pressure to stop people from going to cheaper and better alternatives (whether internal or external). This has been the source of a lot of pain for many people (curiously not myself BTW; it wasn't a service I needed).
In short, my advice to anyone thinking about going to the Cloud is to think very hard about how much you really value the service that you will be getting and what the consequences of downtime or unavailability will be. Once you know that, write the contract, the SLA, etc. so that the service provider puts appropriate value on providing the service to you. If they won't negotiate on the SLA, they're a bunch of cheap-ass cowboys; would you want to entrust something really important to a low-bidder who doesn't care?
Ghosts are not SciFi.
Vampires are not SciFi.
Magic is not SciFi.
Wrestling is not SciFi.
Horror can be SciFi, but not if it includes ghosts and/or magic and/or wrestling.
SciFi is simple - put the story in the future or on another planet or in space. Done.
I've got this idea for a show involving wrestling magical vampire ghosts on Mars with the losers turned into blue cheese. How would you categorize it? (I put the blue cheese in for horror effect; that stuff horrifies me...)
This just ain't so. The notion that everything should be in design and code should be done by interchangeable monkeys doesn't work. It is really popular with people who want a more predictable world, but wishing don't make it so. In the real world, the programming work can be genuinely hard, not because the design is flawed, but because the underlying task requires some amount of coherent thought.
Or rather, if it is true, the program is really already written at the design level and what you've got below that is - or ought to be - mechanical translation. I don't normally worry myself over how my compiler works, after all.
Your assumption that "brilliant" code is badly-written is unsupported. Brilliant code need not be hard to understand; in fact, it's often simple to understand. What's hard is realizing that there's an easy-to-understand way to do something complicated.
Well, depends on whether you're talking about brilliant code or "brilliant" code. The former makes a tough job trivial and clear and can even change how other people think about the original problem, and it will either be well documented or so clear that it doesn't need it. The latter is what the Joshes of the world produce...
Basically, it sounds to me like you've either never seen, or never understood, actual genius-level work. It isn't the same stuff, only faster. While the factor of 160 sounds a bit high, there are certainly plenty of cases of brilliant developers being able to trim days or weeks off of project schedules by finding elegant solutions to problems which looked like they would require a long and painful slog.
The other indicator of real genius-level stuff is that it enables something previously thought impossible or utterly impractical. The first compiler was an example of a genius-level change, no matter how obvious it seems now.
He has no choice but to honor the contract they've made with customers.
Why? The customers don't have a contract with the sysadmin, but rather with the ISP as an organization. Which isn't to say that the sysadmin should not make technical suggestions for how to introduce some sort of "fair-use" policies, but it's not his ass that is personally on the line here and bandwidth-throttling is hardly the sort of grand crime that justifies not doing it.
And in any case, the contracts probably say (or damn well should say!) that customers agree to not use the service in a way that significantly degrades it for others.
Normalise the sizes. Pick points on the images which mark particular features (corner of eye for instance) and then average them to reduce the errors.
Won't help if lots of the images are of the wrong people. That would just make the face look more average overall.
What, you mean I can't make every shmuck that comes in my hospital click on an EULA that says that they can't sue me even if I kill them?
Sure you can! But the courts will ignore it I bet; some types of clause are generally reckoned to be unconscionable and "can't sue me if I kill you" would be a prime candidate for that sort of thing.
The only reason the text of a page doesn't load first today is that web browsers are badly behaved. Firefox will often refuse to render a page until it gets all the content.
Firefox (and, to be fair, all other modern browsers) loads content asynchronously just fine, though with modern networks and HTTP pipelining it's not much of an issue for the textual parts. The real issue is that much javascript is still synchronous and hooked into locations where it hinders all page rendering until it has been loaded and executed in full. Advertisers are particularly bad this way, but are not the only villains.
There were Gopher clients that didn't need external viewers for images [...] Adding HTML to Gopher would have solved a lot of Gopher's problems, but the real problem was that the Gopher protocol wasn't very flexible.
The first time I encountered Mosaic was with HTTP/HTML, but the performance even for content within the same institution was terrible; trying to view the help pages (online at NCSA) was a recipe for effectively hanging the client. When I started actually using Mosaic, it was as a more-usable Gopher client. It sucked so much less than xgopher. Then one of the other students figured out how to make the university gopher server provide pages that were interpreted as HTML by hacking the title by which the page was stored so it appeared to end with ".html"; the lower overhead of the Gopher protocol really helped on the slow networks of that time. (Once you've got delivery of HTML, you can ignore Gopher's crappy hierarchical model.)
It wasn't long after that before networking upgrades meant that we could use HTTP practically; the modern world had arrived. Since then, the big changes have been Netscape (asynch loading of content) and Google (a reasonable chance at finding something useful) - nothing else compares with those two, though pipelining perhaps comes closest - but they are as nothing when stood next to going from hierarchic data to webs of hypertext.
Quoting T'so:
The issue with Ted's comment is... sqlite3 does just that; I grepped the source, and it's certainly using fdatasync(). If it's getting anything wrong, that's a bug report that should be filed.
If you want a masterclass in just how nasty data integrity can get, read the file in sqlite3 that implements these things (for unix). I'm not sure if the parts dealing with synchronization are as scary as the portions on file locking...
What exactly does Godel's theorem have to do with what you just said? The incompleteness theorem deals with axiomatized systems. This leads me to think that you might be confusing the popular meaning of "language" with the mathematical definition. People (at least normal people) do not communicate with mathematical languages.
If you have an unambiguous system, that means it must be possible to give an exact translation from it into mathematics. After all, that's what mathematical notation really is, a way of unambiguously saying things.
But wait! Goedel says that there are no interesting complete mathematical systems (yeah, I do know what axiomatization is, thankyouverymuch). From that we can then deduce that the language that is being translated from must either be able to describe paradoxical entities whose interpretation/valuation must be necessarily ambiguous (that's what Goedel actually did, it's the heart of his proof) or that the originating language is unutterably trivial - that it can't even talk about simple arithmetic for example, let alone actual complex concepts.
The heart of my real argument though was that most people prefer ambiguity. If someone writes "my love is like a red, red rose", it shouldn't have to include a frequency profile of the reflected light off the rose or a precise description of the variety. (More seriously, many poets explicitly want the ambiguity; the reader is supposed to have to work to extract the correct meaning(s) of the poem.)
I don't think this can be examined without language issues. Lojban attempts to make a parsable constructed language (currently undergoing a few grammar issues, but mostly locked down). As we get closer to the Singularity, with regards to infant-style general AI and perhaps even transhuman implants (thought detector or such), we'll see perhaps a myriad of unambiguous languages.
Any language that is truly unambiguous is uninteresting. Firstly, you've got Goedel incompleteness to worry about (which stems from statements that are fundamentally ambiguous as to their interpretation, such as "this statement is false"). Secondly, languages are there for people to communicate with, and people seem to prefer ambiguity. Ask a poet if you need proof of that.
You forgot another big reason for a company to disappear instead of shrink: Governmental involvement.
That's almost always a result of bad management though, and bad management will make the results of governmental involvement worse. If the management is rubbish, the company is in trouble.