Analogies have their limits, so we shouldn't try to take it too far.
Even those who historically have critized "security through obscurity" never suggested that publishing their design or secrets would lead to better security, but rather that you can't assume your that your design can't be cracked.
Of course, the preferred approach is "security through design" which has nothing to do with correcting bugs. The latter could be called "security through maintenence". Thus while we might argue about whether closed or open source produces better design, examining source code for bugs can't compensate for a design that is insecure.
I think your logic is a bit confused. The fact that viruses can be created without reading the source code does not prove that there's no value in keeping the code secret. It's like arguing that there's no point in locking your door because 100,000 houses with locks were broken into.
That's a nice idealistic attitude, but I disagree. Today a university is a very costly and inefficient way to learn if your goal is purely the pursuit of knowledge.
In addition, the university's "prime directive" is not to teach students. Surely, the courses that each student has to take to graduate don't all correspond to each student's educational goals. Being "well-rounded" is defined in terms of what the university needs, not what the student needs. If a particular school wants to specialize in a particular obscure subject area, it will require uninterested students to take courses in that area in order to justify the expense of teaching it.
I suggest that anyone who thinks its just about learning, take your university qualifications off your resume and see what happens.
The subject matter that should be taught for a partiular major changes over time. I went to university before Unix and C were dominant and spent a considerable time doing assembly language coding. The value of that experience diminishes every day.
It's natual for those who spent a lot of time and effort learning (or teaching) now semi-obsolete material to overstate its importance today.
Essentially these guys have a problem because they chose to use Ada - a language that was created for and mandated (briefly) by the government and rejected by the market. If you use a niche language, you're going to have trouble finding people who are experienced in it.
The idea of "proving" programs are correct is a naive one and the impracticality of doing so is one of the reasons why Ada failed.
These guys should also realize that support for OO programming was grafted on to Ada after C++ proved popular. So it would be more accurate to say that if you're writing OO code in Ada, you're really writing Simula, Smaltalk, or C++.
US automakers have always gone for the low hanging fruit, opposed any government-mandated improvements, and then got their clock cleaned when the Japanese automakers provided the improvements that they fought tooth and nail against.
"And he believes Red Hat should be doing $5 billion, not $500 million."
Any company would be glad to be doing $500 million when the core R&D for their product was done for free by AT&T and the core implementation was done for free by unpaid idealists. How much money would they be making if they had to pay for all that work?
"Not mentioning his death would be like not mentioning the death of Pavarotti."
If Pavarotti had only done 3 albums. Like many rock artists who died young, Cobain's death spared him the idignity of becoming a has-been. Had he lived he might very well be on "The Surreal Life" today.
"it's unlikely they would have survived long enough to dominate the search space. Few people would return to a search site that crashes whenever used, as shown by hitting the Google Search button followed by nothing happening."
Wow, even on Slashdot it takes a lot of balls to claim that Windows fails 100% of the time.
"Google success is largerly based on their use of commodity hardware in very large farms of servers, which is very efficient on a costs POV for their kind of operation. Just as an exercise, try to figure out what their operational costs would be if they had to license Windows 2003 server for each server they have."
Compare their revenues to how much they'd have to pay to license Windows and you'd find it wouldn't make that much difference. Of course they could have used BSD or some other type of Unix instead. In addition, they might also have been able to create their own OS specifically designed from the ground up to support search.
Seriously, the Slashdot moderation feature is there so that a "vocal" minority can hide or boost a comment because they dislike or agree with it respectively. It's a great service for those who prefer other people to do their thinking for them.
AOL bought Netscape because they wanted access to the economic value Netscape's alleged victim-hood at the hands of MS would bring. That was the only value the company had. After MS lost the government anti-trust case, AOL got their payday. Their only mistake was that they paid way too much for Netscape, so they lost money overall.
This always comes up. The fact is that the difference in standards between monopolies and non-monopolies are not nearly as vast as many slashdotters think. It's not so simple as Apple can do it and MS can't. In addition, once a particular government has had its day in court and won, it rapidly loses interest in pursing the company further.
Of course, the US government ignores monopolies all the time: TicketMaster has had a monopoly far more pervasive than MS's for a decade or more but nothing was done. Ironically, it usually requires a competitor with deep pockets and influence (e.g. IBM, Sun etc) to get the government to do anything.
"You're being an idiot. You're impervious to facts and reason. Most likely, anyone reading can already see this."
Typically the guy who keeps insulting his opponent and making it personal is the one who is suspect. In any case, I doubt that many people are interested in our little sub-thread.
"The point is, this is a system that implements real-time requirements. It is a realistic example of such a system. In fact, it is typical. It works just as well if the processing unit is a commodity x86 system or some other architecture.
I note that you are now talking about a system that implements real-time requirements rather than software that does. As I said at the start, such a system typically requires specialized hardware to meet real-time requirements and a video capture board is the specialized hardware used in this case.
You still haven't given any specific example of a real-time application that handles the fundamental real-time requirements entirely in software running on an X86 processor.
"True but you can limit the amount of crap code by enforcing standards!"
Of course, you're assuming the standards aren't themselves crap. Most members of standards committees don't have a lot of time to do stuff like designing and programming real applications. You can think of them as very bright people who wrote serious code a decade or more ago.
"Let's take the case of video acquisition. A typical requirement will be that the video hardware will trigger an interrupt when the buffer fills to some particular point."
In this scenario the critical real-time processing has already been performed by the video acquisition card. Then it generates an interrupt to the x86 which allows it to process the data in a non-real-time manner. Yes, the software has to be able to respond without too much latency, but the transfer of data doesn't occur in a real-time manner from a software point of view. In other words the timing behavior of the X86 software is not directly related to the real-time requirements of video data acquisition, but to the size of the card's video buffer. If the size of the buffer exceeded the available memory on the PC, the PC software wouldn't need to satisfy any timing deadlines at all. Thus an obvious real-time process could be performed without any timing requirements on the part of the software. How can this be? It's possible because the real-time behavior is being done the card, not by the software running on the X86 in the CPU.
"Your argument about PC video capture boards makes my point. They work fine in x86 systems and don't require any specialized hardware to make them work. They would work exactly the same in power PC systems or MIPS system. The fact that the board is in an x86 system doesn't make the hardware or software any more complex or simpler."
Wow, you are really missing the point. The capture board is more than just a minimal interface between a TV signal and the PC's processor, it's doing the heavy lifting with respect to the real-time requirements of capturing video. Thus the card is specialized hardware that makes video capture possible by performing the real-time processing. Obviously, it is "specialized" because you couldn't use that card to capture other kinds of data. Being "specialized" has nothing to do with complexity.
"The simplest way to get predictable timing behavior is simply to ensure that the worst case performance is sufficient to meet the timing requirements. Unpredictable acceleration only hurts you if the software isn't designed to account for it. Fortunately, designing the software to account for that is all but trivial."
That's fine if the timing requirements only have an upper bound, but what if there's a lower bound as well? What if the timing window is narrower than the jitter in timing behavior due to caches and prefetch etc? What is your trivial solution for that?
"I've asked you what kind of specialized hardware you think is required and the best you can come up with is "it depends". No, it doesn't depend. Specialized hardware is rarely needed to meet real time requirements."
So your saying that the specialized hardware you believe isn't needed doesn't depend on the application? I don't see how you can claim to understand something you don't believe exists. Do PC video capture boards merely consist of a TV tuner and a D/A converter controlled and sampled by specialized software running on the PC's x86? Why not? Now it's your turn: what software applications do you claim are real-time without any hardware assist?
"All modern x86 commodity implementations includes prioritized interrupts, precision counters and timers with interrupt-generation capability, and so on."
The features you describe are neither necessary nor sufficient for many real-time applications. Again, it's predictable timing behavior that is key.
"I think you have no idea what you're talking about."
Sure, as a former professional Atari 2600 programmer, I don't know anything about real-time software. Just because I had to write code that was accurate to a single CPU cycle, doesn't mean I know what I'm talking about.
"What kind of specialized hardware do you think is needed?"
It depends on what you are trying to build. Perhaps you are thinking of "fast as a bunny" applications rather than real-time.
"If the worst case behavior meets the real-time requirements, then you win. You can often get x86 systems whose worst case behavior is many times faster than non-x86 systems at the same price level."
Real-time has nothing to do with raw speed. There are real-time requirements that x86 software couldn't meet even if it used a processor a million times faster than the current state of the art. Real-time is about meeting bounded timing requirements. It's like batting in baseball: swinging too early is a just as much a strike as swinging too late no matter how fast you can swing.
What happens today is that systems with real-time requirements have delegated the real-time parts to specialized hardware instead of software. In that way they can avoid the problems that inconsistent timing would otherwise present. Thus real-time systems can be implemented on a x86 system, but not entirely in software.
Slashdot Mirror
I see you're trying to imply that Windows is insecure, but I don't see what that has to do with the issue of security through obscurity.
Analogies have their limits, so we shouldn't try to take it too far.
Even those who historically have critized "security through obscurity" never suggested that publishing their design or secrets would lead to better security, but rather that you can't assume your that your design can't be cracked.
Of course, the preferred approach is "security through design" which has nothing to do with correcting bugs. The latter could be called "security through maintenence". Thus while we might argue about whether closed or open source produces better design, examining source code for bugs can't compensate for a design that is insecure.
I think your logic is a bit confused. The fact that viruses can be created without reading the source code does not prove that there's no value in keeping the code secret. It's like arguing that there's no point in locking your door because 100,000 houses with locks were broken into.
That's a nice idealistic attitude, but I disagree. Today a university is a very costly and inefficient way to learn if your goal is purely the pursuit of knowledge.
In addition, the university's "prime directive" is not to teach students. Surely, the courses that each student has to take to graduate don't all correspond to each student's educational goals. Being "well-rounded" is defined in terms of what the university needs, not what the student needs. If a particular school wants to specialize in a particular obscure subject area, it will require uninterested students to take courses in that area in order to justify the expense of teaching it.
I suggest that anyone who thinks its just about learning, take your university qualifications off your resume and see what happens.
The subject matter that should be taught for a partiular major changes over time. I went to university before Unix and C were dominant and spent a considerable time doing assembly language coding. The value of that experience diminishes every day.
It's natual for those who spent a lot of time and effort learning (or teaching) now semi-obsolete material to overstate its importance today.
You say that as if it were something important to know.
Essentially these guys have a problem because they chose to use Ada - a language that was created for and mandated (briefly) by the government and rejected by the market. If you use a niche language, you're going to have trouble finding people who are experienced in it.
The idea of "proving" programs are correct is a naive one and the impracticality of doing so is one of the reasons why Ada failed.
These guys should also realize that support for OO programming was grafted on to Ada after C++ proved popular. So it would be more accurate to say that if you're writing OO code in Ada, you're really writing Simula, Smaltalk, or C++.
US automakers have always gone for the low hanging fruit, opposed any government-mandated improvements, and then got their clock cleaned when the Japanese automakers provided the improvements that they fought tooth and nail against.
IT'S A TRAP!
"And he believes Red Hat should be doing $5 billion, not $500 million."
Any company would be glad to be doing $500 million when the core R&D for their product was done for free by AT&T and the core implementation was done for free by unpaid idealists. How much money would they be making if they had to pay for all that work?
"Microsoft can't take this market from Apple through innovation, so they are trying to do it through litigation."
Just another example of MS ripping off an idea conceived by Sun, Oracle, IBM, AOL, and (ironically) Apple.
"Not mentioning his death would be like not mentioning the death of Pavarotti."
If Pavarotti had only done 3 albums. Like many rock artists who died young, Cobain's death spared him the idignity of becoming a has-been. Had he lived he might very well be on "The Surreal Life" today.
You keep using that phrase "fail 100% of the time". I do not think it means what you think it means.
"it's unlikely they would have survived long enough to dominate the search space. Few people would return to a search site that crashes whenever used, as shown by hitting the Google Search button followed by nothing happening."
Wow, even on Slashdot it takes a lot of balls to claim that Windows fails 100% of the time.
"Google success is largerly based on their use of commodity hardware in very large farms of servers, which is very efficient on a costs POV for their kind of operation. Just as an exercise, try to figure out what their operational costs would be if they had to license Windows 2003 server for each server they have."
Compare their revenues to how much they'd have to pay to license Windows and you'd find it wouldn't make that much difference. Of course they could have used BSD or some other type of Unix instead. In addition, they might also have been able to create their own OS specifically designed from the ground up to support search.
Sure, because nobody cares about subtle trolling.
Seriously, the Slashdot moderation feature is there so that a "vocal" minority can hide or boost a comment because they dislike or agree with it respectively. It's a great service for those who prefer other people to do their thinking for them.
AOL bought Netscape because they wanted access to the economic value Netscape's alleged victim-hood at the hands of MS would bring. That was the only value the company had. After MS lost the government anti-trust case, AOL got their payday. Their only mistake was that they paid way too much for Netscape, so they lost money overall.
This always comes up. The fact is that the difference in standards between monopolies and non-monopolies are not nearly as vast as many slashdotters think. It's not so simple as Apple can do it and MS can't. In addition, once a particular government has had its day in court and won, it rapidly loses interest in pursing the company further.
Of course, the US government ignores monopolies all the time: TicketMaster has had a monopoly far more pervasive than MS's for a decade or more but nothing was done. Ironically, it usually requires a competitor with deep pockets and influence (e.g. IBM, Sun etc) to get the government to do anything.
"You're being an idiot. You're impervious to facts and reason. Most likely, anyone reading can already see this."
Typically the guy who keeps insulting his opponent and making it personal is the one who is suspect. In any case, I doubt that many people are interested in our little sub-thread.
"The point is, this is a system that implements real-time requirements. It is a realistic example of such a system. In fact, it is typical. It works just as well if the processing unit is a commodity x86 system or some other architecture.
I note that you are now talking about a system that implements real-time requirements rather than software that does. As I said at the start, such a system typically requires specialized hardware to meet real-time requirements and a video capture board is the specialized hardware used in this case.
You still haven't given any specific example of a real-time application that handles the fundamental real-time requirements entirely in software running on an X86 processor.
"True but you can limit the amount of crap code by enforcing standards!"
Of course, you're assuming the standards aren't themselves crap. Most members of standards committees don't have a lot of time to do stuff like designing and programming real applications. You can think of them as very bright people who wrote serious code a decade or more ago.
"Let's take the case of video acquisition. A typical requirement will be that the video hardware will trigger an interrupt when the buffer fills to some particular point."
In this scenario the critical real-time processing has already been performed by the video acquisition card. Then it generates an interrupt to the x86 which allows it to process the data in a non-real-time manner. Yes, the software has to be able to respond without too much latency, but the transfer of data doesn't occur in a real-time manner from a software point of view. In other words the timing behavior of the X86 software is not directly related to the real-time requirements of video data acquisition, but to the size of the card's video buffer. If the size of the buffer exceeded the available memory on the PC, the PC software wouldn't need to satisfy any timing deadlines at all. Thus an obvious real-time process could be performed without any timing requirements on the part of the software. How can this be? It's possible because the real-time behavior is being done the card, not by the software running on the X86 in the CPU.
"Your argument about PC video capture boards makes my point. They work fine in x86 systems and don't require any specialized hardware to make them work. They would work exactly the same in power PC systems or MIPS system. The fact that the board is in an x86 system doesn't make the hardware or software any more complex or simpler."
Wow, you are really missing the point. The capture board is more than just a minimal interface between a TV signal and the PC's processor, it's doing the heavy lifting with respect to the real-time requirements of capturing video. Thus the card is specialized hardware that makes video capture possible by performing the real-time processing. Obviously, it is "specialized" because you couldn't use that card to capture other kinds of data. Being "specialized" has nothing to do with complexity.
"The simplest way to get predictable timing behavior is simply to ensure that the worst case performance is sufficient to meet the timing requirements. Unpredictable acceleration only hurts you if the software isn't designed to account for it. Fortunately, designing the software to account for that is all but trivial."
That's fine if the timing requirements only have an upper bound, but what if there's a lower bound as well? What if the timing window is narrower than the jitter in timing behavior due to caches and prefetch etc? What is your trivial solution for that?
"I've asked you what kind of specialized hardware you think is required and the best you can come up with is "it depends". No, it doesn't depend. Specialized hardware is rarely needed to meet real time requirements."
So your saying that the specialized hardware you believe isn't needed doesn't depend on the application? I don't see how you can claim to understand something you don't believe exists. Do PC video capture boards merely consist of a TV tuner and a D/A converter controlled and sampled by specialized software running on the PC's x86? Why not? Now it's your turn: what software applications do you claim are real-time without any hardware assist?
"All modern x86 commodity implementations includes prioritized interrupts, precision counters and timers with interrupt-generation capability, and so on."
The features you describe are neither necessary nor sufficient for many real-time applications. Again, it's predictable timing behavior that is key.
"I think you have no idea what you're talking about."
Sure, as a former professional Atari 2600 programmer, I don't know anything about real-time software. Just because I had to write code that was accurate to a single CPU cycle, doesn't mean I know what I'm talking about.
"What kind of specialized hardware do you think is needed?"
It depends on what you are trying to build. Perhaps you are thinking of "fast as a bunny" applications rather than real-time.
"If the worst case behavior meets the real-time requirements, then you win. You can often get x86 systems whose worst case behavior is many times faster than non-x86 systems at the same price level."
Real-time has nothing to do with raw speed. There are real-time requirements that x86 software couldn't meet even if it used a processor a million times faster than the current state of the art. Real-time is about meeting bounded timing requirements. It's like batting in baseball: swinging too early is a just as much a strike as swinging too late no matter how fast you can swing.
What happens today is that systems with real-time requirements have delegated the real-time parts to specialized hardware instead of software. In that way they can avoid the problems that inconsistent timing would otherwise present. Thus real-time systems can be implemented on a x86 system, but not entirely in software.