``You might save a few blocks because of the shared OS files but if you did a proper minimal OS install then the gain hardly seems to be worth the effort.''
Right, but note the if. Most of the places where I've seen virtualization used have most of the VMs running instances of a proprietary operating system which shall remain unnamed. Together with other components that tend to be common, the amount of data that is common among instances can easily be over 10 GB per instance.
There is certainly a more efficient way to deal with > 10GB of common data per instance than storing the same data multiple times, and deduplication is one way to do things more efficiently.
It's one of the things I never really managed to wrap my head around: why would you want to install many instances of the same OS on the same machine to begin with? Besides using lots of disk space, each instance will also use up memory and redundantly use up resources for updates, background tasks that each OS is running, and basically everything else they have in common.
Sure, you can add on a lot of clever tricks to deduplicate resource usage, but why introduce the duplication in the first place?
``Well--except that pesky material on the surface of a disk that can store either a '1' state or a '0' state. Most people call that a 'bit'. Strangely enough, that 'binary' state is conducive to measuring in powers of two...''
At first, I thought "well, duh", of course you're right.
But then I realized that there is absolutely nothing preventing you from measuring storage in SI-multiples of bits. Which is the same thing Ethernet does with transfer rates, incidentally. So really, just because a bit has two states doesn't mean that this somehow makes it easier to express number of bits in powers of two.
``And yet many of the same people who will cry foul over this will be first in line telling the government it is morally obligated to provide X social program or prop up Y industry "for the good of the country." Surely that isn't a colossal waste, won't go to lining the pockets of consultants, won't get dragged down by graft, won't go over budget estimations, et cetera.''
I think you're conflating two issues there. Allow me to explain.
Your whole post is full of examples of government inefficiency. They are good examples, and I am completely with you there. Government is inefficient, and we know it.
Of course, that doesn't necessarily mean that there is no inefficiency outside of government. And indeed, there is plenty. However, there is a key difference between inefficiency in government and inefficiency outside of government, and that is that, outside of government, you have a choice. If company A is less efficient that company B and therefore charges more for essentially the same products, you can go with company B instead. Doing the same thing with a government is much more involved.
For the above reasons, it is better in many cases to have things provided by multiple, competing organizations than by a government (or, indeed, another monopoly - the same reasoning applies). There will still be inefficiency, but, since you can choose your provider, providers have an incentive to curb their inefficiencies in order to be more competitive. I think that's the long version of what you've been saying, and I agree.
However, there is one key point, and that is that it's sometimes _not_ a good thing to be able to choose your provider and have providers reduce their inefficiencies. This is the case in many social programs. Presuming the social program has any merit at all, the population can be divided into two classes: those who would currently directly benefit from the program, and those who wouldn't.
E.g. if the program provided unemployment benefits, and I were unemployed, and you weren't, then, I would directly benefit, but you wouldn't. If we were free to choose, I might want the system that provided the maximum unemployment benefits, and you might want the system that provided the minimum. But that wouldn't work, because then the money for running the program would have to come from those who don't have it, while those who do have money wouldn't be contributing it.
To make the program work, it must be mandatory for those who have money to contribute to the program that provides money to those who need it. And that means you need the government, despite its tendency towards inefficiency. It's the difference between having a system that works inefficiently with government involvement, or a system that doesn't work at all. And what makes the former system inefficient is precisely the same thing that makes it work at all: the fact that participation is mandatory.
Long story short: if you can make it work while preserving freedom of choice, do so. It will preserve liberty and be more efficient. But in some cases, the only way to make it work is to take away that freedom. The same people can cry foul over inefficiencies in government and still advocate government programs: we need some government programs, but we still want things to be as efficient as possible.
There are whole classes of bugs that could right out be eliminated by writing software in safe languages, and using safe APIs. Many of such bugs (buffer overruns, integer overflows, stack smashing, memory leaks, dangling pointers, format string vulnerabilities, SQL injections, predictable filename attacks,...) end up being featured over and over and over again in vulnerability reports and exploits.
Considering that we have languages and APIs that are safe, efficient, and expressive, all exploits that fall into one of these classes could and should have been avoided. You really need some unsafe constructs to write the kernel of your operating system, but they really have no business being anywhere else. Least of all in applications that can receive arbitrary input from over the network!
Ditch C for application development, and you will be more productive and safer as a result.
It seems to me you are saying that the entire model of HTML and Javascript makes browsers hard to secure, but I don't really see that. Don't HTML and Javascript execute in a pretty well defined sandbox that specifies, basically, you can do this and this and this, and nothing else?
I don't see what about HTML and Javascript makes them especially hard to secure. Compare to, say, Java applets (yes, blast from the past), where you must somehow guard against writing, deleting, or executing arbitrary local files, even though applets have access to APIs for doing that. Or worse, programs containing native code, which have even more tricks up their sleeves and are harder to analyze, too.
On the scale of things, I would say HTML and Javascript aren't anywhere near the top of being hard to secure.
Indeed. Writing a web browser is bloody nasty work. Even the standards are hellish to have to implement, and then there is all that non-standard crap floating around the web that you're supposed to be able to handle. To make things worse, to make your browser usable you must also write pretty performant code. And you have to be able to stand up to the flak you will get if you don't beat the competition on JavaScript benchmarks and Acidn tests, don't have someone's favorite Firefox extension available, or don't run on someone's favorite platform. And even if you work with a team of demi-gods and somehow accomplish all that, your browser will still be susceptible to vulnerabilities in plugins and in libraries that it uses.
Really, I have immense respect for the developers of today's leading web browsers. It's a herculean task, and I know it. Keep it up, fellows!
``I wouldn't call a company that does R&D and licenses the heck out of its work "King of the Patent Trolls.''
What is ARM's business model again? Are they intellectual property trolls? They certainly seem to be helping to bring a lot of good technology to the world.
In case anyone wasn't convinced already, this shows that security questions are a bad idea. Simply stated, they introduce more points of failure into the system, and it's the weakest one that determines how easy the system is to defeat. In short, you can not make the system more secure by providing another way to gain entry.
Of course, security isn't only about keeping the bad guys out, but also about letting the good guys in. I guess that is what gave rise to security questions: to give you a way to gain entry if you forgot your passphrase. But even then, I don't see security questions as a good solution. I like the established method of "provide what authentication credentials you do have, and we'll send you a new passphrase by a method we agreed on earlier" better.
``Why is it more difficult for proprietary systems?
* MSI based installer
+ if installing from DC based on group policy, don't do anything, or
+ else, allow to install SSL cert + XML service URL for querying of updates. Update check interval is specified and is set 1-14 days.''
I don't know what all that means, but the problems with automatic updates for proprietary software aren't technical, but legal.
The same technical solutions that work for open source (distribution packages the software and provides updates) would work for proprietary software, too - but if the license prohibits redistribution (as many proprietary licenses do), this method wouldn't be allowed.
Speaking of Wikipedia, an idea that has long been in my mind, but that I have never sat down and worked out is distributed hosting of Wikipedia. The idea is that volunteers each contribute some resources (network capacity, storage space, RAM, and CPU cycles) to host and serve part of the content.
This way, we should be able to reduce the load on the (donation supported) Wikimedia servers, as well as increase the redundancy in the system.
Is anybody already working on this or are there perhaps even already implementations of this idea?
At the end of it all comes the realization that planning for crisis is complicated, and getting it right is hard. It's also something that every organization I have ever worked with has underestimated considerably. From what little information I have about this incident with Wikimedia (I noticed nothing, myself), they did considerably better than average.
But you are right: the right approach is not to prepare for contingency, but to make recovery part of the normal flow. If failure and recovery are part of the everyday routine, you will know what things are broken before disaster strikes, and when it does, you will be prepared. Nothing will make your organization infallible, but at least you will have procedures, people who know how to execute them, and experience with doing so.
Well, it is a great step forward. And making a system like this work for software that isn't freely redistributable is quite a bit trickier than for open source software. I hope more vendors get with the programme. Even though I don't maintain any Windows systems, I still welcome any development that makes their maintenance less of a burden.
``There are so many reasons that nuclear power technology now available or is on the horizon is bad and so many better alternatives, why are we wasting time on it?''
The same has been said about many of those better alternatives, no doubt. I see things differently. I am happy to see that scientists are researching alternatives to the current ways to produce and deliver energy. I don't care what technology the next round of power plants are based on or who invented that technology, as long as it scores better on the metrics we consider important. Let's discuss what those metrics should be and evaluate new inventions based on those.
Metrics that matter are, for example, pollution generated by the technology, safety, and cost (these should probably be more fine-grained and normalized to badness per MWh). All of the technology alternatives are going to score some points for badness here. However, if a new technology generates less pollution while being at least as safe and at most as expensive as current technology, then it's clearly a step ahead.
I imagine version control would help to identify who contributed what piece of code.
Most version control systems I've used have a 'blame' command (some even have 'praise' as an alias;-) ) that will show you who contributed each line. Every line that isn't by an author who has agreed to the new license means you have work to do - either get the author's approval, or replace the code.
Just to throw in my two cents, I think that if you are concerned about where the mouse cursor is supposed to be, the scroll bars and the most often used buttons should go on the _left_.
The reason for that is that most of the content that will be in the windows is going to be on the left, including most things you are going to want to interact with.
NeXTSTEP had scrollbars on the left and icons on the edges of the screen, and they decided to do it that way after quite a lot of research and thinking about it.
In practice, of course, people are going to expect things like scroll bars and close buttons to be on the right, so they will balk if you don't put them there. But that doesn't say anything about what would have been the best place to put them if people didn't have preconceived expectations.
Ok, so, since the summary didn't make this clear and I didn't find any explanation in the article, maybe someone on Slashdot can shed some light on this. What took Mozilla so long? It's a critical vulnerability that allows remote code execution. Why did is it taking over a month to fix?
And what's being delivered is Windows 7, DX10, and IE9. That big new Corvette Engine does not fit in 8 year old Chevy Cavalier, is that GM's fault?
As far as I am concerned, it isn't really a question of fault. Please do not take my earlier post as an attempt to assign blame. It was not intended that way.
This has created a small tempest of protest from those users still using XP, but this is less of an arbitrary decision than some appear to think. It's literally impossible to port Windows Vista/Win 7-style hardware acceleration backwards to XP. Microsoft would have to either develop a workaround from scratch or create a CPU-driven 'software mode.'
Yes. That's all very well, but that doesn't mean customers shouldn't complain. Were I a customer of Microsoft's, I would be less interested in excuses and technical explanations and more interested in what was actually being delivered and what I could do with it.
Besides, it can't be that Microsoft figured this out just now. They deliberately took the decisions to make use of features that they of all people should have known weren't available in Windows XP. In other words, they chose not to support Windows XP. I can very well understand that users of Windows XP would not be happy with that.
The good news is, of course, that nobody actually needs MSIE 9. This leaves Microsoft free to make whatever decision they see fit when implementing it. People who want a modern browser on Windows XP can use any of the several alternatives which are available now: Opera, Safari, Mozilla Firefox, and Chrome are all modern browsers available for Windows XP. And for applications that depend on MSIE-specific features, you can use an earlier version of Windows XP.
Long story short: Microsoft did decide not to support Windows XP. I can see why users of Windows XP would be unhappy about that. But it's not a big problem.
They shouldn't have to. Standard procedure _should_ be that only authenticated people have access, and authentication credentials are disabled as soon as a person's contract ends. You trust people who work for you (otherwise, don't let them work for you!), but as soon as they don't work for you anymore, they are outsiders who shouldn't have access.
``The point is that the choice should be mine as a user, and should not be forced onto me by Mozilla by restricting my options.''
Right. And the good news is that, because Firefox is free software, Mozilla cannot restrict your options there. They can decide not to provide you with the capabilities you want out of the box, but they can't prevent you from adding those capabilities.
Slashdot Mirror
``You might save a few blocks because of the shared OS files but if you did a proper minimal OS install then the gain hardly seems to be worth the effort.''
Right, but note the if. Most of the places where I've seen virtualization used have most of the VMs running instances of a proprietary operating system which shall remain unnamed. Together with other components that tend to be common, the amount of data that is common among instances can easily be over 10 GB per instance.
There is certainly a more efficient way to deal with > 10GB of common data per instance than storing the same data multiple times, and deduplication is one way to do things more efficiently.
Right.
It's one of the things I never really managed to wrap my head around: why would you want to install many instances of the same OS on the same machine to begin with? Besides using lots of disk space, each instance will also use up memory and redundantly use up resources for updates, background tasks that each OS is running, and basically everything else they have in common.
Sure, you can add on a lot of clever tricks to deduplicate resource usage, but why introduce the duplication in the first place?
``Well--except that pesky material on the surface of a disk that can store either a '1' state or a '0' state. Most people call that a 'bit'. Strangely enough, that 'binary' state is conducive to measuring in powers of two...''
At first, I thought "well, duh", of course you're right.
But then I realized that there is absolutely nothing preventing you from measuring storage in SI-multiples of bits. Which is the same thing Ethernet does with transfer rates, incidentally. So really, just because a bit has two states doesn't mean that this somehow makes it easier to express number of bits in powers of two.
``The most annoying? That nobody has hacked Snow Leopard to restore real units.''
I would hazard a guess that this is because it's not open source.
``And yet many of the same people who will cry foul over this will be first in line telling the government it is morally obligated to provide X social program or prop up Y industry "for the good of the country." Surely that isn't a colossal waste, won't go to lining the pockets of consultants, won't get dragged down by graft, won't go over budget estimations, et cetera.''
I think you're conflating two issues there. Allow me to explain.
Your whole post is full of examples of government inefficiency. They are good examples, and I am completely with you there. Government is inefficient, and we know it.
Of course, that doesn't necessarily mean that there is no inefficiency outside of government. And indeed, there is plenty. However, there is a key difference between inefficiency in government and inefficiency outside of government, and that is that, outside of government, you have a choice. If company A is less efficient that company B and therefore charges more for essentially the same products, you can go with company B instead. Doing the same thing with a government is much more involved.
For the above reasons, it is better in many cases to have things provided by multiple, competing organizations than by a government (or, indeed, another monopoly - the same reasoning applies). There will still be inefficiency, but, since you can choose your provider, providers have an incentive to curb their inefficiencies in order to be more competitive. I think that's the long version of what you've been saying, and I agree.
However, there is one key point, and that is that it's sometimes _not_ a good thing to be able to choose your provider and have providers reduce their inefficiencies. This is the case in many social programs. Presuming the social program has any merit at all, the population can be divided into two classes: those who would currently directly benefit from the program, and those who wouldn't.
E.g. if the program provided unemployment benefits, and I were unemployed, and you weren't, then, I would directly benefit, but you wouldn't. If we were free to choose, I might want the system that provided the maximum unemployment benefits, and you might want the system that provided the minimum. But that wouldn't work, because then the money for running the program would have to come from those who don't have it, while those who do have money wouldn't be contributing it.
To make the program work, it must be mandatory for those who have money to contribute to the program that provides money to those who need it. And that means you need the government, despite its tendency towards inefficiency. It's the difference between having a system that works inefficiently with government involvement, or a system that doesn't work at all. And what makes the former system inefficient is precisely the same thing that makes it work at all: the fact that participation is mandatory.
Long story short: if you can make it work while preserving freedom of choice, do so. It will preserve liberty and be more efficient. But in some cases, the only way to make it work is to take away that freedom. The same people can cry foul over inefficiencies in government and still advocate government programs: we need some government programs, but we still want things to be as efficient as possible.
I agree with you.
There are whole classes of bugs that could right out be eliminated by writing software in safe languages, and using safe APIs. Many of such bugs (buffer overruns, integer overflows, stack smashing, memory leaks, dangling pointers, format string vulnerabilities, SQL injections, predictable filename attacks, ...) end up being featured over and over and over again in vulnerability reports and exploits.
Considering that we have languages and APIs that are safe, efficient, and expressive, all exploits that fall into one of these classes could and should have been avoided. You really need some unsafe constructs to write the kernel of your operating system, but they really have no business being anywhere else. Least of all in applications that can receive arbitrary input from over the network!
Ditch C for application development, and you will be more productive and safer as a result.
It seems to me you are saying that the entire model of HTML and Javascript makes browsers hard to secure, but I don't really see that. Don't HTML and Javascript execute in a pretty well defined sandbox that specifies, basically, you can do this and this and this, and nothing else?
I don't see what about HTML and Javascript makes them especially hard to secure. Compare to, say, Java applets (yes, blast from the past), where you must somehow guard against writing, deleting, or executing arbitrary local files, even though applets have access to APIs for doing that. Or worse, programs containing native code, which have even more tricks up their sleeves and are harder to analyze, too.
On the scale of things, I would say HTML and Javascript aren't anywhere near the top of being hard to secure.
Indeed. Writing a web browser is bloody nasty work. Even the standards are hellish to have to implement, and then there is all that non-standard crap floating around the web that you're supposed to be able to handle. To make things worse, to make your browser usable you must also write pretty performant code. And you have to be able to stand up to the flak you will get if you don't beat the competition on JavaScript benchmarks and Acidn tests, don't have someone's favorite Firefox extension available, or don't run on someone's favorite platform. And even if you work with a team of demi-gods and somehow accomplish all that, your browser will still be susceptible to vulnerabilities in plugins and in libraries that it uses.
Really, I have immense respect for the developers of today's leading web browsers. It's a herculean task, and I know it. Keep it up, fellows!
Unfortunately, it has taken us until now to realize, because they were using ... (wait for it) ... darknets.
``I wouldn't call a company that does R&D and licenses the heck out of its work "King of the Patent Trolls.''
What is ARM's business model again? Are they intellectual property trolls? They certainly seem to be helping to bring a lot of good technology to the world.
``Information economy only works if you have mega army to enforce it.''
Which, of course, is actually the case.
In Soviet Russia, information is controlled by YOU.
In case anyone wasn't convinced already, this shows that security questions are a bad idea. Simply stated, they introduce more points of failure into the system, and it's the weakest one that determines how easy the system is to defeat. In short, you can not make the system more secure by providing another way to gain entry.
Of course, security isn't only about keeping the bad guys out, but also about letting the good guys in. I guess that is what gave rise to security questions: to give you a way to gain entry if you forgot your passphrase. But even then, I don't see security questions as a good solution. I like the established method of "provide what authentication credentials you do have, and we'll send you a new passphrase by a method we agreed on earlier" better.
``Why is it more difficult for proprietary systems?
* MSI based installer
+ if installing from DC based on group policy, don't do anything, or
+ else, allow to install SSL cert + XML service URL for querying of updates. Update check interval is specified and is set 1-14 days.''
I don't know what all that means, but the problems with automatic updates for proprietary software aren't technical, but legal.
The same technical solutions that work for open source (distribution packages the software and provides updates) would work for proprietary software, too - but if the license prohibits redistribution (as many proprietary licenses do), this method wouldn't be allowed.
Speaking of Wikipedia, an idea that has long been in my mind, but that I have never sat down and worked out is distributed hosting of Wikipedia. The idea is that volunteers each contribute some resources (network capacity, storage space, RAM, and CPU cycles) to host and serve part of the content.
This way, we should be able to reduce the load on the (donation supported) Wikimedia servers, as well as increase the redundancy in the system.
Is anybody already working on this or are there perhaps even already implementations of this idea?
You make some very good points in your post.
At the end of it all comes the realization that planning for crisis is complicated, and getting it right is hard. It's also something that every organization I have ever worked with has underestimated considerably. From what little information I have about this incident with Wikimedia (I noticed nothing, myself), they did considerably better than average.
But you are right: the right approach is not to prepare for contingency, but to make recovery part of the normal flow. If failure and recovery are part of the everyday routine, you will know what things are broken before disaster strikes, and when it does, you will be prepared. Nothing will make your organization infallible, but at least you will have procedures, people who know how to execute them, and experience with doing so.
Well, it is a great step forward. And making a system like this work for software that isn't freely redistributable is quite a bit trickier than for open source software. I hope more vendors get with the programme. Even though I don't maintain any Windows systems, I still welcome any development that makes their maintenance less of a burden.
``There are so many reasons that nuclear power technology now available or is on the horizon is bad and so many better alternatives, why are we wasting time on it?''
The same has been said about many of those better alternatives, no doubt. I see things differently. I am happy to see that scientists are researching alternatives to the current ways to produce and deliver energy. I don't care what technology the next round of power plants are based on or who invented that technology, as long as it scores better on the metrics we consider important. Let's discuss what those metrics should be and evaluate new inventions based on those.
Metrics that matter are, for example, pollution generated by the technology, safety, and cost (these should probably be more fine-grained and normalized to badness per MWh). All of the technology alternatives are going to score some points for badness here. However, if a new technology generates less pollution while being at least as safe and at most as expensive as current technology, then it's clearly a step ahead.
I imagine version control would help to identify who contributed what piece of code.
Most version control systems I've used have a 'blame' command (some even have 'praise' as an alias ;-) ) that will show you who contributed each line. Every line that isn't by an author who has agreed to the new license means you have work to do - either get the author's approval, or replace the code.
Just to throw in my two cents, I think that if you are concerned about where the mouse cursor is supposed to be, the scroll bars and the most often used buttons should go on the _left_.
The reason for that is that most of the content that will be in the windows is going to be on the left, including most things you are going to want to interact with.
NeXTSTEP had scrollbars on the left and icons on the edges of the screen, and they decided to do it that way after quite a lot of research and thinking about it.
In practice, of course, people are going to expect things like scroll bars and close buttons to be on the right, so they will balk if you don't put them there. But that doesn't say anything about what would have been the best place to put them if people didn't have preconceived expectations.
Ok, so, since the summary didn't make this clear and I didn't find any explanation in the article, maybe someone on Slashdot can shed some light on this. What took Mozilla so long? It's a critical vulnerability that allows remote code execution. Why did is it taking over a month to fix?
As far as I am concerned, it isn't really a question of fault. Please do not take my earlier post as an attempt to assign blame. It was not intended that way.
Yes. That's all very well, but that doesn't mean customers shouldn't complain. Were I a customer of Microsoft's, I would be less interested in excuses and technical explanations and more interested in what was actually being delivered and what I could do with it.
Besides, it can't be that Microsoft figured this out just now. They deliberately took the decisions to make use of features that they of all people should have known weren't available in Windows XP. In other words, they chose not to support Windows XP. I can very well understand that users of Windows XP would not be happy with that.
The good news is, of course, that nobody actually needs MSIE 9. This leaves Microsoft free to make whatever decision they see fit when implementing it. People who want a modern browser on Windows XP can use any of the several alternatives which are available now: Opera, Safari, Mozilla Firefox, and Chrome are all modern browsers available for Windows XP. And for applications that depend on MSIE-specific features, you can use an earlier version of Windows XP.
Long story short: Microsoft did decide not to support Windows XP. I can see why users of Windows XP would be unhappy about that. But it's not a big problem.
``Admittedly anyone running a *nix based computer would not have had a problem with this malware.''
I can't help but wonder "how long?"
How long until we *nix users start having to bog down our systems in order to slow the flood of malware that would otherwise corrupt them?
They shouldn't have to. Standard procedure _should_ be that only authenticated people have access, and authentication credentials are disabled as soon as a person's contract ends. You trust people who work for you (otherwise, don't let them work for you!), but as soon as they don't work for you anymore, they are outsiders who shouldn't have access.
``The point is that the choice should be mine as a user, and should not be forced onto me by Mozilla by restricting my options.''
Right. And the good news is that, because Firefox is free software, Mozilla cannot restrict your options there. They can decide not to provide you with the capabilities you want out of the box, but they can't prevent you from adding those capabilities.