If the data is valuable enough to steal a computer and try to hack the TPM chip using acid and needles, then it's valuable enough to threaten the person with the password to divulge it.
Do you think China would be willing to steal a laptop with US state secrets on it? Definitely. Would they be willing to kidnap and torture the military officer or NSA employee who knows the password? Not a chance – that's an act of war.
(And no one but a foreign government would put this much effort into retrieving data from a computer. Anything short of state secrets is not worth the effort.)
For instance, SSDs aren't so hot at random writes, sadly. Less than 0.1 msec write time would be neat for an ACID database.
Cheap SSDs aren't. There are now SSDs by Intel and OCZ that can do tens of megabytes per second of random writes. They just cost several times as much per gigabyte as any other disk out there.
IE8 is sure not slow for most web browsing. I messed with it recently before deciding to go back to Firefox and it displays normal web pages noticeably faster. In either case we are talking like a second or less, but still. Most websites out there, IE8 was enough of an improvement I noted it.
Now obviously that wasn't enough for me to switch, but you are right that the "Oh it is so slow!" crap is disingenuous. IE8 doesn't have support for the new standards, but what it does support it seems to be pretty zippy with.
Tip: compare a fresh IE8 profile to a fresh Firefox profile. If you're comparing pristine IE8 to Firefox with all your history and bookmarks and extensions, then yeah, no kidding Firefox will be slower.
Worth pointing out that HTML5 isn't a standard yet. It's still in draft for the next couple years.
Canvas is at last call at the WHATWG. Look at the little tags at the side: "Last call for comments". This means that the WHATWG (a standards organization) believes that part of the spec is stable and is asking for implementations.
Canvas is also a de facto standard. Gecko, WebKit, and Presto have all implemented it more or less interoperably for an awful long time now: Firefox since 2005, for instance.
You are correct to say that HTML5 is not yet a W3C standard, unless you call Working Drafts "standards". But the W3C is not the only standards body out there.
IE8 actually works pretty damn well for much of the modern web; it's far from the fastest but it's fast enough for most, it is compatible with CSS2 and the other standards most web developers still use, and it has fixed most of the issues that people have cursed at IE over for so long. However, it has very little support for new standards - its CSS3 is still limited, and as far as I know it supports no HTML5 at all.
It supports some HTML5 features, e.g., localStorage. But many fewer than other browsers: multiple competitors already support video, audio, canvas, various new form attributes, and much more.
Then neither are you. Perhaps you should read the HTML5 specs.
Have you actually done that? Because it's well over 600 pages in PDF format. No, I thought not, or else you'd realize that there are key things that HTML5 is still missing. Support for microphone/webcam input, for instance, is a glaringly obvious feature that has yet to be specced, let alone implemented.
Flash and Silverlight won't see the inside of this box because they are both proprietary and HTML 5 can do everything flash or silverlight can do in a standards based way (just ask google voice).
Um, not quite. HTML5 is awesome, yes, but it's not up to Flash's feature levels yet. Not even in the spec, let alone implementations. For example, audio input (along with webcam, etc.) is in the spec labeled as "Idea: yet to be specified". Let alone things that are a little more obscure or less obviously useful. Google Voice ain't going to work in pure HTML5 just yet.
But Apple is big enough to get major sites to make an iPhone app so they work anyway. So, minimal harm to them, lots of harm to Flash, which is great for the web.
Question: as I am not a Linux guy I don't know so maybe someone here can answer: which is more expensive, just buying a Windows 7 Pro license, or getting RHEL for free and paying support for 5 years? Honestly I don't have a clue, all I know is I can usually pick up a Windows pro OEM for usually around $130-150. So which is more expensive?
A direct comparison isn't so straightforward. It depends which versions of Windows/RHEL you pick. For Red Hat, the differentiation is in the support: you can pay $80 per desktop per year with the cheapest level of support, up to well over a thousand dollars per server per year if you go for the most expensive support. But in all cases, you get more or less the full features of the OS. Microsoft differentiates a lot on what software you get: cheap editions have fewer features.
So for a given set of computers, you could easily end up paying more for either Windows or RHEL, as far as I can tell. It depends. You also realistically have to take into account how much it will cost to administer either one, and what your options might be for the future. You're much less locked in with RHEL than with Windows. It's not a simple comparison.
Chrome is open source in the same way that OS X is open source.
Sure they're both based on a open source project (Chromium/Webkit and Darwin/BSD) does not mean they are truly open source. Try to modify and redistribute either and see how long before either of their "parents" get all lawyer-ey.
The analogy Chrome : Chromium:: OS X : Darwin/BSD is nonsense. You can't build an almost identical replica of OS X from open-source code, or anywhere close. Chromium is fully open-source, and it's essentially identical to Chrome. It's what the Chrome developers themselves use for development and testing.
You want to know why *nix operating systems have inherently better architecture? You don't have to be an admin to use your computer, and userspace programs don't have the power to do to my PC what IS2010 did to me last night.
Nonsense. If anyone targeted Linux, they'd be able to exploit the exact same vulnerability in Firefox. They could then change your wallpaper, mess with your programs, and steal all your data. There's little difference between an unprivileged user and root on a single-user machine. But if they wanted root, they could just stick a gksudo (or whatever) workalike somewhere in your PATH and wait for you to give them your password.
The problem is that any code execution exploit means you can do anything as the current user. Complicated programs like Firefox, Flash, Adobe Reader, etc. will have buffer overflows and such, inevitably. User-space programs that process any files need to be heavily sandboxed. Google is leading the way here with Chrome, and Mozilla is following suit sooner or later. Hopefully so will Adobe, or else hopefully Flash will die.
OS architecture is worthless if a bug in any app can let an attacker take control of the system. More defense in depth on the application level, and these exploits will be a lot harder to pull off.
(By the way, "userspace" doesn't mean what you think it means. Root is userspace too.)
GPL is designed to destroy the authors-retain-intellectual-property commercial software model. It is philosophically opposed to intellectual property rights. This is not contestable.
Agreed. The FSF is in favor of some copyright, AFAIK, but very limited compared to what exists today.
One of the ways it tries to acheive this aim is by acting as a land-mine inside of the aforementioned commercial software. I cannot speak for all software companies, but at Microsoft the concern is that someone will see some innocuous code that is freely available for their eyes [as in, they can see it], but that code of course exists under a license that doesn't permit them to use it under plausible terms.
The result is that when GPL software is "accidentally" included in commercial software, the intellectual property is the entire package is destroyed.
"Destroyed" in what sense? Distributing proprietary software mixed with GPL does not and cannot automatically license the proprietary software under the GPL. Such distribution is illegal, but only as regular copyright infringement, and the remedies available are the same as for regular copyright infringement: damages, and injunctions against further distribution.
You can continue to redistribute your proprietary software as soon as you remove the GPL portions of it (e.g., a clean-room rewrite). This is the same as open-source projects have to do if they accidentally include proprietary or incompatibly licensed code, which has happened more than once.
(I'm sure that the FSF would have made it autoconvert your code to GPL if they could have. But copyright licenses can't do that.)
Activision just said they crossed $1,000,000,000 (over one billion) in MW2 revenues. Just saying..
WoW has got to make more than that per year. 12 million subscribers × $13 per subscriber per month × 12 months per year = $1,872,000,000 gross per year, to a first approximation.
i've thought about this before - i think what one needs is a single PRIVATE number - that never gets given out to anyone - and you have a bunch of private ALIAS/Reference numbers which you yourself point to your private number - then you only give out the aliases - and if one of the aliases gets overloaded, you pull the plug on the alias, create a new alias, and then direct that new alias towards your private number.
I do that in Gmail with plus-addressing. For instance, if I get spam from Simetrical+dontsendhere@gmail.com, I can just block all mail from that address. Haven't had it happen yet, though.
That's why people don't use Ubuntu or even Debian for important servers.
Wikipedia uses Ubuntu for all its Linux servers. Hasn't had serious problems yet, and the distro packages are both reasonably stable and up-to-date, which is true of few to no other major distributions.
I guess they didn't consider btrfs ready enough for benchmarking yet.
Aside from btrfs not being ready for production according to anyone, including its developers, it's probably not useful to Google. It has tons of awesome features, but they mostly make administration easier. Google already administers everything through their own user-space cross-computer filesystem, which can handle all their integrity/backup/live upgrade/etc. requirements much better than btrfs probably could. What they want is raw performance, and when btrfs is ready for prime time, it will probably beat ext4 on some benchmarks (especially if you have, e.g., a "file copy" benchmark and let btrfs use COW) but lose on others.
If Google is actually still using ext2 rather than ext3, ext4 will be significantly *more* reliable.
They don't care. I can't remember where I read it, but I read that they were using ext2 since they have no reason to use journaling – if a machine crashes, they just reimage it. GFS ensures that everything is copied to multiple nodes, maybe even in physically disparate locations, so there's no need for recovery (such as via journaling) of individual nodes that have failed. ext2 is just ext3 with journaling disabled.
What Google wants, as the summary suggests, is performance, and ext4 will certainly provide that compared to ext2/3.
Ok, maybe it's true, but it seems much more likely that this was about them conserving CPU, not about you getting your email faster. That would be why it's taken until now for them to take this step.
SSL requires extra round-trips to negotiate keys. If you have significant latency to the nearest Google cluster, that could be a noticeable delay on every HTTP request, since connections aren't recycled. If Gmail switches to Web Sockets or such, of course, that would become a nonissue.
Actually, that is possible. Encrypted data doesn't generally compress as well as plaintext, and it's quite common for web servers to compress data before sending it to the client.
Can you point me to a single HTTPS implementation in wide use that applies SSL before compression? It's the same software doing both, you know. But SSL requires extra round-trips to set up connections, so it is indeed slower.
Google seems to have a policy of talking about new ways to do things, and not making changes suddenly. Afterall, YouTube is the dominant video sharing site right now, and they don't want to let an open source format make them risk their status. So, it looks like HTML5 is going to get a good kick from Google telling them "Hey, we'll use whatever you tell us... but you've got to finish the spec first!" We'll see what this does to that.
Google employs Ian Hickson, the editor of HTML5. He quite literally wrote the entire spec (>1000 pages of complete.html) single-handedly, and personally reads and acts on all feedback. He makes all decisions about the spec unless maybe he's overruled by the HTML Working Group Decision Process, which has happened a grand total of once so far, and that on a purely editorial issue (microdata being a separate spec). Google doesn't need to give anyone "a good kick" when they're the ones writing the spec. They have eight HTMLWG members, too.
(Of course, if Google didn't employ Hixie he'd probably just do the exact same thing but employed by someone else. But they still do employ him.)
There's only one problem. It ain't finished yet. So we've got the same problems 801.11n had a few years ago. It's hard to implement a moving spec.
<video> is interoperably implemented in Firefox, Safari, Chrome, and Opera. The core aspects of the spec are not moving. Details are still being worked out (e.g., recent discussions about autobuffer control), but the spec is definitely implementable.
Standards are good... but we're still in a format war over HMTL5 that makes it nearly impossible to implement it right now.
Nonsense. YouTube can serve H.264 via <video> if supported, and via Flash if not supported. That could be done immediately. If anything is holding them back, it's probably lackluster browser implementations: so far only Firefox 3.6 supports fullscreen, for instance. Spec maturity is not the problem here, and the format problem isn't an issue either (since they'll have to use Flash for fallback anyway for old browsers).
If the EU can fine a US company for what amounted to unfair business practices,
what should the US do to China?
Debt?
What debt?
And then never have a foreign nation lend to us again? Have to pay higher interest rates to American lenders too, uncertain at our lack of scruples? Not a good plan. Besides, this kind of thing leads to retaliation, and everyone loses. We trade an awful lot with China, and it would hurt us noticeably if all that trade went to Europe instead.
Er, "proprietary" as in "open-source under New BSD License"? And "Chrome/ChromeOS" as in "Native Client runs on 32-bit x86 systems that use Windows, Vista, Mac OS X, or Linux. Some ARM and x86-64 support is implemented in the source base, and we hope to make it available for application developers later this year"?
Slashdot Mirror
http://xkcd.com/538/
If the data is valuable enough to steal a computer and try to hack the TPM chip using acid and needles, then it's valuable enough to threaten the person with the password to divulge it.
Do you think China would be willing to steal a laptop with US state secrets on it? Definitely. Would they be willing to kidnap and torture the military officer or NSA employee who knows the password? Not a chance – that's an act of war.
(And no one but a foreign government would put this much effort into retrieving data from a computer. Anything short of state secrets is not worth the effort.)
For instance, SSDs aren't so hot at random writes, sadly. Less than 0.1 msec write time would be neat for an ACID database.
Cheap SSDs aren't. There are now SSDs by Intel and OCZ that can do tens of megabytes per second of random writes. They just cost several times as much per gigabyte as any other disk out there.
To best appreciate the article, type this into your URL bar:
Firefox: javascript:document.body.style.MozTransform="rotate(180deg)";void(0);
Safari/Chrome: javascript:document.body.style.WebkitTransform="rotate(180deg)";void(0);
IE8 is sure not slow for most web browsing. I messed with it recently before deciding to go back to Firefox and it displays normal web pages noticeably faster. In either case we are talking like a second or less, but still. Most websites out there, IE8 was enough of an improvement I noted it.
Now obviously that wasn't enough for me to switch, but you are right that the "Oh it is so slow!" crap is disingenuous. IE8 doesn't have support for the new standards, but what it does support it seems to be pretty zippy with.
Tip: compare a fresh IE8 profile to a fresh Firefox profile. If you're comparing pristine IE8 to Firefox with all your history and bookmarks and extensions, then yeah, no kidding Firefox will be slower.
Worth pointing out that HTML5 isn't a standard yet. It's still in draft for the next couple years.
Canvas is at last call at the WHATWG. Look at the little tags at the side: "Last call for comments". This means that the WHATWG (a standards organization) believes that part of the spec is stable and is asking for implementations.
Canvas is also a de facto standard. Gecko, WebKit, and Presto have all implemented it more or less interoperably for an awful long time now: Firefox since 2005, for instance.
You are correct to say that HTML5 is not yet a W3C standard, unless you call Working Drafts "standards". But the W3C is not the only standards body out there.
Firefox 3.0 doesn't support HTML5 either, but they've included that in the test, and it performs a lot better than IE8.
Firefox has supported <canvas> since 1.5, so it was perfectly fair to include 3.0.
IE8 actually works pretty damn well for much of the modern web; it's far from the fastest but it's fast enough for most, it is compatible with CSS2 and the other standards most web developers still use, and it has fixed most of the issues that people have cursed at IE over for so long. However, it has very little support for new standards - its CSS3 is still limited, and as far as I know it supports no HTML5 at all.
It supports some HTML5 features, e.g., localStorage. But many fewer than other browsers: multiple competitors already support video, audio, canvas, various new form attributes, and much more.
Then neither are you. Perhaps you should read the HTML5 specs.
Have you actually done that? Because it's well over 600 pages in PDF format. No, I thought not, or else you'd realize that there are key things that HTML5 is still missing. Support for microphone/webcam input, for instance, is a glaringly obvious feature that has yet to be specced, let alone implemented.
Flash and Silverlight won't see the inside of this box because they are both proprietary and HTML 5 can do everything flash or silverlight can do in a standards based way (just ask google voice).
Um, not quite. HTML5 is awesome, yes, but it's not up to Flash's feature levels yet. Not even in the spec, let alone implementations. For example, audio input (along with webcam, etc.) is in the spec labeled as "Idea: yet to be specified". Let alone things that are a little more obscure or less obviously useful. Google Voice ain't going to work in pure HTML5 just yet.
But Apple is big enough to get major sites to make an iPhone app so they work anyway. So, minimal harm to them, lots of harm to Flash, which is great for the web.
Question: as I am not a Linux guy I don't know so maybe someone here can answer: which is more expensive, just buying a Windows 7 Pro license, or getting RHEL for free and paying support for 5 years? Honestly I don't have a clue, all I know is I can usually pick up a Windows pro OEM for usually around $130-150. So which is more expensive?
A direct comparison isn't so straightforward. It depends which versions of Windows/RHEL you pick. For Red Hat, the differentiation is in the support: you can pay $80 per desktop per year with the cheapest level of support, up to well over a thousand dollars per server per year if you go for the most expensive support. But in all cases, you get more or less the full features of the OS. Microsoft differentiates a lot on what software you get: cheap editions have fewer features.
So for a given set of computers, you could easily end up paying more for either Windows or RHEL, as far as I can tell. It depends. You also realistically have to take into account how much it will cost to administer either one, and what your options might be for the future. You're much less locked in with RHEL than with Windows. It's not a simple comparison.
Chrome is open source in the same way that OS X is open source.
Sure they're both based on a open source project (Chromium/Webkit and Darwin/BSD) does not mean they are truly open source. Try to modify and redistribute either and see how long before either of their "parents" get all lawyer-ey.
The analogy Chrome : Chromium :: OS X : Darwin/BSD is nonsense. You can't build an almost identical replica of OS X from open-source code, or anywhere close. Chromium is fully open-source, and it's essentially identical to Chrome. It's what the Chrome developers themselves use for development and testing.
You want to know why *nix operating systems have inherently better architecture? You don't have to be an admin to use your computer, and userspace programs don't have the power to do to my PC what IS2010 did to me last night.
Nonsense. If anyone targeted Linux, they'd be able to exploit the exact same vulnerability in Firefox. They could then change your wallpaper, mess with your programs, and steal all your data. There's little difference between an unprivileged user and root on a single-user machine. But if they wanted root, they could just stick a gksudo (or whatever) workalike somewhere in your PATH and wait for you to give them your password.
The problem is that any code execution exploit means you can do anything as the current user. Complicated programs like Firefox, Flash, Adobe Reader, etc. will have buffer overflows and such, inevitably. User-space programs that process any files need to be heavily sandboxed. Google is leading the way here with Chrome, and Mozilla is following suit sooner or later. Hopefully so will Adobe, or else hopefully Flash will die.
OS architecture is worthless if a bug in any app can let an attacker take control of the system. More defense in depth on the application level, and these exploits will be a lot harder to pull off.
(By the way, "userspace" doesn't mean what you think it means. Root is userspace too.)
Seriously, I suggest you have nothing to do with such idiots on the off chance that it is contagious.
Unfortunately, it's hard to make much money as a hermit.
GPL is designed to destroy the authors-retain-intellectual-property commercial software model. It is philosophically opposed to intellectual property rights. This is not contestable.
Agreed. The FSF is in favor of some copyright, AFAIK, but very limited compared to what exists today.
One of the ways it tries to acheive this aim is by acting as a land-mine inside of the aforementioned commercial software. I cannot speak for all software companies, but at Microsoft the concern is that someone will see some innocuous code that is freely available for their eyes [as in, they can see it], but that code of course exists under a license that doesn't permit them to use it under plausible terms.
The result is that when GPL software is "accidentally" included in commercial software, the intellectual property is the entire package is destroyed.
"Destroyed" in what sense? Distributing proprietary software mixed with GPL does not and cannot automatically license the proprietary software under the GPL. Such distribution is illegal, but only as regular copyright infringement, and the remedies available are the same as for regular copyright infringement: damages, and injunctions against further distribution.
You can continue to redistribute your proprietary software as soon as you remove the GPL portions of it (e.g., a clean-room rewrite). This is the same as open-source projects have to do if they accidentally include proprietary or incompatibly licensed code, which has happened more than once.
(I'm sure that the FSF would have made it autoconvert your code to GPL if they could have. But copyright licenses can't do that.)
Activision just said they crossed $1,000,000,000 (over one billion) in MW2 revenues. Just saying..
WoW has got to make more than that per year. 12 million subscribers × $13 per subscriber per month × 12 months per year = $1,872,000,000 gross per year, to a first approximation.
i've thought about this before - i think what one needs is a single PRIVATE number - that never gets given out to anyone - and you have a bunch of private ALIAS/Reference numbers which you yourself point to your private number - then you only give out the aliases - and if one of the aliases gets overloaded, you pull the plug on the alias, create a new alias, and then direct that new alias towards your private number.
I do that in Gmail with plus-addressing. For instance, if I get spam from Simetrical+dontsendhere@gmail.com, I can just block all mail from that address. Haven't had it happen yet, though.
That's why people don't use Ubuntu or even Debian for important servers.
Wikipedia uses Ubuntu for all its Linux servers. Hasn't had serious problems yet, and the distro packages are both reasonably stable and up-to-date, which is true of few to no other major distributions.
I guess they didn't consider btrfs ready enough for benchmarking yet.
Aside from btrfs not being ready for production according to anyone, including its developers, it's probably not useful to Google. It has tons of awesome features, but they mostly make administration easier. Google already administers everything through their own user-space cross-computer filesystem, which can handle all their integrity/backup/live upgrade/etc. requirements much better than btrfs probably could. What they want is raw performance, and when btrfs is ready for prime time, it will probably beat ext4 on some benchmarks (especially if you have, e.g., a "file copy" benchmark and let btrfs use COW) but lose on others.
If Google is actually still using ext2 rather than ext3, ext4 will be significantly *more* reliable.
They don't care. I can't remember where I read it, but I read that they were using ext2 since they have no reason to use journaling – if a machine crashes, they just reimage it. GFS ensures that everything is copied to multiple nodes, maybe even in physically disparate locations, so there's no need for recovery (such as via journaling) of individual nodes that have failed. ext2 is just ext3 with journaling disabled.
What Google wants, as the summary suggests, is performance, and ext4 will certainly provide that compared to ext2/3.
Bullshit.
Ok, maybe it's true, but it seems much more likely that this was about them conserving CPU, not about you getting your email faster. That would be why it's taken until now for them to take this step.
SSL requires extra round-trips to negotiate keys. If you have significant latency to the nearest Google cluster, that could be a noticeable delay on every HTTP request, since connections aren't recycled. If Gmail switches to Web Sockets or such, of course, that would become a nonissue.
Actually, that is possible. Encrypted data doesn't generally compress as well as plaintext, and it's quite common for web servers to compress data before sending it to the client.
Can you point me to a single HTTPS implementation in wide use that applies SSL before compression? It's the same software doing both, you know. But SSL requires extra round-trips to set up connections, so it is indeed slower.
Google seems to have a policy of talking about new ways to do things, and not making changes suddenly. Afterall, YouTube is the dominant video sharing site right now, and they don't want to let an open source format make them risk their status. So, it looks like HTML5 is going to get a good kick from Google telling them "Hey, we'll use whatever you tell us... but you've got to finish the spec first!" We'll see what this does to that.
Google employs Ian Hickson, the editor of HTML5. He quite literally wrote the entire spec (>1000 pages of complete.html) single-handedly, and personally reads and acts on all feedback. He makes all decisions about the spec unless maybe he's overruled by the HTML Working Group Decision Process, which has happened a grand total of once so far, and that on a purely editorial issue (microdata being a separate spec). Google doesn't need to give anyone "a good kick" when they're the ones writing the spec. They have eight HTMLWG members, too.
(Of course, if Google didn't employ Hixie he'd probably just do the exact same thing but employed by someone else. But they still do employ him.)
There's only one problem. It ain't finished yet. So we've got the same problems 801.11n had a few years ago. It's hard to implement a moving spec.
<video> is interoperably implemented in Firefox, Safari, Chrome, and Opera. The core aspects of the spec are not moving. Details are still being worked out (e.g., recent discussions about autobuffer control), but the spec is definitely implementable.
Standards are good... but we're still in a format war over HMTL5 that makes it nearly impossible to implement it right now.
Nonsense. YouTube can serve H.264 via <video> if supported, and via Flash if not supported. That could be done immediately. If anything is holding them back, it's probably lackluster browser implementations: so far only Firefox 3.6 supports fullscreen, for instance. Spec maturity is not the problem here, and the format problem isn't an issue either (since they'll have to use Flash for fallback anyway for old browsers).
If the EU can fine a US company for what amounted to unfair business practices, what should the US do to China? Debt? What debt?
And then never have a foreign nation lend to us again? Have to pay higher interest rates to American lenders too, uncertain at our lack of scruples? Not a good plan. Besides, this kind of thing leads to retaliation, and everyone loses. We trade an awful lot with China, and it would hurt us noticeably if all that trade went to Europe instead.
Google would be over there adding proprietary features to Chrome/ChromeOS.
Er, "proprietary" as in "open-source under New BSD License"? And "Chrome/ChromeOS" as in "Native Client runs on 32-bit x86 systems that use Windows, Vista, Mac OS X, or Linux. Some ARM and x86-64 support is implemented in the source base, and we hope to make it available for application developers later this year"?