By the way, Airbus made a similar mistake not that many years ago, which was fixed with extra procedures and software updates.
The key difference between Airbus and Boeing is that Airbus has never relied on a single source of data, while Boeing did. A320 has never affected by unreliable data reading, but the modified version of the algorithm used in A330/A340 contained a bug, which could lead under certain conditions to a pitch-down command due to multiple spikes of incorrect reading from just one of ADIRUs.
We do not know all facts yet, but it looks like Boeing’s decision to base its MCAS system on a single source of data was very reckless, especially after they increased the limit from 0.6 to 2.5 degrees.
Most mental abilities do not decline significantly in otherwise healthy individuals as they age, but multitasking gets more difficult with age. So you need to adjust how you work to reduce interruptions when it's feasible.
Accordingly to the article: "Starting with this version [version 2.3.9], the Apache HTTPD server got an option that would allow server owners to ignore custom security settings made to individual folders via.htaccess files. This setting was made for security reasons, was enabled by default, and remained so for all subsequent Apache HTTPD server releases."
I wonder how many other plugins are silently broken due to this change.
When the “View As” feature was developed, the motto was "Move Fast and Break Things." Should we be surprised that this feature is broken?
Clearly, moving fast is very important for any company that wants to be successful, but if you prioritize speed over security, it is going to catch with you later. Security bugs are different from regular software bugs in that you may never find out about them until serious damage is already done. Therefore the idea "let's move fast and fix a few bugs later" never works well when it comes to security.
The only problem with AMD processors is they don't implement transactional memory operations.
Aside some very specific use cases, transactional memory does not offer much in terms of performance. Moreover, transactional memory helps a lot with Timing Side Channel Attacks against the kernel. For example: https://www.blackhat.com/docs/...
Also you should compare cars under the similar driving conditions. Currently, autopilots refuse to function in difficult road conditions, while human drivers do.
Commercial Unix workstations had a decent desktop for its time, but they were too expensive. Their private hardware was the primary reason of their excessive cost. Still they were not eager to offer their OS for PC, when PC became power enough to run UNIX OSes. Though, there were some commercial UNIX OS for i386 in the early 1990s, they were too expensive for private users. By his own admission, Linus would never write his own OS if he could just buy a commercial Unix OS for a reasonable price.
Linux has been ready for the desktop since about 1999
I use Linux desktop since 1997, and I know people who started to use it before me. However, when it comes to regular people, Ubuntu became the first distro usable by non-technical crowd. (BTW, personally, I still prefer Debian over Ubuntu, but that's another story...)
I'm writing this on Windows but that's only because Windows came on this machine, I'll be installing Linux when I have a week of downtime.
In this regard, my experience is very different than yours. If I had a machine with pre-installed Windows, it would take me a week to install all software that I regularly use, and then I had to change a lot of default settings, which is really annoying. On the other hand, it takes me one day to install a Linux distro from scratch with all required software, and I am ready to go.
In any case, the reason why we don't have more Linux desktops has nothing to do with the Linux kernel. If you want to have a good desktop, having a good kernel does not really matter that much. On the other hand, if you want to build a supercomputer, the kernel is the crucial part of your system.
The working group is actively seeking non-web uses and has not provided DOM integration in the first versions (you must go via JavaScript to touch the DOM).
Emscripten allows to integrate this javascript directly in your C++ code, so touching DOM from C++ is not a real problem.
validating CFI for arbitrary graphs of basic blocks is a solved problem and was a decade ago,
AFAIK, the Java bytecode verificator does not handle some corner cases, and it is so complicated that it may contain security bugs. So I would not say that the problem is solved in general...
but trying to compile a C codebase using goto or some of the more interesting variations on a switch statement into WebAssembly requires O(n^2) algorithms and potentially an O(n^2) increase in bytecode size, which the WebAssembly JIT has to then undo to be able to generate something whose performance doesn't suck.
WebAssembly requires the compiler to do a bit more work, but it makes the verificator much simpler and faster. If practice shows that WebAssembly does not handle switch statements well enough, WebAssembly can be extended in the future to handle it as a special case. I see no reason to support arbitrary graphs.
This sounds an awful lot like browser-based java virtual machine circa 1995.
It only appears so at first glance. WebAssembly is a logical continuation of asm.js, which based on experience of developing of high-performance JavaScript engines. The goal of WebAssembly is to use existing Javascript engines to archive close to C performance within browsers, i.e. something that asm.js already does to lesser degree. In contrast, Java VM was developed to run independently from web browsers, and though you can run it inside a web browser, it's not integrated nearly as well with the browser.
In many ways, WebAssembly is very different than JavaVM. For instance, WebAssembly does not have a GC, while JavaVM relies on it. WebAssembly allows only structured control flow, while you can have an arbitrary control flow in Java. (The restriction on the control flow makes validator for WebAssemply bytecode rather trivial, which helps both with loading speed and security.)
In short, WebAssembly is a VM developed with web browsers in mind, while JavaVM was developed with different priorities.
The idea of AI initiating a pre-emptive strike is B.S. If you want to train AI to do something well, you need a lot of data with known outcome. Usually AI can do better than humans only when they were trained on a much larger set of data than any human can process. So I don't see how you can train AI to make good strategic decisions, because you don't have much data here.
However, AI can contribute to escalation of different proxy-wars. If you send your soldiers abroad, it comes with a heavy political cost at home. Using AI in military can reduce the human cost, which may escalate some regional conflicts supported by different powers, and that may lead to a world war.
The real technical challenge is not how to build a pod that can accelerate to supersonic speed inside the near-vacuum, the real challenge is how to build a very long vacuum tube that would be safe and cost-efficient to operate. So all those hyperloop competitions do nothing to advance the hyperloop idea -- it is just a show for a gullible public.
It is true that Russia places a much greater emphasis on teaching math, physics, and CS than the West. However, it is only possible because of Russian culture puts more value on knowledge of those subjects. Their knowledge means both more social prestige and better prospect of finding a well-paid job.
BTW, many Russians tend to preserve this attitude to math even when they emigrate to the US. As result, their children do better in math on average than American kids. For example, Sergey Brin has never attended any education institution in the Soviet Union, but he was successful in math and CS. Similar, many Asian kids do well in math, because of their parents.
Anyway, Russia has a large pool of young well-educated people, but Russia does not develop as much software as it could given human resources that it has. As result many young people cannot find a legal well-paid job, and some of them get attracted to the dark economy. Usually Russian authorities will not go after them as long as they choose their targets abroad.
But you'd never hear someone say that brain surgery is "fun," or that structural engineering is "easy."
Jeez.. Does the author know anything about programming? Programming is fun, because you don't have to do the same routine over and over again. If you a good programmer, you always write something new, and something innovative, and no one expects you to be perfect each time. As long as you get basic data structures and design right, small mistakes won't matter at the end.
Manic attention to detail is a must
In my experience, good programmers are not those who have the most attention span, but those who know how to write their code in the way that it will be easy to read and verify. Those who often complain that coding requires "manic attention to detail" don't know how to do that properly. It is very common for novices to create ugly overcomplicated solutions, because they don't know how to structure data and code properly, and then they spend enormous amount of time trying to debug that code.
The article starts with a claim "women have higher levels of education than men," which might be true, but it has nothing to do with underrepresentation of women in Information Security. The relevant information would be the percent graduates in computer science. When I googled for that, I found that only 18% of CS graduates were women. (Source: http://www.aauw.org/research/s...). So though there are more women with degrees, most of those degrees have nothing to do with CS.
Then there was a claim that "women make up only 11 percent of the cyber security workforce". I don't know where this number came from. Based on statistics provided by US Department of Labor, there are 18.1 percent of women in Information security analysts. Source: https://www.dol.gov/wb/stats/C...
Where is the link to the original study? The only valuable piece of information in the whole article is: "We do not yet know which came first - the social media use or the perceived social isolation". As to correlation between social isolation and active use of "social media", it is neither new nor particularly surprising.
Google search is not a magic tool to learn the truth. If you feed some nonsense in the algorithm, you should not be to surprise of getting some nonsense back. The Google's Snippets feature says nothing about accuracy of the presented information. So you should not be surprise of getting some nonsense if you search for it. To be able to use Google correctly means being able to validate different online source, and not to rely on what came up in Google search first. What is really surprising is how many university students are incapable to work with online sources and blindly believe in whatever Google says. IMHO, that is a much bigger problem than any imperfection of Google's algorithms.
Rust does not aim to provide you a sandbox to run untrusted code. Its goal is to provide type safety. It means that code written in Rust is as safe as written in Python or in another high-level language, but it runs as fast as if it were written C++.
Obviously, it could be bugs in the Rust compiler or an unsafe library that you use, but the attack surface is much smaller in this way. Take a look at programs written in high-level languages, you do not hear about buffer overflow and other low-level attacks against them very often, though they also rely on some unsafe code and may have implementation bugs.
Most attacks against applications written in high-level languages focus on the application logic. For example, attackers may try to force the application to overwrite some configuration file, which enables them a remote access, or create an executable file, which can be then run remotely, etc.
So for most practical purposes, Rust eliminates certain classes of attacks. This does not mean that applications written in Rust are truly safe, but they are likely to be much safer than written in C/C++.
Apparently, you have never managed any software project for many years. Because if you did, you would realize that people are different, and some far more sensitive to criticism than others. Also a lot depends on the overall culture in your organization. So without any specific context, all those generalizations about what "a wise manager" is supposed to do is UTTER nonsense.
Now if we speak about the Linux kernel, the fact is the success of the Linux kernel is largely due to Linus ability to keep many talented people involved, and he works with same people for many years. So whatever words he chooses to express himself, it does not seem to affect his working relationship with those people. Also I do not remember that he has ever criticized newbies, who are still learning, or anyone like that. Practically, all his harsh words were directed at his lieutenants, who were entrusted to keep the source code to a certain standard, but failed to do so.
Finally, I will never trust you (or anyone else) just because you are willing to work on some stuff. I can trust you only if I know that you can deliver the result that meets certain requirements. I had a developer who tried to be nice and willing to work on almost anything, but his code was nearly always crappy, so giving him nearly any task (aside the most trivial stuff) was completely useless. So we had to part with him. So the question is not what you are willing to do, but what you can deliver in practical terms.
Professional and effective managers always reprimand in private, and praise in public. DON'T work for someone who doesn't follow that rule, life is too short.
First of all, Linus does not do any hiring and does not pay anyone's salaries. So anyone is free to choose whether to work with him or not. Many top developers started to work with him because it's fun, and only later they were able to find a job related to the kernel development.
Second, I do not see anything wrong with public reprimand if the person is clearly wrong, because it is a matter of honesty and trust. This can be a problem only if the person cannot respond to the criticism, because he is afraid to lose his job or something like that. Clearly this is not the case with Linux development. I have never seen Linus harshly criticizing anyone who would be afraid to respond.
The only thing that I do not like is that he uses profanities a bit too much, but if it helps to keep crybabies away then it is not too high price to pay...
No one forced the Greece government to take so much debt. In fact, the Greece government tried to hide how much debt it accumulated until it became impossible to hide.
Now the problem is not just a huge debt that Greece accumulated, but low productivity, aging population, prevailing corruption on all levels. I think investors could agree to some compromises if Greece had any real strategy to repay a substantial part of the debt. The current "balanced" budget comes at enormous social cost, and that is simply unsustainable in the long run. There have not been any real economical reforms that would make Greece more competitive in the world market. So it looks like Greece just wants the old debt to be forgotten, so it can start borrowing again...
It appears that the accident is linked to the use of new fuel and related modification to the engine. Unfortunately, no amount ground testing can guarantee safety in the air. This is true for jet-engines as well. However, a jet-engine failure rarely leads to a deadly outcome for the testing crew. In most cases, the pilot can land the plane safely even with a severely damaged engine. Failure of a rocket-engine leads to a large uncontained explosion with little chance for the crew to survive. In the age of drones, we should not use human beings during such tests.
Any sysadmin who is thinking about it, would put a web server and all it's components in a chroot jail and force it to run in user space and set up to refuse interactive logins for this user.. That way any "escalations" of privilege won't get you much more than the web server. It's easy, quick and effective.
If an attacker find a way to escalate privileges to "root" within the chroot jail, he can take over the whole system. So, a chroot jail does not help much except by limiting the surface of the attack to escalate privilege. For example, you can eliminate all suid programs within the jail environment. However, such manual installation can be difficult to maintain as automatic updates may not work. So, the chroot jail is not any better than properly configured AppArmour or SELinux, which also allows significantly to restrict what the web user can access.
Usually a more secure and simpler solution is to use OpenVZ (or another paravirtualization) to isolate the virtual machine that run the web server.
Linux is BY DEFAULT more secure than Windows, mainly by design.
I am not sure I can fully agree with you here. A lot depends on application installed, the system configuration, and how the system is used, and other things that have nothing to do with design. The only thing where Linux clearly wins is when you want to harden security accordingly to your needs. Linux is far more transparent, so it is easy to configure it properly, while Windows does a lot of things behind your back and some of them may unintentenly can compromise security.
Why would anyone use a new gcc release three months old for critical components?
The bug was introduced in gcc 4.5.0 (which was released in April 2010), so it took 4 years with active use of gcc before kernel developers could pintpoint the cause of some strange kernel crashes.
So how long are we supposed to wait before using a new GCC release?
Slashdot Mirror
By the way, Airbus made a similar mistake not that many years ago, which was fixed with extra procedures and software updates.
The key difference between Airbus and Boeing is that Airbus has never relied on a single source of data, while Boeing did. A320 has never affected by unreliable data reading, but the modified version of the algorithm used in A330/A340 contained a bug, which could lead under certain conditions to a pitch-down command due to multiple spikes of incorrect reading from just one of ADIRUs.
We do not know all facts yet, but it looks like Boeing’s decision to base its MCAS system on a single source of data was very reckless, especially after they increased the limit from 0.6 to 2.5 degrees.
Most mental abilities do not decline significantly in otherwise healthy individuals as they age, but multitasking gets more difficult with age. So you need to adjust how you work to reduce interruptions when it's feasible.
Accordingly to the article: "Starting with this version [version 2.3.9], the Apache HTTPD server got an option that would allow server owners to ignore custom security settings made to individual folders via .htaccess files. This setting was made for security reasons, was enabled by default, and remained so for all subsequent Apache HTTPD server releases."
I wonder how many other plugins are silently broken due to this change.
When the “View As” feature was developed, the motto was "Move Fast and Break Things." Should we be surprised that this feature is broken?
Clearly, moving fast is very important for any company that wants to be successful, but if you prioritize speed over security, it is going to catch with you later. Security bugs are different from regular software bugs in that you may never find out about them until serious damage is already done. Therefore the idea "let's move fast and fix a few bugs later" never works well when it comes to security.
The only problem with AMD processors is they don't implement transactional memory operations.
Aside some very specific use cases, transactional memory does not offer much in terms of performance. Moreover, transactional memory helps a lot with Timing Side Channel Attacks against the kernel. For example: https://www.blackhat.com/docs/...
Also you should compare cars under the similar driving conditions. Currently, autopilots refuse to function in difficult road conditions, while human drivers do.
Consider that 10 years ago:
We were on the 2.4 Linux Kernel (no longer supported with updates)
Linux 2.6 was released in December 2003.
Unix never made inroads on the desktop.
Commercial Unix workstations had a decent desktop for its time, but they were too expensive. Their private hardware was the primary reason of their excessive cost. Still they were not eager to offer their OS for PC, when PC became power enough to run UNIX OSes. Though, there were some commercial UNIX OS for i386 in the early 1990s, they were too expensive for private users. By his own admission, Linus would never write his own OS if he could just buy a commercial Unix OS for a reasonable price.
Linux has been ready for the desktop since about 1999
I use Linux desktop since 1997, and I know people who started to use it before me. However, when it comes to regular people, Ubuntu became the first distro usable by non-technical crowd. (BTW, personally, I still prefer Debian over Ubuntu, but that's another story...)
I'm writing this on Windows but that's only because Windows came on this machine, I'll be installing Linux when I have a week of downtime.
In this regard, my experience is very different than yours. If I had a machine with pre-installed Windows, it would take me a week to install all software that I regularly use, and then I had to change a lot of default settings, which is really annoying. On the other hand, it takes me one day to install a Linux distro from scratch with all required software, and I am ready to go.
In any case, the reason why we don't have more Linux desktops has nothing to do with the Linux kernel. If you want to have a good desktop, having a good kernel does not really matter that much. On the other hand, if you want to build a supercomputer, the kernel is the crucial part of your system.
The working group is actively seeking non-web uses and has not provided DOM integration in the first versions (you must go via JavaScript to touch the DOM).
Emscripten allows to integrate this javascript directly in your C++ code, so touching DOM from C++ is not a real problem.
validating CFI for arbitrary graphs of basic blocks is a solved problem and was a decade ago,
AFAIK, the Java bytecode verificator does not handle some corner cases, and it is so complicated that it may contain security bugs. So I would not say that the problem is solved in general...
but trying to compile a C codebase using goto or some of the more interesting variations on a switch statement into WebAssembly requires O(n^2) algorithms and potentially an O(n^2) increase in bytecode size, which the WebAssembly JIT has to then undo to be able to generate something whose performance doesn't suck.
WebAssembly requires the compiler to do a bit more work, but it makes the verificator much simpler and faster. If practice shows that WebAssembly does not handle switch statements well enough, WebAssembly can be extended in the future to handle it as a special case. I see no reason to support arbitrary graphs.
It only appears so at first glance. WebAssembly is a logical continuation of asm.js, which based on experience of developing of high-performance JavaScript engines. The goal of WebAssembly is to use existing Javascript engines to archive close to C performance within browsers, i.e. something that asm.js already does to lesser degree. In contrast, Java VM was developed to run independently from web browsers, and though you can run it inside a web browser, it's not integrated nearly as well with the browser.
In many ways, WebAssembly is very different than JavaVM. For instance, WebAssembly does not have a GC, while JavaVM relies on it. WebAssembly allows only structured control flow, while you can have an arbitrary control flow in Java. (The restriction on the control flow makes validator for WebAssemply bytecode rather trivial, which helps both with loading speed and security.)
In short, WebAssembly is a VM developed with web browsers in mind, while JavaVM was developed with different priorities.
The idea of AI initiating a pre-emptive strike is B.S. If you want to train AI to do something well, you need a lot of data with known outcome. Usually AI can do better than humans only when they were trained on a much larger set of data than any human can process. So I don't see how you can train AI to make good strategic decisions, because you don't have much data here.
However, AI can contribute to escalation of different proxy-wars. If you send your soldiers abroad, it comes with a heavy political cost at home. Using AI in military can reduce the human cost, which may escalate some regional conflicts supported by different powers, and that may lead to a world war.
The real technical challenge is not how to build a pod that can accelerate to supersonic speed inside the near-vacuum, the real challenge is how to build a very long vacuum tube that would be safe and cost-efficient to operate. So all those hyperloop competitions do nothing to advance the hyperloop idea -- it is just a show for a gullible public.
It is true that Russia places a much greater emphasis on teaching math, physics, and CS than the West. However, it is only possible because of Russian culture puts more value on knowledge of those subjects. Their knowledge means both more social prestige and better prospect of finding a well-paid job.
BTW, many Russians tend to preserve this attitude to math even when they emigrate to the US. As result, their children do better in math on average than American kids. For example, Sergey Brin has never attended any education institution in the Soviet Union, but he was successful in math and CS. Similar, many Asian kids do well in math, because of their parents.
Anyway, Russia has a large pool of young well-educated people, but Russia does not develop as much software as it could given human resources that it has. As result many young people cannot find a legal well-paid job, and some of them get attracted to the dark economy. Usually Russian authorities will not go after them as long as they choose their targets abroad.
Jeez.. Does the author know anything about programming? Programming is fun, because you don't have to do the same routine over and over again. If you a good programmer, you always write something new, and something innovative, and no one expects you to be perfect each time. As long as you get basic data structures and design right, small mistakes won't matter at the end.
In my experience, good programmers are not those who have the most attention span, but those who know how to write their code in the way that it will be easy to read and verify. Those who often complain that coding requires "manic attention to detail" don't know how to do that properly. It is very common for novices to create ugly overcomplicated solutions, because they don't know how to structure data and code properly, and then they spend enormous amount of time trying to debug that code.
The article starts with a claim "women have higher levels of education than men," which might be true, but it has nothing to do with underrepresentation of women in Information Security. The relevant information would be the percent graduates in computer science. When I googled for that, I found that only 18% of CS graduates were women. (Source: http://www.aauw.org/research/s...). So though there are more women with degrees, most of those degrees have nothing to do with CS.
Then there was a claim that "women make up only 11 percent of the cyber security workforce". I don't know where this number came from. Based on statistics provided by US Department of Labor, there are 18.1 percent of women in Information security analysts. Source: https://www.dol.gov/wb/stats/C...
Where is the link to the original study? The only valuable piece of information in the whole article is: "We do not yet know which came first - the social media use or the perceived social isolation". As to correlation between social isolation and active use of "social media", it is neither new nor particularly surprising.
Google search is not a magic tool to learn the truth. If you feed some nonsense in the algorithm, you should not be to surprise of getting some nonsense back. The Google's Snippets feature says nothing about accuracy of the presented information. So you should not be surprise of getting some nonsense if you search for it. To be able to use Google correctly means being able to validate different online source, and not to rely on what came up in Google search first. What is really surprising is how many university students are incapable to work with online sources and blindly believe in whatever Google says. IMHO, that is a much bigger problem than any imperfection of Google's algorithms.
Rust does not aim to provide you a sandbox to run untrusted code. Its goal is to provide type safety. It means that code written in Rust is as safe as written in Python or in another high-level language, but it runs as fast as if it were written C++.
Obviously, it could be bugs in the Rust compiler or an unsafe library that you use, but the attack surface is much smaller in this way. Take a look at programs written in high-level languages, you do not hear about buffer overflow and other low-level attacks against them very often, though they also rely on some unsafe code and may have implementation bugs.
Most attacks against applications written in high-level languages focus on the application logic. For example, attackers may try to force the application to overwrite some configuration file, which enables them a remote access, or create an executable file, which can be then run remotely, etc.
So for most practical purposes, Rust eliminates certain classes of attacks. This does not mean that applications written in Rust are truly safe, but they are likely to be much safer than written in C/C++.
Apparently, you have never managed any software project for many years. Because if you did, you would realize that people are different, and some far more sensitive to criticism than others. Also a lot depends on the overall culture in your organization. So without any specific context, all those generalizations about what "a wise manager" is supposed to do is UTTER nonsense.
Now if we speak about the Linux kernel, the fact is the success of the Linux kernel is largely due to Linus ability to keep many talented people involved, and he works with same people for many years. So whatever words he chooses to express himself, it does not seem to affect his working relationship with those people. Also I do not remember that he has ever criticized newbies, who are still learning, or anyone like that. Practically, all his harsh words were directed at his lieutenants, who were entrusted to keep the source code to a certain standard, but failed to do so.
Finally, I will never trust you (or anyone else) just because you are willing to work on some stuff. I can trust you only if I know that you can deliver the result that meets certain requirements. I had a developer who tried to be nice and willing to work on almost anything, but his code was nearly always crappy, so giving him nearly any task (aside the most trivial stuff) was completely useless. So we had to part with him. So the question is not what you are willing to do, but what you can deliver in practical terms.
Professional and effective managers always reprimand in private, and praise in public. DON'T work for someone who doesn't follow that rule, life is too short.
First of all, Linus does not do any hiring and does not pay anyone's salaries. So anyone is free to choose whether to work with him or not. Many top developers started to work with him because it's fun, and only later they were able to find a job related to the kernel development.
Second, I do not see anything wrong with public reprimand if the person is clearly wrong, because it is a matter of honesty and trust. This can be a problem only if the person cannot respond to the criticism, because he is afraid to lose his job or something like that. Clearly this is not the case with Linux development. I have never seen Linus harshly criticizing anyone who would be afraid to respond.
The only thing that I do not like is that he uses profanities a bit too much, but if it helps to keep crybabies away then it is not too high price to pay...
say "Auf Flugenhafen Bitte", your American accent will give you away
Maybe, because it should be "Zum Flughafen bitte."
No one forced the Greece government to take so much debt. In fact, the Greece government tried to hide how much debt it accumulated until it became impossible to hide.
Now the problem is not just a huge debt that Greece accumulated, but low productivity, aging population, prevailing corruption on all levels. I think investors could agree to some compromises if Greece had any real strategy to repay a substantial part of the debt. The current "balanced" budget comes at enormous social cost, and that is simply unsustainable in the long run. There have not been any real economical reforms that would make Greece more competitive in the world market. So it looks like Greece just wants the old debt to be forgotten, so it can start borrowing again...
It appears that the accident is linked to the use of new fuel and related modification to the engine. Unfortunately, no amount ground testing can guarantee safety in the air. This is true for jet-engines as well. However, a jet-engine failure rarely leads to a deadly outcome for the testing crew. In most cases, the pilot can land the plane safely even with a severely damaged engine. Failure of a rocket-engine leads to a large uncontained explosion with little chance for the crew to survive. In the age of drones, we should not use human beings during such tests.
Any sysadmin who is thinking about it, would put a web server and all it's components in a chroot jail and force it to run in user space and set up to refuse interactive logins for this user.. That way any "escalations" of privilege won't get you much more than the web server. It's easy, quick and effective.
If an attacker find a way to escalate privileges to "root" within the chroot jail, he can take over the whole system. So, a chroot jail does not help much except by limiting the surface of the attack to escalate privilege. For example, you can eliminate all suid programs within the jail environment. However, such manual installation can be difficult to maintain as automatic updates may not work. So, the chroot jail is not any better than properly configured AppArmour or SELinux, which also allows significantly to restrict what the web user can access.
Usually a more secure and simpler solution is to use OpenVZ (or another paravirtualization) to isolate the virtual machine that run the web server.
Linux is BY DEFAULT more secure than Windows, mainly by design.
I am not sure I can fully agree with you here. A lot depends on application installed, the system configuration, and how the system is used, and other things that have nothing to do with design. The only thing where Linux clearly wins is when you want to harden security accordingly to your needs. Linux is far more transparent, so it is easy to configure it properly, while Windows does a lot of things behind your back and some of them may unintentenly can compromise security.
Why would anyone use a new gcc release three months old for critical components?
The bug was introduced in gcc 4.5.0 (which was released in April 2010), so it took 4 years with active use of gcc before kernel developers could pintpoint the cause of some strange kernel crashes.
So how long are we supposed to wait before using a new GCC release?