The fact that the question submitter didn't provide reasons for keeping Windows does not mean that (s)he doesn't have any.
In fact, the question submitter explicitly identified the reason for keeping Windows for the guest access, "funny looks and confused users" when offering Linux instead.
In other news today, Samsung, have very clearly said NO to this new browser direction of Google's. They're going for a different new projectwith Mozilla.
I don't see how signing on to a long-term, high-risk project to build a new browser from scratch with new technology (something that happened long before Blink was announced) is somehow a rejection of an immediate term divorce of Chromium from the WebKit project.
Google themselves often has long-term, high-risk projects that address the same (or overlapping) concerns as the projects behind their existing products, which clearly isn't a "rejection" of those current projects. Why would it be a "rejection" of the current Google project for a Google partner to do the same kind of thing Google itself often does in parallel with its current projects?
Within the past century, 95% of the purchasing power of the US dollar has been taken away by inflation. Exactly how safe do you think the US dollar is again?
If you are using currency as a long-term store of value, you are mostly using it wrong.
Good thing I'm not doing that then.
If you aren't, then the value decline of the US dollar of the last century is irrelevant to its safety, only the degree of short-term volatility is a safety issue.
And, as recently demonstrated by Cyprus, if the government arbitrarily changes the rules ex post facto and decides they're going to take your money "because we need it," how well do you sleep?
Governments can just as easily arbitrarily change the rules and take away: 1) The computing devices that give me access to Bitcoins, 2) The computing devices that Bitcoin exchanges use, 3) The computing devices that other people accepting Bitcoins use, 4) The bank accounts that Bitcoin exchanges use, 5) The legal environment which allows merchants to feel comfortable accepting Bitcoins in exchange for goods and services, 6) My physical freedom to access any of the things that would allow me to access any Bitcoins I do have, 7+) etc.
So, Bitcoin is hardly immune to arbitrary deprivation by the government.
Its also, demonstrably, subject to additional risks without arbitrary deprivation by the government that conventional bank accounts are not subject to.
That depends on if the US government can confiscate money held in banks like what happened in Cyprus, or not. The question is, do you trust government to honor its promises.
The thing about the unlimited power that comes with soveriegnty is that governments can confiscate computing devices as well as confiscating bank deposits or any other kind of property.
Amen to that. People don't realize the protocol is absolutely, 100% perfectly fraud-proof. It is designed to be impossible to forge a bad block or fake a transaction or gain ownership of coins you don't own. The only way to actually do it is to outprocess the entire rest of the network, which is impossible.
Unless honest participants in the network definitively control more than half of the computing power on the planet, it is at best impractical rather than impossible. Its not "absolutely, 100% perfectly fraud-proof".
Within the past century, 95% of the purchasing power of the US dollar has been taken away by inflation. Exactly how safe do you think the US dollar is again?
If you are using currency as a long-term store of value, you are mostly using it wrong.
I hate to break this to you, but your insured deposits aren't held as coins in an outsized piggy bank like Scrooge McDuck's Money Bin. They exist only as entries in an electronic ledger.
They also exist in the form of various transaction documents and balance statements I can present to a court with jurisdiction over the bank in question as evidence of the existence of the deposits.
Seriously. Who in the name of Tesla uses V8? For real. Nice as an OSS exercise but completely worthless/useless in a real world. H.264 is the de-facto standard. No way around it.
V8 is a JavaScript engine used by Chrome, Node.js, and a number of other things.
You are probably thinking of VP8, which is completely unrelated.
So why didn't Google just use Webkit2's "multiprocess sandboxing" instead of forking the code base and writing their own?
Less importantly, because WebKit2 doesn't work the way Chromium wanted a multiprocess model to work. More importantly, because WebKit2 was an alternative response to Chromium's multiprocess model, so it would have required a time machine for them to do that.
I'm sure Google will take this opportunity to add native bindings for Dart, which will make dart a whole lot more interesting now.
I wouldn't expect that. Google engineers have said that while they have Chromium builds with integrated Dart VM ("Dartium") which are distributed with the Dart SDK, the only purpose they see for that at the present time is improving the edit-test cycle with the SDK, for client-side Dart code, dart2js is preferred because they don't want to create single-browser sites.
I suspect Google will bundle Dart VM with Chrome only if at least one other major browser vendor adopts the VM (and their engineers have said its quite possible that continued JS improvements will make dart2js the preferred client-side method of deploying dart for the forseeable future.)
By which you mean code that hasn't been used by any Apple browser for years. And that was hard for Google to ignore, while it wasn't for Apple?
Google doesn't want to ignore it, they want to fix WebKit's networking code to improve performance on platforms that people actually use, however, doing that while not breaking the legacy bits has produced fragile workarounds that are themselves the source of bugs. Google wants to cut to the heart of the matter, and streamline the whole networking layer rather than continue to work-around the "can't touch this" legacy bits, which they can't do within WebKit given the present constraints imposed by the WebKit project.
Apple, clearly, can ignore it just fine and will no doubt continue ignoring it as Google leaves WebKit.
Given that the whole point of Blink is for Google to remove support for platforms other than their own, this is is either unlikely or impossible.
That's not the point. The point is not to be held back by constraints imposed by commitments of the WebKit project. A short term benefit to the split is removing a lot of code that Chromium doesn't use -- not because it supports different "platforms", but because it supports different WebKit-based browsers with different approaches (e.g., WebKit2's alternative to Chromium's multi-process model, etc.)
The only goal identified in their blog post announcing this was to be able to remove all the code supporting other people's work.
No, removing code not used by Chrome is a short-term benefit cited, not a goal. There are goals and motivations cited in the second paragraph regarding improved pace for implementing improvements. If you click through to the Blink project page, as anyone who wanted more than the orbital overview could be expected to, the details of the planned architectural changes (including discussion of what held those changes back while Chrome was tied to WebKit) are discussed.
As long as they don't create a dash blink prefix for newish features like borders
One of the announced changes that they are making with the split from WebKit is abandoning vendor prefixing for experimental CSS features, so I don't think there is any risk of that.
I imagine most browsers will start sending a UA with both blink & webkit and then slowly phase out the webkit token.
Yeah, I imagine Chrome and other Blink-based browsers will be phasing out "WebKit" from their UA just after they phase out "KHTML", "Like Gecko", and "Mozilla".
If I somehow could go back a year and tell my past self that in 2013 Opera would be using WebKit, but Chrome would be using something else I would not have believed it.
There's not really a point where Opera is using WebKit and Chrome isn't (at least for new development); Opera's switch to "WebKit" was a switch to base off of Chromium; with Chromium forking WebKit as Blink, new Opera will now also be based on Blink.
Here, google are forking exactly to make it difficult for the original authors to integrate their code, not to take things in a new direction.
Except that they've specifically identified both the new directions in which they want to take the code and the problems that they have been running into trying to take the code in those direction while meeting the commitments and constraints of the upstream project (to which they are both the largest source of commits and the largest source of reviewers.)
Chromium and WebKit have divergent goals and it has become increasingly burdensome trying to reconcile them.
I wonder if blink will still identify itself @ webkit for sites written that way
If by "@" you mean "as", then, probably. I mean, Chrome's user agent string now also identifies itself as "Mozilla", "KHTML", "like Gecko", and "Safari" as well as "Chrome" and "AppleWebKit".
No, new models with Intel chips (Celeron on the low end where ARM lives, Core i5 for the Pixel) were added to the lineup.
Where is my full HD resolution ARM based notebook?
The only full HD (and well beyond, for that matter) Chromebook is the high-end, Core i5-based Chromebook Pixel, so, yeah, they don't have a full HD ARM-based Chromebook. But they never did, so that's not really a sign of a switch from ARM to Intel anywhere.
I wouldn't be surprised if the next-generation of the inexpensive (both ARM and Celeron) Chromebooks had higher pixel count and went from 1366x768 to full HD, though.
Slashdot Mirror
In fact, the question submitter explicitly identified the reason for keeping Windows for the guest access, "funny looks and confused users" when offering Linux instead.
I don't see how signing on to a long-term, high-risk project to build a new browser from scratch with new technology (something that happened long before Blink was announced) is somehow a rejection of an immediate term divorce of Chromium from the WebKit project.
Google themselves often has long-term, high-risk projects that address the same (or overlapping) concerns as the projects behind their existing products, which clearly isn't a "rejection" of those current projects. Why would it be a "rejection" of the current Google project for a Google partner to do the same kind of thing Google itself often does in parallel with its current projects?
If you aren't, then the value decline of the US dollar of the last century is irrelevant to its safety, only the degree of short-term volatility is a safety issue.
Its worse than that, its not for "doing nothing", its for "consuming resources".
Governments can just as easily arbitrarily change the rules and take away:
1) The computing devices that give me access to Bitcoins,
2) The computing devices that Bitcoin exchanges use,
3) The computing devices that other people accepting Bitcoins use,
4) The bank accounts that Bitcoin exchanges use,
5) The legal environment which allows merchants to feel comfortable accepting Bitcoins in exchange for goods and services,
6) My physical freedom to access any of the things that would allow me to access any Bitcoins I do have,
7+) etc.
So, Bitcoin is hardly immune to arbitrary deprivation by the government.
Its also, demonstrably, subject to additional risks without arbitrary deprivation by the government that conventional bank accounts are not subject to.
The thing about the unlimited power that comes with soveriegnty is that governments can confiscate computing devices as well as confiscating bank deposits or any other kind of property.
So how is Bitcoin secure, again?
Unless honest participants in the network definitively control more than half of the computing power on the planet, it is at best impractical rather than impossible. Its not "absolutely, 100% perfectly fraud-proof".
If you are using currency as a long-term store of value, you are mostly using it wrong.
They also exist in the form of various transaction documents and balance statements I can present to a court with jurisdiction over the bank in question as evidence of the existence of the deposits.
No, out-of-process iframes means better isolation of code running from different sources.
It'll still be in WebKit, where it always was. It won't be in Blink, which didn't exist before, so I don't see how that's a substantial change.
V8 is a JavaScript engine used by Chrome, Node.js, and a number of other things.
You are probably thinking of VP8, which is completely unrelated.
Less importantly, because WebKit2 doesn't work the way Chromium wanted a multiprocess model to work.
More importantly, because WebKit2 was an alternative response to Chromium's multiprocess model, so it would have required a time machine for them to do that.
I wouldn't expect that. Google engineers have said that while they have Chromium builds with integrated Dart VM ("Dartium") which are distributed with the Dart SDK, the only purpose they see for that at the present time is improving the edit-test cycle with the SDK, for client-side Dart code, dart2js is preferred because they don't want to create single-browser sites.
I suspect Google will bundle Dart VM with Chrome only if at least one other major browser vendor adopts the VM (and their engineers have said its quite possible that continued JS improvements will make dart2js the preferred client-side method of deploying dart for the forseeable future.)
Google doesn't want to ignore it, they want to fix WebKit's networking code to improve performance on platforms that people actually use, however, doing that while not breaking the legacy bits has produced fragile workarounds that are themselves the source of bugs. Google wants to cut to the heart of the matter, and streamline the whole networking layer rather than continue to work-around the "can't touch this" legacy bits, which they can't do within WebKit given the present constraints imposed by the WebKit project.
Apple, clearly, can ignore it just fine and will no doubt continue ignoring it as Google leaves WebKit.
That's not the point. The point is not to be held back by constraints imposed by commitments of the WebKit project. A short term benefit to the split is removing a lot of code that Chromium doesn't use -- not because it supports different "platforms", but because it supports different WebKit-based browsers with different approaches (e.g., WebKit2's alternative to Chromium's multi-process model, etc.)
No, removing code not used by Chrome is a short-term benefit cited, not a goal. There are goals and motivations cited in the second paragraph regarding improved pace for implementing improvements. If you click through to the Blink project page, as anyone who wanted more than the orbital overview could be expected to, the details of the planned architectural changes (including discussion of what held those changes back while Chrome was tied to WebKit) are discussed.
One of the announced changes that they are making with the split from WebKit is abandoning vendor prefixing for experimental CSS features, so I don't think there is any risk of that.
Yeah, I imagine Chrome and other Blink-based browsers will be phasing out "WebKit" from their UA just after they phase out "KHTML", "Like Gecko", and "Mozilla".
There's not really a point where Opera is using WebKit and Chrome isn't (at least for new development); Opera's switch to "WebKit" was a switch to base off of Chromium; with Chromium forking WebKit as Blink, new Opera will now also be based on Blink.
Well, for one thing, because it is open source, other browsers (Opera, for instance) will be using its code base.
They already have.
Except that they've specifically identified both the new directions in which they want to take the code and the problems that they have been running into trying to take the code in those direction while meeting the commitments and constraints of the upstream project (to which they are both the largest source of commits and the largest source of reviewers.)
Chromium and WebKit have divergent goals and it has become increasingly burdensome trying to reconcile them.
If by "@" you mean "as", then, probably. I mean, Chrome's user agent string now also identifies itself as "Mozilla", "KHTML", "like Gecko", and "Safari" as well as "Chrome" and "AppleWebKit".
No, new models with Intel chips (Celeron on the low end where ARM lives, Core i5 for the Pixel) were added to the lineup.
The only full HD (and well beyond, for that matter) Chromebook is the high-end, Core i5-based Chromebook Pixel, so, yeah, they don't have a full HD ARM-based Chromebook. But they never did, so that's not really a sign of a switch from ARM to Intel anywhere.
I wouldn't be surprised if the next-generation of the inexpensive (both ARM and Celeron) Chromebooks had higher pixel count and went from 1366x768 to full HD, though.