Ugh. I don't denigrate the talent and effort that went into C++/CLI -- it is a valiant (and largely successful) effort to integrate the CLI programming model into C++. But it buys little expressive power over C#, at the cost of a much more complex syntax. Unless you're a language fanatic or are looking to create a CLI interface to unmanaged C++, you'd be best off avoiding it entirely in favor of C#.
As others have mentioned, this is a proprietary OS that supports the Linux ABI, not any version of Linux.
I've developed and shipped software certified to DO-178B level A on a likewise certified OS (on two different aircraft), and I can state categorically that no widely-used general purpose OS will ever be certified to that level. The requirements are just way too stringent to apply to anything that wasn't developed from the ground up with the intent of achieving certification. For level A software for example, you need (among many other things):
Traceability: Written system-level requirements that provably map to the code and vice-versa. No requirements can be unimplemented and all code must support at least one requirement. This must be proven by inspection, possibly with the assistance of automated tools.
Code Coverage: Proof of Modified Condition Decision Coverage, where test cases must cover every decision point in the program, plus each of the two possible states for every boolean condition within every decision.
Reviewed Changes: Every change to a requirement document or the source code must be reviewed and signed off on, usually by multiple individuals.
Documentation: not only for all your system and software level requirements, but for every review performed on changes to those requirements or the source code.
This week's Linux Weekly News had an article on MythTV that also covered Knoppmyth. Apparently it's not as easy as it seems (or at least the LWN editor didn't find it so).
President George Washington: "It is impossible to rightly govern the world without God and the Bible."
...
President James Madison
"We've staked the whole future of American civilization not on the power of government, far from it. We have staked the future of all our political institutions upon the capacity of each and all of us . . . to Govern ourselves according to the commandments of God. The future and success of America is not in this Constitution, but in the laws of God upon which this Constitution is founded."
You're not off to a very good start, considering that the above quotes are fake.
So this is a system failure, but the system is the 'process,' and not the physical components. I assume the aviation industry has things to prevent this. we follow that industry when we can, but our profit margin is extremely tight.
I can't speak to the requirements for hardware, but for software, there is a requirement that the control coupling and data coupling between components is confirmed. That assumedly would prevent the analogous situation from occurring in software.
Re:LinuxBIOS in flight computers
on
In-Flight Reboot?
·
· Score: 2, Informative
AFAIK, civilian flight systems are three times redundant. Written by three different isolated teams in three different programming paradigms, from three different cultures to avoid similar faults due to "contamination" by other teams, or simlar faults due to similar paradigms. (Airbus 340 (3M LOC), Boeing 777 are said to have employed such techniques)
Not necessarily true. To certify software systems using the currently accepted civilian standards for software development (DO-178B), you need to show through analysis that the failure rate of the entire system is below some threshold. One way to attain that threshold is to use multiple, redundant systems that have a higher-than-threshold failure rate, such that the combined failure rate is below the threshold. There is no requirement to use redundancy; it just happens to be an effective way to meet the failure threshold.
I have developed avionics software for business jets and I can tell you that the system on which I worked was designed to be only two-times redundant, and it was redudant with another instance of itself, not a wholly independent system. That level of redundancy was sufficient to meet the required failure threshold.
I used to work on avionics software and one of the biggest beefs of our main liason to the regulatory agencies was that there is currently no approved standard for generating system requirements. As a result there is no agreed-upon method for dealing with this single point of failure. In contrast, there is a well-defined and approved standard for software development: DO-178B.
This individual claimed that most of the mishaps she was aware of that were attributed to software were in fact due to faulty system requirements, and I have no reason to doubt her. Unfortunately I don't remember any specific cases that she cited.
How about a real-life example of how the ease of using Visual Basic for viruses and worms has affected internal application development where I work?
As an employee at a large aerospace company, I'm part of a group that writes code on Windows for an embedded application. Our group has been using VB scripts to automate our build process for quite a while. Just recently, our IT group has decided that the risk of virus/worm infection from VB scripts is so high that they have enabled blocking of all.VBS files. This has caused us significant pain since now we have to change all of our.VBS extensions and redo our build scripts so that the scripts are interpreted properly. In effect, we've lost some of the ease-of-use that VB scripts are supposed to provide.
Before you argue that this policy is stupid, useless, invalid, etc., realize that it fundamentally doesn't matter. There's enough perceived risk of virus and worm infection that reasonable people are concluding that allowing easy execution of VB scripts is simply not worth it. The IT department at the company I work for is not any more fascist or ignorant than most other companies (in fact, I've heard the head of IT give a talk on information security and he knows his stuff), so I suspect this is not an isolated example.
I agree with Bruce that the East Bay is a great place to live if you are also working there, but if you intend to commute to Silicon Valley, SF, or some locations in the East Bay, it could be a major pain. The commuter train, BART, is great if your home and work are reasonably close to stations (I take it daily from El Cerrito to Berkeley). However, if you have to drive I-80 through Berkeley and Emeryville (the maze) you're going to be in a world of pain. I believe that stretch of highway is the most congested in the Bay Area; traffic is often backed up there for at least a mile even during non-commute hours.
Also, although the housing market in the East Bay isn't as bad as in Silicon Valley, it is getting increasingly expensive. For reference, the rent for my fairly nice one bedroom apt. in El Cerrito was $650/mo when I moved in three years ago. That was a little below market value at the time. Now my rent is going up to $990/mo, which is right about current market value. And if you want to live in Berkeley, places are even harder to find and more expensive. If you're looking to buy, you're going to be in the same boat. The couple that lives next door to me have been looking to buy for at least a year now and haven't found anything that is decent and cheap enough for them. They both have good paying jobs, so it's not like they are scraping to get by either.
I'm hoping that the downturn in home sales that Bruce referred to elsewhere will cool off the market a little bit. If it doesn't, I wouldn't be surprised to see the housing market here rivaling the one in Silicon Valley in a few years.
In 1997, cars killed 102197 people. Guns killed 32436 people. (Sources: FARS, CDC) Cars are three times more lethal than guns. And guns were designed to kill things! That tells you something.
It sure does; it tells me that we're not doing nearly enough to reduce the number of gun deaths. Since cars are used much, much, more often than guns (I'm sure more than three times as often, although I don't have the data to prove it), then guns must be more deadly on a per use basis.
But regardless, we can definitely say that guns are within an order of magnitude as deadly as cars, yet we don't even attempt to ensure gun purchasers can safely operate their guns. To do so would require only the most minimal "meddling," but would surely help reduce the number of gun deaths. Let's face it; there are stupid, irresponsible, and ignorant people out there (not to mention crackpots). If they're going to have a weapon, they should at least have to prove they can use it safely.
So the creators of the constitution has so little faith in their own document that they needed to provide a means within that very document to invalidate it? If that's the case then it must be a pretty poor basis for government.
For the sake of argument, let's suppose the federal government did become tyrannical. Then by definition it would not be respecting the constitution, including the second amendment. So whatever rights you had would be moot in just the case where you would need them!
That's why states require that car owners are properly aware of how to safely operate their cars, through written and practical (i.e. driving) tests. That's a hell of a lot more than you can say for gun owners!
On the NewsHour with Jim Lehrer (an excellent news source for those not familiar with it), there was an excellent debate on gun control tonight in the context of the Million Mom March.
Many of the people against gun control seem to be hell-bent on portraying anyone supporting any kind of gun control as wanting to ban all weapons. But what the woman supporting gun control on the program proposed was not a ban of all (or any) firearms, but what seemed to me to be a reasonable approach (via registration and licensing) to try to keep guns out of the hands of criminals and those who are not able to use them safely. There are enough nutcases and irresponsible people out there; shouldn't it be possible to do something to prevent them from getting their hands on firearms, even if it makes it a bit more difficult for legitimate firearms buyers to acquire weapons?
First, I agree that if users were smarter and knew not to open attachments like this, there wouldn't be a problem. However blaming stupid users does absolutely nothing to solve the problem. Whether you like it or not, naive users exist and are (presumably) the vast majority of Outlook users. Trying to educate them about (in their view) esoteric problems with attachments is not going to work, because fundamentally they're not going to care until after a virus bites them, by which time it is too late. This is just human nature.
When you combine this attitude with the relative ease with which naive users can cause a virus to propagate, it makes it trivially easy for viruses like ILOVEYOU to spread. Arguments about whether the same thing can be done on operating system X are pointless; at a fundamental level something like ILOVEYOU could be propagated by any email client that can save or execute attachments. The relevant issue is the number and difficulty of the steps that the naive user must take to propagate the virus. In the case of Outlook, it's a simple double click!
Given that Microsoft should have known that their email clients would be used largely by naive users, they should have set the default security to a level where it would be difficult for those users to propagate a virus. Then more advanced users could lower the security, and everyone would be happy. Since they didn't do this, they should share a large part of the blame for the severity of and damage caused by the virus.
Ehh I don't know that you could make it *that* much worse than what we've seen so far.
I'm certain that things can (and will) be worse than ILOVEYOU in the future. In terms of propagation, if someone was able to exploit a true security hole in Outlook, so that simply viewing the message caused it to be resent, it would be everywhere virtually instantaneously. Barring that, the worm could reply to the user's saved mail messages with the original subject, or use a random subject to make it less easy for naive users to identify as a worm.
In terms of payload, I can think of a number of ways in which a worm could be more damaging. Sending a randomly chosen word document on the hard drive along with/in addition to the worm would be particularly devastating because it would expose trade secrets and other information that a person or company would not want exposed (didn't this happen somewhat with Melissa or Explore.zip?). Perhaps the worst thing that a worm could do to a host system (at least in terms of identification of damage and cleanup) would be to periodically flip random bits in randomly chosen files on the hard drive or network drives. If that were to happen, it would be difficult or impossible to tell which files had been affected. Another thing that could be done is to install a backdoor like BackOrifice, although it would take some skill to figure out a way to do that without having to download it from a central source that could be shut down (maybe download it from the trojaned victim who sent the worm?).
I'm firmly convinced that the worst is yet to come...
this morning on the front page of the business section was this article, detailing how Napster and GNUtella are outstripping the music and movie industries' abilities to stop people from sharing content. It also talks about diVX (not the defunct DVD player) which appears to encode a VCD from the contents of a DVD.
But we haven't been borrowing money only from ourselves. 38% of the national debt is owed to foreign interests. And did you realize that the federal government is paying $364 billion/year (as of 1998) for interest on the debt? That's more than 10% of the national budget, and it could be returned to taxpayers every year if we were to pay off the debt. Besides, the sheer size of the debt keeps interest rates artificially high, making it more expensive for people with mortgages and credit card balances.
This site has some other very interesting and useful information on the debt.
My expectations of how funny the show should be haven't changed; it's the show that's changing, and changing significantly for the worse. When I watch the syndicated episodes, they are consistently funny, whereas this season's episodes are just terrible. I think I laughed a grand total of three times while watching the last two episodes.
The problem seems to be that the writers are emphasizing cheap gags at the expense of intelligent humor and consistent characterization. When Ned Flanders can give up God and then go back in the span of two minutes, something is seriously wrong. In the space of one episode, the writers destroyed a character that had been consistently defined in the 10 years of episodes leading up to now. And for what point?
The writers seem to have lost all sense of subtlety as well; someone should let them know that meta humor is not funny when you hit the audience over the head with it (e.g. "this episode written by Ian Maxtone-Graham"). As much as I hate to say it, the show is degenerating into the type of material that the Simpsons used to make fun of. And that is just sad.
I agree completely. I think the writers have gotten lazy and are just relying on the stereotypical interactions of the characters, instead of actually trying to do something new. That, in combination with the one-liners, is driving the show dangerously close to lame sitcom (what other kind is there?) type humor.
I recall in particular an episode this season where Homer did something Homerish, and Bart shrugged in and "eh, what are you going to do?" kind of way. This is the exact type of sitcom-type interaction that the Simpsons made fun of in the past, and now they're doing it themselves! Aaaargh!
Science (and evolution) is an attempt to explain the evidence irrespective of a diety. To be absolutely clear: science takes no position on the existence of a diety. Science deals in things that are testable and falsifiable, and the existence of a diety is neither. I am sooooo tired of seeing this assertion that science denies the existence of a deity.
Furthermore, evolution is a falsifiable theory and is thus not "just as much religion as creationism". Creationism rests on untestable beliefs (i.e. religion); evolution does not.
"we can't put God in a lab and run him through experiments so we aren't even going to deal with the question of his existence".
Essentially true. Science deals in hypotheses and theories that are falsifiable. As you said, it is not possible to demonstrate the existence or non-existence of God. Thus any position on the existence of God is not falsifiable and therefore is not in the domain of science.
You seem to be missing the distinction between professing no belief on a topic and professing disbelief. There are certainly a large number of scientists who do believe in God, but (ideally) they do not incorporate that belief into their work because it is not testable.
Not quite. The number of misleading and downright false statements in the piece is staggering. Off the top of my head:
Windows NT 4.0 Outperforms Linux On Common Customer Workloads The numbers cited are from the Mindcraft benchmark, which is far from a common customer workload.
They compared NT only to Linux/x86, when Linux/Alpha is better in some categories. Also, the assertion that Linux/x86 is limited to 128MB swap is false.
Some Microsoft OEMs guarantee 99.9% uptime, but that's still 11 minutes a week of downtime.
They cite a TCO study for a completely different operating system.
The very definition of Linux as an Open Software effort means that commercial companies like Red Hat will make money by charging for services. Therefore, commercial support services for Linux will be fee-based and will likely be priced at a premium. These costs have to be factored into the total cost model. They neglect to mention that there is competition among support companies, which will drive down the cost.
Linux security is all-or-nothing. This is false. sudo allows one to delegate root privileges.
C2 accreditation: this is only applicable for an NT box not on a network.
Linux system administrators must spend huge amounts of time understanding the latest Linux bugs and determining what to do about them. This is made complex due to the fact that there isn't a central location for security issues to be reported and fixed. This is false. Can you say http://www.redhat.com/errata? (and similar for other distributions)
Slashdot Mirror
Ugh. I don't denigrate the talent and effort that went into C++/CLI -- it is a valiant (and largely successful) effort to integrate the CLI programming model into C++. But it buys little expressive power over C#, at the cost of a much more complex syntax. Unless you're a language fanatic or are looking to create a CLI interface to unmanaged C++, you'd be best off avoiding it entirely in favor of C#.
I've developed and shipped software certified to DO-178B level A on a likewise certified OS (on two different aircraft), and I can state categorically that no widely-used general purpose OS will ever be certified to that level. The requirements are just way too stringent to apply to anything that wasn't developed from the ground up with the intent of achieving certification. For level A software for example, you need (among many other things):
This week's Linux Weekly News had an article on MythTV that also covered Knoppmyth. Apparently it's not as easy as it seems (or at least the LWN editor didn't find it so).
You're not off to a very good start, considering that the above quotes are fake.
You might be able to make your case better if you didn't use fraudulent quotes.
I can't speak to the requirements for hardware, but for software, there is a requirement that the control coupling and data coupling between components is confirmed. That assumedly would prevent the analogous situation from occurring in software.
Not necessarily true. To certify software systems using the currently accepted civilian standards for software development (DO-178B), you need to show through analysis that the failure rate of the entire system is below some threshold. One way to attain that threshold is to use multiple, redundant systems that have a higher-than-threshold failure rate, such that the combined failure rate is below the threshold. There is no requirement to use redundancy; it just happens to be an effective way to meet the failure threshold.
I have developed avionics software for business jets and I can tell you that the system on which I worked was designed to be only two-times redundant, and it was redudant with another instance of itself, not a wholly independent system. That level of redundancy was sufficient to meet the required failure threshold.
I used to work on avionics software and one of the biggest beefs of our main liason to the regulatory agencies was that there is currently no approved standard for generating system requirements. As a result there is no agreed-upon method for dealing with this single point of failure. In contrast, there is a well-defined and approved standard for software development: DO-178B.
This individual claimed that most of the mishaps she was aware of that were attributed to software were in fact due to faulty system requirements, and I have no reason to doubt her. Unfortunately I don't remember any specific cases that she cited.
As an employee at a large aerospace company, I'm part of a group that writes code on Windows for an embedded application. Our group has been using VB scripts to automate our build process for quite a while. Just recently, our IT group has decided that the risk of virus/worm infection from VB scripts is so high that they have enabled blocking of all .VBS files. This has caused us significant pain since now we have to change all of our .VBS extensions and redo our build scripts so that the scripts are interpreted properly. In effect, we've lost some of the ease-of-use that VB scripts are supposed to provide.
Before you argue that this policy is stupid, useless, invalid, etc., realize that it fundamentally doesn't matter. There's enough perceived risk of virus and worm infection that reasonable people are concluding that allowing easy execution of VB scripts is simply not worth it. The IT department at the company I work for is not any more fascist or ignorant than most other companies (in fact, I've heard the head of IT give a talk on information security and he knows his stuff), so I suspect this is not an isolated example.
Also, although the housing market in the East Bay isn't as bad as in Silicon Valley, it is getting increasingly expensive. For reference, the rent for my fairly nice one bedroom apt. in El Cerrito was $650/mo when I moved in three years ago. That was a little below market value at the time. Now my rent is going up to $990/mo, which is right about current market value. And if you want to live in Berkeley, places are even harder to find and more expensive. If you're looking to buy, you're going to be in the same boat. The couple that lives next door to me have been looking to buy for at least a year now and haven't found anything that is decent and cheap enough for them. They both have good paying jobs, so it's not like they are scraping to get by either.
I'm hoping that the downturn in home sales that Bruce referred to elsewhere will cool off the market a little bit. If it doesn't, I wouldn't be surprised to see the housing market here rivaling the one in Silicon Valley in a few years.
It sure does; it tells me that we're not doing nearly enough to reduce the number of gun deaths. Since cars are used much, much, more often than guns (I'm sure more than three times as often, although I don't have the data to prove it), then guns must be more deadly on a per use basis.
But regardless, we can definitely say that guns are within an order of magnitude as deadly as cars, yet we don't even attempt to ensure gun purchasers can safely operate their guns. To do so would require only the most minimal "meddling," but would surely help reduce the number of gun deaths. Let's face it; there are stupid, irresponsible, and ignorant people out there (not to mention crackpots). If they're going to have a weapon, they should at least have to prove they can use it safely.
For the sake of argument, let's suppose the federal government did become tyrannical. Then by definition it would not be respecting the constitution, including the second amendment. So whatever rights you had would be moot in just the case where you would need them!
That's why states require that car owners are properly aware of how to safely operate their cars, through written and practical (i.e. driving) tests. That's a hell of a lot more than you can say for gun owners!
Many of the people against gun control seem to be hell-bent on portraying anyone supporting any kind of gun control as wanting to ban all weapons. But what the woman supporting gun control on the program proposed was not a ban of all (or any) firearms, but what seemed to me to be a reasonable approach (via registration and licensing) to try to keep guns out of the hands of criminals and those who are not able to use them safely. There are enough nutcases and irresponsible people out there; shouldn't it be possible to do something to prevent them from getting their hands on firearms, even if it makes it a bit more difficult for legitimate firearms buyers to acquire weapons?
When you combine this attitude with the relative ease with which naive users can cause a virus to propagate, it makes it trivially easy for viruses like ILOVEYOU to spread. Arguments about whether the same thing can be done on operating system X are pointless; at a fundamental level something like ILOVEYOU could be propagated by any email client that can save or execute attachments. The relevant issue is the number and difficulty of the steps that the naive user must take to propagate the virus. In the case of Outlook, it's a simple double click!
Given that Microsoft should have known that their email clients would be used largely by naive users, they should have set the default security to a level where it would be difficult for those users to propagate a virus. Then more advanced users could lower the security, and everyone would be happy. Since they didn't do this, they should share a large part of the blame for the severity of and damage caused by the virus.
I'm certain that things can (and will) be worse than ILOVEYOU in the future. In terms of propagation, if someone was able to exploit a true security hole in Outlook, so that simply viewing the message caused it to be resent, it would be everywhere virtually instantaneously. Barring that, the worm could reply to the user's saved mail messages with the original subject, or use a random subject to make it less easy for naive users to identify as a worm.
In terms of payload, I can think of a number of ways in which a worm could be more damaging. Sending a randomly chosen word document on the hard drive along with/in addition to the worm would be particularly devastating because it would expose trade secrets and other information that a person or company would not want exposed (didn't this happen somewhat with Melissa or Explore.zip?). Perhaps the worst thing that a worm could do to a host system (at least in terms of identification of damage and cleanup) would be to periodically flip random bits in randomly chosen files on the hard drive or network drives. If that were to happen, it would be difficult or impossible to tell which files had been affected. Another thing that could be done is to install a backdoor like BackOrifice, although it would take some skill to figure out a way to do that without having to download it from a central source that could be shut down (maybe download it from the trojaned victim who sent the worm?).
I'm firmly convinced that the worst is yet to come...
this morning on the front page of the business section was this article, detailing how Napster and GNUtella are outstripping the music and movie industries' abilities to stop people from sharing content. It also talks about diVX (not the defunct DVD player) which appears to encode a VCD from the contents of a DVD.
Tell it to the Supreme Court. It has long been recognized that commercial speech is subject to greater restriction than non-commercial speech.
This site has some other very interesting and useful information on the debt.
The problem seems to be that the writers are emphasizing cheap gags at the expense of intelligent humor and consistent characterization. When Ned Flanders can give up God and then go back in the span of two minutes, something is seriously wrong. In the space of one episode, the writers destroyed a character that had been consistently defined in the 10 years of episodes leading up to now. And for what point?
The writers seem to have lost all sense of subtlety as well; someone should let them know that meta humor is not funny when you hit the audience over the head with it (e.g. "this episode written by Ian Maxtone-Graham"). As much as I hate to say it, the show is degenerating into the type of material that the Simpsons used to make fun of. And that is just sad.
I recall in particular an episode this season where Homer did something Homerish, and Bart shrugged in and "eh, what are you going to do?" kind of way. This is the exact type of sitcom-type interaction that the Simpsons made fun of in the past, and now they're doing it themselves! Aaaargh!
Georgia isn't the only state with asinine sodomy laws either; see this page for other states.
Furthermore, evolution is a falsifiable theory and is thus not "just as much religion as creationism". Creationism rests on untestable beliefs (i.e. religion); evolution does not.
Essentially true. Science deals in hypotheses and theories that are falsifiable. As you said, it is not possible to demonstrate the existence or non-existence of God. Thus any position on the existence of God is not falsifiable and therefore is not in the domain of science.
You seem to be missing the distinction between professing no belief on a topic and professing disbelief. There are certainly a large number of scientists who do believe in God, but (ideally) they do not incorporate that belief into their work because it is not testable.
Not quite. The number of misleading and downright false statements in the piece is staggering. Off the top of my head:
The numbers cited are from the Mindcraft benchmark, which is far from a common customer workload.
They neglect to mention that there is competition among support companies, which will drive down the cost.
This is false. sudo allows one to delegate root privileges.
This is false. Can you say http://www.redhat.com/errata? (and similar for other distributions)