I find it amusing that everyone rails against IE (rightfully so in many ways) for not following standards, but every web developer I know (and being one in a lively local web development community, I am exposed to a fair number) still has to check sites in IE plus a multitude of other browsers. When there are differences between standards compliant browsers, theres something wrong with the standard imho.
It's not necessarily a problem with the standard, it's a problem of specifications generally. Writing a specification that covers everything is very hard, and writing code to match a specification exactly is also very hard. You can realistically only get approximations. The same thing occurs with other standards. Look at how many differences you have between C compilers, Unixes, or (God help us) SQL databases – sometimes even when the standard is very clear.
What's wrong with W3C standards is that there's never been a reference implementation, which means there's a lot of room for interpretation, and interpretations can vary a lot. And after they've been implemented, people start discussing which implementations are closest to what the standard intended, after which people need to fix their browser, and in the mean time, we've got a big bloody mess.
Reference implementations are important.
The W3C publishes standards too rapidly for a reference implementation to be feasible, unless you just arbitrarily pick a major browser and declare it such. The work to maintain a reasonable reference implementation is probably beyond the W3C's budget.
In practice, if uncertainty arises, a browser developer can just ask on the relevant mailing list and an official conclusion can usually be reached in a week or less. So I don't think a reference implementation is really necessary here. Detailed behavior descriptions, extensive test cases, and a quick way to resolve uncertainty suffice.
I can assure you that they do not act this way out of sympathy for IE. They do so because they know that the user base not using IE/Firefox/Safari is too small to care for.
Chrome now has larger market share than Safari according to four out of the five reports here. And the one exception is drastically different from the other four on all counts, while the other four largely agree with each other, so I'd neglect it. Of course, individual sites will differ, but still.
With all the idiots fighting over the usual crap no one mentioned that it doesn't seem to support the canvas element. Microsoft has specifically tried to get the canvas element removed from the HTML5 spec. (as per here). And I know why Microsoft doesn't want the canvas element in there: because it's a direct threat to Silverlight.
The canvas API is no longer in the HTML5 spec anyway. The editor, Ian Hickson, has been in favor of a single monolithic specification, but other HTMLWG members have argued for various parts to be broken out into separate specs for a long time. In January, the HTMLWG overruled the editor and decided to split microdata into a separate spec. At the same time, in anticipation of further WG decisions in the same vein, the editor split the canvas 2D API into a separate spec too, which recently became a Working Draft.
This doesn't actually change the status of the canvas element: it's still part of a W3C Working Draft. They can implement it or not, just as much as if it was in the main HTML5 spec. Personally, I'm guessing they'll most likely implement it in a later IE9 release, but time will tell.
Meaning Microsoft controls the kinds of video IE can stream?
This is a big opportunity for Microsoft to force the Internet media standards AND generate some meaningful license fees. Those fees would be paid to Microsoft to enable streaming your hot-new-VC-backed media format. Microsoft would never have to deal with those pesky media streaming competitors they used to call partners.
If I made decisions at Microsoft, that's how I'd do it.
Let me rephrase then.
What is the better default behavior given that there is an option to alter said behavior if you don't like it?
The default behavior attempts to keep Firefox as up to date as possible. It also tries to recover from the browser crashing or some other misfortune. If I need to go in a hurry, I can close the browser and it will reopen where I left off.
The better default behavior is to open immediately and do update checking in the background. Once the update is downloaded and installed, then you can tell the user to restart. The current behavior is absolutely infuriating if you're trying to get something done.
Chrome doesn't even open a modal dialog if it crashed last session. It just pops up a notification at the top of the screen asking if you want to restore your tabs, which is easily visible if you're looking around for your lost tabs, but easily ignored if you're doing something else (in which case it will eventually vanish).
IE has been sandboxing browser engine (including JS) to run in reduced elevation mode (so that it doesn't even have the privileges of user who runs the browser - so it can't access the files of that user, for example) since IE7/Vista.
More precisely, it runs in "Low Integrity Mode". This means that it can't write to files or directories with Medium or High integrity, and any file it creates is marked as low-integrity as well (so if creates a program, that will run with low integrity if it gets executed). But it can still take other actions with the privileges of the current user. It prevents IE from installing programs or corrupting data if compromised, but not snooping around and sending back data, or participating in DDoS, etc.
This is enough to prevent typical serious attacks, to be fair. But Chrome's sandbox is much tighter.
H.264 is patented outside the US. Including most of Europe, for instance – that post lists 20 European countries. And Canada, Australia, Japan, India . . .
You don't get it. If Firefox had h.264 support, it could not be redistributed. Period. Everyone would have to download the 'offical' version from Mozilla. No Linux distro could include it. No one could change the code and distribute it. It would cripple Firefox. Why the hell doesn't anyone understand this?
That's not true. All of Mozilla is licensed under the LGPL or a more permissive license, so it can be linked to patent-encumbered (or, indeed, completely proprietary) code. At most, they might have to license the actual H.264 implementation under some non-GPL-based license, to avoid anti-patent clauses of some kind, but Google's lawyers don't see this as a problem with their use of ffmpeg under the LGPL, so I doubt it.
Linux distributions already ship H.264 codecs, so saying they wouldn't ship Firefox if it supported H.264 is unreasonable. Chromium supports H.264 if you compile it to do so, but I haven't heard of any distro saying they won't ship it for that reason. Indeed, fta's PPA package of Chromium already supports H.264 if you install ffmpeg with non-free codecs.
In short: you're wrong. Mozilla is acting on purely ideological grounds, not practical ones. Correctly so, in my opinion, although they'll probably lose in the end. This is not the first time they've taken a principled stance on what features to support, and nor should it be the last. Browser implementers should be moving the web forward in the long term, not just acting in their users' immediate self-interest.
This is actually one of the examples from TFA. The contention is that the statistics show that a majority of the certificate errors that users run across are false positives
You're grossly understating their conclusion (emphasis added):
Ironically, one place a user will almost certainly never see a certificate error is on a phishing or malware hosting site. That is, using certificates is almost unknown among the reported phishing sites in PhishTank [7]. The rare cases that employ certificates use valid ones. The same is true of sites that host malicious content. Attackers wisely calculate that it is far better to go without a certificate than risk the warning. In fact, as far as we can determine, there is no evidence of a single user being saved from harm by a certificate error, anywhere, ever.
Repeated for people who skimmed the quote: "In fact, as far as we can determine, there is no evidence of a single user being saved from harm by a certificate error, anywhere, ever."
Let the OS handle it, and let the browser interact via plug-ins.
It's really not that complicated.
It's not that simple. HTML5 video is first-class HTML content. It has to interact with CSS and JS, including potentially things like rotations, other things overlapping it, resizing, etc., and all of these things changing at any time due to script. Who says the OS is going to expose an API complicated enough to support all of HTML's features?
In fact, notice that every browser that supports >video> uses a library entirely under their control. Firefox uses libtheora and is contemplating GStreamer (at least for mobile); Chrome uses ffmpeg; Safari uses QuickTime; Opera uses GStreamer. In every case, it's either open-source, or developed by the same company. No one is relying on OS support except arguably Apple, and that only on Mac, which they control. Because OS support isn't good enough.
Disclaimer: I'm not a browser developer, but I do hang out around them a lot.:)
JPEG images are patent encumbered too. There's just a gentleman's agreement among group members not to pursue royalties for "baseline" implementations of the standard. I don't see anyone scrambling to remove them from Wikipedia.
JPEG has no known patents on it, according to Wikipedia. A couple of companies have asserted patent rights on JPEG, but it's not at all clear that the patents are actually valid: some have already been overturned by the Patent Office, and others are undergoing review.
How much of the useful content of Wikipedia is going to end up trapped inside videos when easily indexed and searched, entirely unencumbered US Grade-A ASCII^h^h^h^h^hUTF-8 would have been sufficient?
None. Videos will supplement the textual content of Wikipedia, not supplant it. They can already be found in some articles floated to the side, like images often are. Also, Wikimedia Commons is happy to host educational material that's not useful to Wikipedia.
Well - maybe it's not a direct equivalent, but yes, HTML5 has the potential to keep such persistent cookies, as large as or larger than flash now uses.
Read the actual spec. It has an entire section on privacy. One quote:
If users attempt to protect their privacy by clearing cookies without also clearing data stored in the local storage area, sites can defeat those attempts by using the two features as redundant backup for each other. User agents should present the interfaces for clearing these in a way that helps users to understand this possibility and enables them to delete data in all persistent storage features simultaneously.
Both the article and the summary mixes up the concepts. Randomness and bias are related but different things. Think of a biased coin loaded in favor of heads - the heads may appear twice as often as the tails, but the distribution is still random. Here too, contrary to the summary's claim of "far from random", the results are random, just biased
Could people please realize that there are multiple valid definitions of random out there? It's very clear from context that the relevant definition here is "uniformly distributed, unpredictable", not "obeying a probability distribution".
We'll never run out of plastic. Don't forget that "oil" came from biological sources. It'll be more expensive than just pumping the stuff out of the ground, but as long as there is life on Earth we'll be able to produce all the polymers we need.
We can also always create gold by nuclear fusion if there's no more to mine. That doesn't mean we'll never run out of gold in a practical sense.
Can you give specific examples of where IE8 sucks at implementing the final (non-draft) W3C standards, such as HTML 4.01 and CSS 2.1?
Why shouldn't they implement draft standards? You do realize that to get to Proposed Recommendation status, at least one implementation is required? W3C drafts are not meant to remain unimplemented until they reach Candidate Recommendation stage.
By the way, CSS 2.1 is a Candidate Recommendation, so it's not final. And it only even reached that level in September 2009, less than six months ago. Focusing on "final" specs makes no sense – large W3C specs can take a decade to get from first Working Draft to Recommendation. E.g., CSS3 Selectors was a Working Draft in April 2000, and hasn't yet reached Recommendation. Ian Hickson, editor of HTML5, estimates that it will reach Recommendation in 2022 (it was started in 2004). Waiting for REC before implementing would be crazy.
For that matter IE8 sucks too. I wish Microsoft would just get it together and use webkit or gecko as their rendering engine. They could keep the familiar IE interface and whatever extras they wanted without forcing this load of crap on all us poor developers that just want standards support.
IE8's CSS2.1 support is excellent, on par with any other browser. Its major problem is that it doesn't implement many of the standards that all other browsers do these days, like CSS3 Selectors, SVG, or certain parts of HTML5 (like <canvas>). But it's livable.
The awful thing about IE6 and IE7 is how they implement CSS incorrectly in a big way, so you have to figure out their crazy version of CSS and serve separate stylesheets. (There are probably JS problems too, but I don't do much JS, so I dunno.) IE8 isn't a big problem, you just can't use some features in it.
Horses for courses. If you want reproducible, you don't want true random. If you want security, you do.
For security, it depends. Cryptography requires some truly random numbers, typically, but pseudo-random number generators are often used as well. For example, you can construct a stream cipher from a pseudo-random number generator by using the pseudorandom stream as an infinite-length one-time pad, with both parties using the same (secret) seed. If the pseudorandom number generator is secure, the resulting stream cipher is provably secure as well (for some definitions of secure). This doesn't work if the stream is truly random.
No, true random means the outcome cannot be predicted with certainty. What you're describing is one particular type of randomness known as the "uniform distribution". Gaussian or binomial random variables, for example, don't have equal likelihood for the outcomes but are still truly random.
In the sense of "random variable", yes. In the sense of "pseudo-random number generator", no. The relevant meaning of random here is "unpredictable": given the first n bits of a string, you should only have a 50/50 chance of guessing the next. This isn't the case if you're sampling the bits from a binomial or Gaussian distribution, only from a uniform distribution (or some approximation thereto).
Linux uses available memory for cache, and rather aggressively. All available memory can be filled with cached file blocks. This happens routinely on systems which have big randomly-accessed files open, like databases.
Actually, databases will typically maintain their own cache, bypassing the OS page cache. A notable exception is MyISAM, the default storage engine for MySQL: that uses the OS page cache for data (although maintains its own cache for keys).
In practice, my Linux machines always have all memory filled within an hour or two. You just have to read or write a gigabyte or two of non-temporary files.
The problem with giving to Wikimedia is that they have been so wasteful of the money they've been given. The move to the Bay Area is chief exhibit #1 - why move an organization whose whole purpose, mission, and asset is a web page to one of the most expensive real estate locations on earth?
Maybe because it's a lot easier to find software developers in the Bay Area? Their previous location was Florida – better known for its retirees than its programming industry. Even though Wikimedia runs a website, and many people work remotely, they still do have quite a few people working from their office.
Accelerating to 99.999998% of light speed in 3.5 hours would be a somewhat dizzying experience. Especially since you'd actually experience an acceleration equivalent to going to 5000 times light speed in a pure Newtonian universe. We're talking more than 500.000km/s^2 here -- or 50 million g.
It wouldn't be dizzying if you could apply the appropriate force uniformly across all the particles in your body. If you were in a uniform gravitational field of 50 million g, you wouldn't even notice. At least, not as far as I can figure. We don't notice the force of gravity on Earth, we notice the normal force of the ground pushing up against our feet – if you jump down a long shaft in a vacuum, you'll feel weightless as you fall.
Of course, we don't know of any way even in principle to create such a uniform force field other than actual gravity. But this is science fiction right now anyway, right?
Slashdot Mirror
I find it amusing that everyone rails against IE (rightfully so in many ways) for not following standards, but every web developer I know (and being one in a lively local web development community, I am exposed to a fair number) still has to check sites in IE plus a multitude of other browsers . When there are differences between standards compliant browsers, theres something wrong with the standard imho.
It's not necessarily a problem with the standard, it's a problem of specifications generally. Writing a specification that covers everything is very hard, and writing code to match a specification exactly is also very hard. You can realistically only get approximations. The same thing occurs with other standards. Look at how many differences you have between C compilers, Unixes, or (God help us) SQL databases – sometimes even when the standard is very clear.
What's wrong with W3C standards is that there's never been a reference implementation, which means there's a lot of room for interpretation, and interpretations can vary a lot. And after they've been implemented, people start discussing which implementations are closest to what the standard intended, after which people need to fix their browser, and in the mean time, we've got a big bloody mess.
Reference implementations are important.
The W3C publishes standards too rapidly for a reference implementation to be feasible, unless you just arbitrarily pick a major browser and declare it such. The work to maintain a reasonable reference implementation is probably beyond the W3C's budget.
In practice, if uncertainty arises, a browser developer can just ask on the relevant mailing list and an official conclusion can usually be reached in a week or less. So I don't think a reference implementation is really necessary here. Detailed behavior descriptions, extensive test cases, and a quick way to resolve uncertainty suffice.
I can assure you that they do not act this way out of sympathy for IE. They do so because they know that the user base not using IE/Firefox/Safari is too small to care for.
Chrome now has larger market share than Safari according to four out of the five reports here. And the one exception is drastically different from the other four on all counts, while the other four largely agree with each other, so I'd neglect it. Of course, individual sites will differ, but still.
With all the idiots fighting over the usual crap no one mentioned that it doesn't seem to support the canvas element. Microsoft has specifically tried to get the canvas element removed from the HTML5 spec. (as per here). And I know why Microsoft doesn't want the canvas element in there: because it's a direct threat to Silverlight.
The canvas API is no longer in the HTML5 spec anyway. The editor, Ian Hickson, has been in favor of a single monolithic specification, but other HTMLWG members have argued for various parts to be broken out into separate specs for a long time. In January, the HTMLWG overruled the editor and decided to split microdata into a separate spec. At the same time, in anticipation of further WG decisions in the same vein, the editor split the canvas 2D API into a separate spec too, which recently became a Working Draft.
This doesn't actually change the status of the canvas element: it's still part of a W3C Working Draft. They can implement it or not, just as much as if it was in the main HTML5 spec. Personally, I'm guessing they'll most likely implement it in a later IE9 release, but time will tell.
Meaning Microsoft controls the kinds of video IE can stream?
This is a big opportunity for Microsoft to force the Internet media standards AND generate some meaningful license fees. Those fees would be paid to Microsoft to enable streaming your hot-new-VC-backed media format. Microsoft would never have to deal with those pesky media streaming competitors they used to call partners.
If I made decisions at Microsoft, that's how I'd do it.
IE9 is supporting "MP4 h.264 video, MP3 or AAC audio - just like Safari, Chrome." Not Theora, of course, but H.264, not some Microsoft-only thing.
Let me rephrase then. What is the better default behavior given that there is an option to alter said behavior if you don't like it?
The default behavior attempts to keep Firefox as up to date as possible. It also tries to recover from the browser crashing or some other misfortune. If I need to go in a hurry, I can close the browser and it will reopen where I left off.
The better default behavior is to open immediately and do update checking in the background. Once the update is downloaded and installed, then you can tell the user to restart. The current behavior is absolutely infuriating if you're trying to get something done.
Chrome doesn't even open a modal dialog if it crashed last session. It just pops up a notification at the top of the screen asking if you want to restore your tabs, which is easily visible if you're looking around for your lost tabs, but easily ignored if you're doing something else (in which case it will eventually vanish).
IE has been sandboxing browser engine (including JS) to run in reduced elevation mode (so that it doesn't even have the privileges of user who runs the browser - so it can't access the files of that user, for example) since IE7/Vista.
More precisely, it runs in "Low Integrity Mode". This means that it can't write to files or directories with Medium or High integrity, and any file it creates is marked as low-integrity as well (so if creates a program, that will run with low integrity if it gets executed). But it can still take other actions with the privileges of the current user. It prevents IE from installing programs or corrupting data if compromised, but not snooping around and sending back data, or participating in DDoS, etc.
This is enough to prevent typical serious attacks, to be fair. But Chrome's sandbox is much tighter.
Oh, how so? Outside US, that is?
H.264 is patented outside the US. Including most of Europe, for instance – that post lists 20 European countries. And Canada, Australia, Japan, India . . .
You don't get it. If Firefox had h.264 support, it could not be redistributed. Period. Everyone would have to download the 'offical' version from Mozilla. No Linux distro could include it. No one could change the code and distribute it. It would cripple Firefox. Why the hell doesn't anyone understand this?
That's not true. All of Mozilla is licensed under the LGPL or a more permissive license, so it can be linked to patent-encumbered (or, indeed, completely proprietary) code. At most, they might have to license the actual H.264 implementation under some non-GPL-based license, to avoid anti-patent clauses of some kind, but Google's lawyers don't see this as a problem with their use of ffmpeg under the LGPL, so I doubt it.
Linux distributions already ship H.264 codecs, so saying they wouldn't ship Firefox if it supported H.264 is unreasonable. Chromium supports H.264 if you compile it to do so, but I haven't heard of any distro saying they won't ship it for that reason. Indeed, fta's PPA package of Chromium already supports H.264 if you install ffmpeg with non-free codecs.
In short: you're wrong. Mozilla is acting on purely ideological grounds, not practical ones. Correctly so, in my opinion, although they'll probably lose in the end. This is not the first time they've taken a principled stance on what features to support, and nor should it be the last. Browser implementers should be moving the web forward in the long term, not just acting in their users' immediate self-interest.
This is actually one of the examples from TFA. The contention is that the statistics show that a majority of the certificate errors that users run across are false positives
You're grossly understating their conclusion (emphasis added):
Repeated for people who skimmed the quote: "In fact, as far as we can determine, there is no evidence of a single user being saved from harm by a certificate error, anywhere, ever."
Let the OS handle it, and let the browser interact via plug-ins.
It's really not that complicated.
It's not that simple. HTML5 video is first-class HTML content. It has to interact with CSS and JS, including potentially things like rotations, other things overlapping it, resizing, etc., and all of these things changing at any time due to script. Who says the OS is going to expose an API complicated enough to support all of HTML's features?
In fact, notice that every browser that supports >video> uses a library entirely under their control. Firefox uses libtheora and is contemplating GStreamer (at least for mobile); Chrome uses ffmpeg; Safari uses QuickTime; Opera uses GStreamer. In every case, it's either open-source, or developed by the same company. No one is relying on OS support except arguably Apple, and that only on Mac, which they control. Because OS support isn't good enough.
Disclaimer: I'm not a browser developer, but I do hang out around them a lot. :)
JPEG images are patent encumbered too. There's just a gentleman's agreement among group members not to pursue royalties for "baseline" implementations of the standard. I don't see anyone scrambling to remove them from Wikipedia.
JPEG has no known patents on it, according to Wikipedia. A couple of companies have asserted patent rights on JPEG, but it's not at all clear that the patents are actually valid: some have already been overturned by the Patent Office, and others are undergoing review.
How much of the useful content of Wikipedia is going to end up trapped inside videos when easily indexed and searched, entirely unencumbered US Grade-A ASCII^h^h^h^h^hUTF-8 would have been sufficient?
None. Videos will supplement the textual content of Wikipedia, not supplant it. They can already be found in some articles floated to the side, like images often are. Also, Wikimedia Commons is happy to host educational material that's not useful to Wikipedia.
Well - maybe it's not a direct equivalent, but yes, HTML5 has the potential to keep such persistent cookies, as large as or larger than flash now uses.
http://completosec.wordpress.com/2010/02/07/html-5-persistent-offline-storage-as-a-risk-management-challenge/
Read the actual spec. It has an entire section on privacy. One quote:
Both the article and the summary mixes up the concepts. Randomness and bias are related but different things. Think of a biased coin loaded in favor of heads - the heads may appear twice as often as the tails, but the distribution is still random. Here too, contrary to the summary's claim of "far from random", the results are random, just biased
Could people please realize that there are multiple valid definitions of random out there? It's very clear from context that the relevant definition here is "uniformly distributed, unpredictable", not "obeying a probability distribution".
We'll never run out of plastic. Don't forget that "oil" came from biological sources. It'll be more expensive than just pumping the stuff out of the ground, but as long as there is life on Earth we'll be able to produce all the polymers we need.
We can also always create gold by nuclear fusion if there's no more to mine. That doesn't mean we'll never run out of gold in a practical sense.
Can you give specific examples of where IE8 sucks at implementing the final (non-draft) W3C standards, such as HTML 4.01 and CSS 2.1?
Why shouldn't they implement draft standards? You do realize that to get to Proposed Recommendation status, at least one implementation is required? W3C drafts are not meant to remain unimplemented until they reach Candidate Recommendation stage.
By the way, CSS 2.1 is a Candidate Recommendation, so it's not final. And it only even reached that level in September 2009, less than six months ago. Focusing on "final" specs makes no sense – large W3C specs can take a decade to get from first Working Draft to Recommendation. E.g., CSS3 Selectors was a Working Draft in April 2000, and hasn't yet reached Recommendation. Ian Hickson, editor of HTML5, estimates that it will reach Recommendation in 2022 (it was started in 2004). Waiting for REC before implementing would be crazy.
For that matter IE8 sucks too. I wish Microsoft would just get it together and use webkit or gecko as their rendering engine. They could keep the familiar IE interface and whatever extras they wanted without forcing this load of crap on all us poor developers that just want standards support.
IE8's CSS2.1 support is excellent, on par with any other browser. Its major problem is that it doesn't implement many of the standards that all other browsers do these days, like CSS3 Selectors, SVG, or certain parts of HTML5 (like <canvas>). But it's livable.
The awful thing about IE6 and IE7 is how they implement CSS incorrectly in a big way, so you have to figure out their crazy version of CSS and serve separate stylesheets. (There are probably JS problems too, but I don't do much JS, so I dunno.) IE8 isn't a big problem, you just can't use some features in it.
Horses for courses. If you want reproducible, you don't want true random. If you want security, you do.
For security, it depends. Cryptography requires some truly random numbers, typically, but pseudo-random number generators are often used as well. For example, you can construct a stream cipher from a pseudo-random number generator by using the pseudorandom stream as an infinite-length one-time pad, with both parties using the same (secret) seed. If the pseudorandom number generator is secure, the resulting stream cipher is provably secure as well (for some definitions of secure). This doesn't work if the stream is truly random.
No, true random means the outcome cannot be predicted with certainty. What you're describing is one particular type of randomness known as the "uniform distribution". Gaussian or binomial random variables, for example, don't have equal likelihood for the outcomes but are still truly random.
In the sense of "random variable", yes. In the sense of "pseudo-random number generator", no. The relevant meaning of random here is "unpredictable": given the first n bits of a string, you should only have a 50/50 chance of guessing the next. This isn't the case if you're sampling the bits from a binomial or Gaussian distribution, only from a uniform distribution (or some approximation thereto).
Linux uses available memory for cache, and rather aggressively. All available memory can be filled with cached file blocks. This happens routinely on systems which have big randomly-accessed files open, like databases.
Actually, databases will typically maintain their own cache, bypassing the OS page cache. A notable exception is MyISAM, the default storage engine for MySQL: that uses the OS page cache for data (although maintains its own cache for keys).
In practice, my Linux machines always have all memory filled within an hour or two. You just have to read or write a gigabyte or two of non-temporary files.
The problem with giving to Wikimedia is that they have been so wasteful of the money they've been given. The move to the Bay Area is chief exhibit #1 - why move an organization whose whole purpose, mission, and asset is a web page to one of the most expensive real estate locations on earth?
Maybe because it's a lot easier to find software developers in the Bay Area? Their previous location was Florida – better known for its retirees than its programming industry. Even though Wikimedia runs a website, and many people work remotely, they still do have quite a few people working from their office.
Accelerating to 99.999998% of light speed in 3.5 hours would be a somewhat dizzying experience. Especially since you'd actually experience an acceleration equivalent to going to 5000 times light speed in a pure Newtonian universe. We're talking more than 500.000km/s^2 here -- or 50 million g.
It wouldn't be dizzying if you could apply the appropriate force uniformly across all the particles in your body. If you were in a uniform gravitational field of 50 million g, you wouldn't even notice. At least, not as far as I can figure. We don't notice the force of gravity on Earth, we notice the normal force of the ground pushing up against our feet – if you jump down a long shaft in a vacuum, you'll feel weightless as you fall.
Of course, we don't know of any way even in principle to create such a uniform force field other than actual gravity. But this is science fiction right now anyway, right?
Does it?
Heck if I know, I was kidding. Go talk to the guy who modded me Insightful.
If you're not going to give him a second chance, why let him out of prison at all?
Costs less. Duh.