Even if the game is static, then as others previously said, you can store game logic on the server. For example, you can do all the enemy AI there. AI doesn't need to be super-responsive like physics, so adding a little lag due to client-server communication is not the end of the world.
And if the AI is anywhere like most modern games, it would be very hard to reverse engineer. In fact, if a hacking team can reverse engineer it, they would probably be offered jobs by gaming companies. That is, don't expect this kind of game to ever be hacked.
It's been debated at length on the OpenSim and also realXtend mailing lists. Here is the official statement on the OpenSim website, regarding requirements for submitting patches:
You have not studied source code from the GPL Second Life viewer or its derivatives within the last 6 months.
I realize that you can read the particular sentence in a nefarious way. But it seems a very awkward reading. And, the GPL clearly gives you rights to use the code - just not to connect to their servers.
If they removed the GPL, and retained only these legal terms, there might be room for concern. As it is, maybe the terms could be worded better, but I don't see them as 'backpedaling on the GPL' as the title says. Anyhow, they will probably issue a clarification given the current uproar. If they don't, then I guess I might start to worry.
Even if you couldn't connect to their servers with a modified client at all, it would still be useful: Linden Labs also open sourced the server. So, if you like, you can connect with your client to your server, or anybody else's server who allows it.
No, Linden Labs did no such thing. You are probably thinking of OpenSim, a separate open source project, which is a reverse-engineered SL server with a BSD license.
OpenSim is far less mature than the official closed-source SL server. It is also written in C#, with the issues that brings. So it isn't the same as if the official SL server were open sourced (which they considered doing at some point, but never did). To clarify how separate it is from the official SL codebase: OpenSim won't accept patches from people that hack on the SL client, for fear of 'contamination' by the GPL.
They aren't backpedaling on the GPL at all. The code is still GPLed, and you can use it however you want, according to that license.
They do limit your ability to access their servers, and to list you in their pages as a recognized 3rd-party viewer - they have certain requirements for both, and they have now clarified those requirements. But that has nothing to do with the GPL, it's an entirely separate issue.
tl;dr: It's like Wordpress (the software) is GPLed, but Wordpress.com (the website with hosted blogs) won't let you write a blog on their website that links to malware etc.
How can game engines not take advantage of multiple cores?
Several reasons.
If your game will run on both single-core and multi-core machines, it might not make sense to optimize for the latter, which would likely make the former slower - and the former is already slower, so you care more about it.
Many games care more about responsiveness than throughput. While you can run N threads on N cores, getting full utilization of your resources, games usually have a loop in which input feeds into the logic system, which feeds into the physics system, which feeds into the rendering system, and the loop starts again. To get from input to viewable output in the same frame - responsiveness - you can't split up the tasks into multiple threads and let them complete whenever they can. Multithreading might make sense within tasks (say, physics of physically separate regions), but not between them - rendering needs for physics to completely finish before it starts.
That said, console games usually are multithreaded. Since they know the target hardware, they can plan how to use the cores exactly. The tests in TFA, however, were not run on console games but on PC games, which as mentioned in the first point, tend to be optimized for the single-core case.
However, I don't see that it can be legal for them to force you to agree to pay a per-system fee to use a binary patch.
There are two questions here: Legal and practical.
Legally, you can sell GPL software. In fact that is explicitly stated in the GPL itself - it is not anti-commercial, no matter what some people think.
Practically, once you sell a single copy, people are free to distribute it further, so in theory you won't get any more buyers.
But, that problem is exactly the 'problem' Red Hat has with selling RHEL. Overall plenty of people still pay for RHEL, and the free version (CentOS) in many ways helps, by getting more people used to RHEL. The thinking in this company is likely the same: People (or rather large enterprises) will pay for the assurance of timely and secure updates.
Why do you think the recent Google-China issue is either all about Google having a conscience or all about Google acting in their own self interest? It's both, and it's complicated.
For one thing, having a conscience is in Google's best self interest. Public image is crucial for a company like that.
For another, companies Google's size (or any size, if they are competent) don't make decisions based on 1 factor. They take into account many, many factors, including conflicting ones, and they arrive at a decision. In this case, clearly both the conscience issue was a factor as well as the self interest factor.
I am the last person to defend the Chinese government - but I read the article and it is not too clear on how they determined that the source is actually the Chinese government? Is it all based on the fact that the traffic is coming from certain IP addresses or is there (hopefully) more than just that to support the conclusion. Not advocating anyone trying to hack google, but if they did - pwning some unpatched pirated copy of Windows in China to use as a launching point wouldn't exactly be the worst approach to keep the heat from finding whoever was doing it.
Actually it would be a horrible approach, to fake an attack from the Chinese government's servers.
If you are inside China doing that, then you aren't risking a fine or club fed. You're risking being put to death.
If you are outside China doing that... then you are also risking your life. This isn't framing the government of Luxembourg. It's framing a non-democratic nuclear power that strongly believes in the death penalty and has a very poor human rights record. You don't frame a China or a Russia unless you don't mind getting radioactive elements in your water - or worse.
If this was a frame job, the framers should be running for their lives right about now, and probably getting their heads examined if they live long enough to worry about why they were so stupid to frame China.
So, it's possible it was a frame job - the public will probably never know. But I'd bet on the other option.
This is really stupid. If anything, it might renew interest in a relatively obscure (for younger people) book. Now, it will just result in backlash as people will refuse to buy anything from Dick now.
Please don't refrain from reading PKD's works because his estate are greedy morons. PKD was a remarkable author, one of the best in his field in the 20th century, and maybe not just in his field. There is a tremendous amount of depth in his novels, as well as a steady stream of brilllliant ideas (which explains why so many movies have been made from them).
If you must punish the estate, borrow his books or buy them used. They are really worth reading.
They have been pretty open about latency issues. The server needs to be reasonably close (max 1000 miles) to keep round trip time below 80ms.
Well, they say 80ms and 1,000 miles. But first of all, even that seems a little dubious, for two reasons:
80ms is the very limit of the 'feeling of control' (before the lag gets to be too much). If they are always that close to the limit, noise will make things very bad, a lot of the time. Especially as more and more people sign up for the service (due to both load on their servers, and the network out of it).
80ms is the ping. But the ping isn't the entire story: Events happen on the *server* here, so there is 40ms until you are even aware of them, and *then* 80ms after you respond for you to see your response. That 40ms doesn't exist if the game is doing distributed physics (say, by having your machine 'in charge' of your character), or various forms of clientside prediction. But they aren't doing either of these, the client is a dumb terminal.
In general, OnLive (/GaiKai) are interesting, but to work, they need radical breakthroughs in several separate areas, primarily compression and networking. It is possible they solved both. However, if you had a breakthrough in even one of them, it would be lucrative enough by itself. Whereas they are relying on multiple breakthroughs for their specific product. So, I guess it's possible, but it just seems odd. Add to that the concerns about lag even with 80ms, and something is fishy.
Furthermore, this will be expensive. Even with the 'cloud gaming' model of sharing hardware, they will need at least 5 machines per customer (TechCrunch guesses more actually), which means just for the hardware costs people will need to pay hundreds of dollars a year. Add to that the cost of bandwidth - this is very, very bandwidth intensive, ISPs will raise prices if this takes off - and the other OnLive hardware costs, plus additional OnLive costs for salaries and so forth, and this will not be cheap. Even if this worked as promised, would enough people be willing to pay a large amount of money for it? I'm not sure.
Tumors form through uncontrolled growth of cells. Axons are the connections between nerve cells that conduct the nerve impulses. There is no cell division proliferation going on here.
That's true, the goal here is to let existing cells regrow their axons, not for cells to multiply - which is what cancer is a bad form of. So this might not directly be relevant to cancer.
However, there are plenty of other ways in which this could turn out to have side effects that make it a bad idea. One basic concern is that there is probably a reason why axon growth is supressed in the central nervous system - after all, the brain is amazingly complicated, and all those connections between brain cells need to be of the right kind. If things start connecting where they shouldn't, badness may occur. So just stopping the suppression might lead to too many connections being made.
But this is all speculation. Bottom line, this sounds like a breakthrough finding by the researchers, and one that will lead to a lot of followup investigation. Kudos to them.
The rifle argument gets pretty stale when you realize the Nazis could just use their air force to bomb Switzerland to kingdom come had they so desired. Nazi close air support aircraft would make mincemeat of resistance by soft targets.
Sure, they could have done that. But bombing from the air is very different from invading and holding ground, when that ground is (1) very defensible, geographically speaking, and (2) every grown man has a rifle.
It just made more sense to not invade and to not bomb, and to let Switzerland stay 'neutral', while also acting as a bank to the Nazis.
In other words, it was a combination of the two factors, not one or the other.
Well, compare it to V8, and it is about by an order of magnitude by the Debian benchmarks. But I think their version of V8 is a little old, so it should be a little better than that by now.
Perhaps it's a great language, but it reduced modern Core i7 computers to performance of a 486, negating 15 years of computing revolution.
Some sort of interpreted language was needed for the web, to run untrusted code in a secure way. C couldn't be used for that. So it was a slow language or no language, back then. The only alternative at the time was Java, but it actually had worse performance in the way that most mattered to the web - startup times (not much use if it gets fast later on, if you need to wait an annoyingly long time for each page).
New JavaScript engines are slower than C, but by less than an order of magnitude - and getting faster. There is no theoretical reason why they can't run fast ('dynamic types' isn't enough of a reason - modern tracing, hidden classes, etc. approaches can deal with that).
For years it's been known that kids from third world countries usually don't suffer from auto-immune diseases and things akin because of the sickly environment they are exposed too. It's simple, if you live constantly with the risk of infection your body will build up a stronger immune system than someone who lives in a bubble.
Actually no, it isn't known. It is a hypothesis, the "hygiene theory". Such things are very hard to prove.
Speaking of proof, TFA actually seems to not be relevant to the hygiene theory at all: All it says is that staph on your skin now will reduce inflammation. It says nothing about being exposed to staph as a child helping you as an adult.
The hygiene hypothesis might be true - there are other lines of evidence supporting it. But, my points are that (1) it isn't a fact quite yet, and (2) TFA either doesn't support it, or is poor reporting.
Why would Google publish their marketshare changes? Especially because only way they can go is down, unless they can gain marketshare in China (from Baidu) or Russia (from yandex).
Not so. Actually both Google and Bing gained about 1% in this new data - at the expense of Yahoo.
In general Google and Bing are eating away at Yahoo's market share, and have been for quite a while.
To extend the analogy someone else used earlier, OO in Javascript is like attempting to tighten a screw with a hammer.
I respectfully disagree.
See for example John Resig's approach. Basically it adds more familiar class-based inheritance to JavaScript, building upon the existing prototype-based inheritance. I am using it in a large project (see my homepage link), and it works great. Btw, it seems Google has something similar in the Closure Library, as well, but I didn't check if it was as concise as Resig's.
JavaScript is a flexible language (Crockford once called it "Lisp in C's clothing"), which lets you 'extend' it in ways like the one linked to above.
None of us would use Javascript if we had a choice, but we don't. So toolkits like JQuery or this release by Google are life savers.
JavaScript the language is actually very nice - the main problems with 'JavaScript' are browser inconsistencies, the DOM, etc. etc.
But if you take JavaScript itself, then yeah it has some problems - it was rushed - but it has good parts: It's a dynamic language, supports closures, first-class functions, convenient object definition syntax (from where we get JSON), etc. Due to its ubiquity, it also has the most secure and fast engines of any dynamic language (except for LuaJIT, but a comparison there is a topic all in itself).
Because of those, JavaScript is being used more and more as a scripting language outside of web browsers, for example in desktop environments, game engines, etc. If you stick to good coding practices in JavaScript, you can write large and robust applications in it.
But, again, to return to the original point, the current state of JavaScript in browsers is very messy. Which is why we need things like jQuery, and maybe this new library from Google as well.
Drivers are in the kernel or as modules aren't they? We already get regular kernel updates for kernels, about the only time you have to reboot, and video kernel modules just need to restart X.
A lot of the time, the driver will only work with the latest kernel. This is in part due to the kernel (on purpose) not having stable ABIs. So, you do need to upgrade the entire kernel for such things (which are common).
So why isn't the perpetual slow upgrade then the way to do it, why have a whole new "version" all the time anyway? That part I never understood. There must be a reason, I just really don't know what it is. Just slop over thinking from the closed source world where they need an excuse to dun you again for another wad of ca$h every few years or something?
My guess is this: Ubuntu is primarily a desktop distro. People using desktops tend to want the latest firefox, GIMP, graphics drivers, and so forth. It's possible in theory to backport those in various ways (PPAs, etc.), but in general the standard way to install stuff is from the repos. So, the approach is to upgrade every 6 months.
In theory this is easier to solve for apps like Firefox, GIMP, etc., than for drivers. But desktop users tend to have newer hardware than servers. My desktop, for example, was bought last year but only started to be fully supported out of the box with Karmic. If the upgrade cycle was 12 months, I might have had another 6 months to wait.
I agree with you that this isn't an easy attack vector, and you make a good point that if one can do such an attack, there are plenty of juicy targets for it.
Still, collisions have been found for the simpler variants of SHA. So I, personally, would just enable the option to actually check for duplicates, instead of worry about yet another potential security hole - since it is so trivial to close this one. Unless, of course, enabling that option makes the entire thing not cost-effective (which I actually doubt, but you never know until you test I guess).
The probability of a hash collision for a 256 bit hash (or even a 128 bit one) is negligible.
How negligible? Well, the probability of a collision is never more then N^2 / 2^h, where N is the number of blocks stored and h is the number of bits in the hash. So, if we have 2^64 blocks stored (a mere billion terabytes or so for 128 byte blocks) , the probability of a collision is less than 2^(-128), or 10^(-38). Hardly worth worrying about.
And that's an upper limit, not the actual value.
There are a lot of assumptions there. For one thing, you assume that hash functions on normal data give 'random' hashes. Optimally that is the case, and it seems to be so in practice, but it isn't a mathematical certainty. In other words there is a risk here we cannot quantify.
For another thing, hashes can have security vulnerabilities. That is, if someone is intentionally trying to find collisions, that might be easier than attempting to do so at random. This could then lead to attacks of the following sort:
Rent a VM on a hosted server
Find the hash value of some crucial area on the disk (e.g. part of the kernel). This might be easy if you know what OS they use.
Create a block with the same hash, potentially confusing the underlying filesystem into using yours.
(Most likely it won't, because it will use the older one. But in theory you can do this before say a security patch is applied, and your data will be used instead.)
Other attacks might be against data and not the OS, say if you know some data is stored on another VM on the same machine.
I would personally not run this cool feature without the flag to actually check for duplicates.
Hey Perlman (if that is your real name): the dot-com bubble called. They want their failed business strategy back. Subsidise the hardware, sure, but don't give it away. That's just asking for financial disaster. Your business is risky enough as it is.
They're not really giving anything away. The hardware will be 'free', but you'll be paying a hefty subscription.
This isn't like the dot-com bubble's business model. This is like the cellphone business model.
Anyhow this isn't the problem with the concept. The problem is they think games at 80ms lag are fun. That's 80ms of input lag, that is, between moving the mouse and seeing it move, or clicking a button and seeing a shot - not just for other player's actions. 80ms sounds horrible to me.
Slashdot Mirror
Even if the game is static, then as others previously said, you can store game logic on the server. For example, you can do all the enemy AI there. AI doesn't need to be super-responsive like physics, so adding a little lag due to client-server communication is not the end of the world.
And if the AI is anywhere like most modern games, it would be very hard to reverse engineer. In fact, if a hacking team can reverse engineer it, they would probably be offered jobs by gaming companies. That is, don't expect this kind of game to ever be hacked.
You have not studied source code from the GPL Second Life viewer or its derivatives within the last 6 months.
See also the other terms there.
I realize that you can read the particular sentence in a nefarious way. But it seems a very awkward reading. And, the GPL clearly gives you rights to use the code - just not to connect to their servers.
If they removed the GPL, and retained only these legal terms, there might be room for concern. As it is, maybe the terms could be worded better, but I don't see them as 'backpedaling on the GPL' as the title says. Anyhow, they will probably issue a clarification given the current uproar. If they don't, then I guess I might start to worry.
Even if you couldn't connect to their servers with a modified client at all, it would still be useful: Linden Labs also open sourced the server. So, if you like, you can connect with your client to your server, or anybody else's server who allows it.
No, Linden Labs did no such thing. You are probably thinking of OpenSim, a separate open source project, which is a reverse-engineered SL server with a BSD license.
OpenSim is far less mature than the official closed-source SL server. It is also written in C#, with the issues that brings. So it isn't the same as if the official SL server were open sourced (which they considered doing at some point, but never did). To clarify how separate it is from the official SL codebase: OpenSim won't accept patches from people that hack on the SL client, for fear of 'contamination' by the GPL.
They aren't backpedaling on the GPL at all. The code is still GPLed, and you can use it however you want, according to that license.
They do limit your ability to access their servers, and to list you in their pages as a recognized 3rd-party viewer - they have certain requirements for both, and they have now clarified those requirements. But that has nothing to do with the GPL, it's an entirely separate issue.
tl;dr: It's like Wordpress (the software) is GPLed, but Wordpress.com (the website with hosted blogs) won't let you write a blog on their website that links to malware etc.
How can game engines not take advantage of multiple cores?
Several reasons.
That said, console games usually are multithreaded. Since they know the target hardware, they can plan how to use the cores exactly. The tests in TFA, however, were not run on console games but on PC games, which as mentioned in the first point, tend to be optimized for the single-core case.
However, I don't see that it can be legal for them to force you to agree to pay a per-system fee to use a binary patch.
There are two questions here: Legal and practical.
Legally, you can sell GPL software. In fact that is explicitly stated in the GPL itself - it is not anti-commercial, no matter what some people think.
Practically, once you sell a single copy, people are free to distribute it further, so in theory you won't get any more buyers.
But, that problem is exactly the 'problem' Red Hat has with selling RHEL. Overall plenty of people still pay for RHEL, and the free version (CentOS) in many ways helps, by getting more people used to RHEL. The thinking in this company is likely the same: People (or rather large enterprises) will pay for the assurance of timely and secure updates.
Why do you think the recent Google-China issue is either all about Google having a conscience or all about Google acting in their own self interest? It's both, and it's complicated.
For one thing, having a conscience is in Google's best self interest. Public image is crucial for a company like that.
For another, companies Google's size (or any size, if they are competent) don't make decisions based on 1 factor. They take into account many, many factors, including conflicting ones, and they arrive at a decision. In this case, clearly both the conscience issue was a factor as well as the self interest factor.
I am the last person to defend the Chinese government - but I read the article and it is not too clear on how they determined that the source is actually the Chinese government? Is it all based on the fact that the traffic is coming from certain IP addresses or is there (hopefully) more than just that to support the conclusion. Not advocating anyone trying to hack google, but if they did - pwning some unpatched pirated copy of Windows in China to use as a launching point wouldn't exactly be the worst approach to keep the heat from finding whoever was doing it.
Actually it would be a horrible approach, to fake an attack from the Chinese government's servers.
If you are inside China doing that, then you aren't risking a fine or club fed. You're risking being put to death.
If you are outside China doing that... then you are also risking your life. This isn't framing the government of Luxembourg. It's framing a non-democratic nuclear power that strongly believes in the death penalty and has a very poor human rights record. You don't frame a China or a Russia unless you don't mind getting radioactive elements in your water - or worse.
If this was a frame job, the framers should be running for their lives right about now, and probably getting their heads examined if they live long enough to worry about why they were so stupid to frame China.
So, it's possible it was a frame job - the public will probably never know. But I'd bet on the other option.
This is really stupid. If anything, it might renew interest in a relatively obscure (for younger people) book. Now, it will just result in backlash as people will refuse to buy anything from Dick now.
Please don't refrain from reading PKD's works because his estate are greedy morons. PKD was a remarkable author, one of the best in his field in the 20th century, and maybe not just in his field. There is a tremendous amount of depth in his novels, as well as a steady stream of brilllliant ideas (which explains why so many movies have been made from them).
If you must punish the estate, borrow his books or buy them used. They are really worth reading.
They have been pretty open about latency issues. The server needs to be reasonably close (max 1000 miles) to keep round trip time below 80ms.
Well, they say 80ms and 1,000 miles. But first of all, even that seems a little dubious, for two reasons:
In general, OnLive (/GaiKai) are interesting, but to work, they need radical breakthroughs in several separate areas, primarily compression and networking. It is possible they solved both. However, if you had a breakthrough in even one of them, it would be lucrative enough by itself. Whereas they are relying on multiple breakthroughs for their specific product. So, I guess it's possible, but it just seems odd. Add to that the concerns about lag even with 80ms, and something is fishy.
Furthermore, this will be expensive. Even with the 'cloud gaming' model of sharing hardware, they will need at least 5 machines per customer (TechCrunch guesses more actually), which means just for the hardware costs people will need to pay hundreds of dollars a year. Add to that the cost of bandwidth - this is very, very bandwidth intensive, ISPs will raise prices if this takes off - and the other OnLive hardware costs, plus additional OnLive costs for salaries and so forth, and this will not be cheap. Even if this worked as promised, would enough people be willing to pay a large amount of money for it? I'm not sure.
THAT'S the difference between Apple and MS. Apple does not. They have, what 8%?
And even that is only in the US. Outside of the US, Apple's market share is negligible.
Tumors form through uncontrolled growth of cells. Axons are the connections between nerve cells that conduct the nerve impulses. There is no cell division proliferation going on here.
That's true, the goal here is to let existing cells regrow their axons, not for cells to multiply - which is what cancer is a bad form of. So this might not directly be relevant to cancer.
However, there are plenty of other ways in which this could turn out to have side effects that make it a bad idea. One basic concern is that there is probably a reason why axon growth is supressed in the central nervous system - after all, the brain is amazingly complicated, and all those connections between brain cells need to be of the right kind. If things start connecting where they shouldn't, badness may occur. So just stopping the suppression might lead to too many connections being made.
But this is all speculation. Bottom line, this sounds like a breakthrough finding by the researchers, and one that will lead to a lot of followup investigation. Kudos to them.
The rifle argument gets pretty stale when you realize the Nazis could just use their air force to bomb Switzerland to kingdom come had they so desired. Nazi close air support aircraft would make mincemeat of resistance by soft targets.
Sure, they could have done that. But bombing from the air is very different from invading and holding ground, when that ground is (1) very defensible, geographically speaking, and (2) every grown man has a rifle.
It just made more sense to not invade and to not bomb, and to let Switzerland stay 'neutral', while also acting as a bank to the Nazis.
In other words, it was a combination of the two factors, not one or the other.
Well, compare it to V8, and it is about by an order of magnitude by the Debian benchmarks. But I think their version of V8 is a little old, so it should be a little better than that by now.
Perhaps it's a great language, but it reduced modern Core i7 computers to performance of a 486, negating 15 years of computing revolution.
For years it's been known that kids from third world countries usually don't suffer from auto-immune diseases and things akin because of the sickly environment they are exposed too. It's simple, if you live constantly with the risk of infection your body will build up a stronger immune system than someone who lives in a bubble.
Actually no, it isn't known. It is a hypothesis, the "hygiene theory". Such things are very hard to prove.
Speaking of proof, TFA actually seems to not be relevant to the hygiene theory at all: All it says is that staph on your skin now will reduce inflammation. It says nothing about being exposed to staph as a child helping you as an adult.
The hygiene hypothesis might be true - there are other lines of evidence supporting it. But, my points are that (1) it isn't a fact quite yet, and (2) TFA either doesn't support it, or is poor reporting.
Why would Google publish their marketshare changes? Especially because only way they can go is down, unless they can gain marketshare in China (from Baidu) or Russia (from yandex).
Not so. Actually both Google and Bing gained about 1% in this new data - at the expense of Yahoo.
In general Google and Bing are eating away at Yahoo's market share, and have been for quite a while.
To extend the analogy someone else used earlier, OO in Javascript is like attempting to tighten a screw with a hammer.
I respectfully disagree.
See for example John Resig's approach. Basically it adds more familiar class-based inheritance to JavaScript, building upon the existing prototype-based inheritance. I am using it in a large project (see my homepage link), and it works great. Btw, it seems Google has something similar in the Closure Library, as well, but I didn't check if it was as concise as Resig's.
JavaScript is a flexible language (Crockford once called it "Lisp in C's clothing"), which lets you 'extend' it in ways like the one linked to above.
None of us would use Javascript if we had a choice, but we don't. So toolkits like JQuery or this release by Google are life savers.
JavaScript the language is actually very nice - the main problems with 'JavaScript' are browser inconsistencies, the DOM, etc. etc.
But if you take JavaScript itself, then yeah it has some problems - it was rushed - but it has good parts: It's a dynamic language, supports closures, first-class functions, convenient object definition syntax (from where we get JSON), etc. Due to its ubiquity, it also has the most secure and fast engines of any dynamic language (except for LuaJIT, but a comparison there is a topic all in itself).
Because of those, JavaScript is being used more and more as a scripting language outside of web browsers, for example in desktop environments, game engines, etc. If you stick to good coding practices in JavaScript, you can write large and robust applications in it.
But, again, to return to the original point, the current state of JavaScript in browsers is very messy. Which is why we need things like jQuery, and maybe this new library from Google as well.
Drivers are in the kernel or as modules aren't they? We already get regular kernel updates for kernels, about the only time you have to reboot, and video kernel modules just need to restart X.
A lot of the time, the driver will only work with the latest kernel. This is in part due to the kernel (on purpose) not having stable ABIs. So, you do need to upgrade the entire kernel for such things (which are common).
So why isn't the perpetual slow upgrade then the way to do it, why have a whole new "version" all the time anyway? That part I never understood. There must be a reason, I just really don't know what it is. Just slop over thinking from the closed source world where they need an excuse to dun you again for another wad of ca$h every few years or something?
My guess is this: Ubuntu is primarily a desktop distro. People using desktops tend to want the latest firefox, GIMP, graphics drivers, and so forth. It's possible in theory to backport those in various ways (PPAs, etc.), but in general the standard way to install stuff is from the repos. So, the approach is to upgrade every 6 months.
In theory this is easier to solve for apps like Firefox, GIMP, etc., than for drivers. But desktop users tend to have newer hardware than servers. My desktop, for example, was bought last year but only started to be fully supported out of the box with Karmic. If the upgrade cycle was 12 months, I might have had another 6 months to wait.
I agree with you that this isn't an easy attack vector, and you make a good point that if one can do such an attack, there are plenty of juicy targets for it.
Still, collisions have been found for the simpler variants of SHA. So I, personally, would just enable the option to actually check for duplicates, instead of worry about yet another potential security hole - since it is so trivial to close this one. Unless, of course, enabling that option makes the entire thing not cost-effective (which I actually doubt, but you never know until you test I guess).
The probability of a hash collision for a 256 bit hash (or even a 128 bit one) is negligible.
How negligible? Well, the probability of a collision is never more then N^2 / 2^h, where N is the number of blocks stored and h is the number of bits in the hash. So, if we have 2^64 blocks stored (a mere billion terabytes or so for 128 byte blocks) , the probability of a collision is less than 2^(-128), or 10^(-38). Hardly worth worrying about.
And that's an upper limit, not the actual value.
There are a lot of assumptions there. For one thing, you assume that hash functions on normal data give 'random' hashes. Optimally that is the case, and it seems to be so in practice, but it isn't a mathematical certainty. In other words there is a risk here we cannot quantify.
For another thing, hashes can have security vulnerabilities. That is, if someone is intentionally trying to find collisions, that might be easier than attempting to do so at random. This could then lead to attacks of the following sort:
Other attacks might be against data and not the OS, say if you know some data is stored on another VM on the same machine.
I would personally not run this cool feature without the flag to actually check for duplicates.
"is so cheap they plan to give it away"
Hey Perlman (if that is your real name): the dot-com bubble called. They want their failed business strategy back. Subsidise the hardware, sure, but don't give it away. That's just asking for financial disaster. Your business is risky enough as it is.
They're not really giving anything away. The hardware will be 'free', but you'll be paying a hefty subscription.
This isn't like the dot-com bubble's business model. This is like the cellphone business model.
Anyhow this isn't the problem with the concept. The problem is they think games at 80ms lag are fun. That's 80ms of input lag, that is, between moving the mouse and seeing it move, or clicking a button and seeing a shot - not just for other player's actions. 80ms sounds horrible to me.