That would work, except that no "other product" would claim it either. So what happens when you search the market and find 20 programs that claim to do what you want, but none of them will guarantee their work?
"most" free software is complete and utter crap. "most" free software never gets past version.00000001. "most" free software doesn't get reviewed by very many eyes at all.
some free software projects are certainly of much better quality and get massive peer review, but that number is pretty small compared to the vast sea of crap free software out there that doesn't.
Freshmeat lists nearly 70,000 projects. You can't possibly believe that "most" of those are of even moderate quality, or that "most" of them get any real peer review.
Even if we accepted your inaccurate tautology, it wouldn't change the fact that having "fewer" bugs wouldn't make you any less liable. All it takes is one to put you in financial ruin if such liability were required. Simply put, no open source developer could afford to write code, much like no unlicensed and uninsured doctor can afford to practice medicine.
You raise an interesting point, however, let's look at how a bridge is built versus how software is built.
When you build a bridget, an architect designs every detail of that bridge. An engineer ensures that the bridge is structurally sound, and develops the methods used to build it.
The people that actually BUILD the bridge, are, for all intents and purposes, monkeys. Skilled monkeys, to be sure, but monkey's no less. They do what they're told, and have no "creative input" into the building of the bridge.
In software, typically everyone working on it has creative input of some kind or another. There are no standardized ways to do the jobs they're told to do, and they often have to engineer their own solutions, and depending on their experience and skill can choose some pretty poor ways to do it.
Software engineers ARE engineers in every sense of the word, because they're DOING engineering tasks. That doesn't mean their qualified to BE an engineer, they just are by default.
Until such time as the software can be 100% specified by a qualified engineer, and no creative input is required by the workers, you won't get a well engineered product. In fact, if that were possible, you wouldn't even NEED programmers. The software could be specified, and then other software could build it based on the specifications.
So, until programmers are no longer needed, you're not going to have well engineered software.
I still think you're ignoring the obvious. You only hire what you consider to be good programmers, because those are the people that pass your test. While indeed, you do get good programmers, you're also NOT hiring good programmers that simply "froze up" during your interview, or were simply not mentally in the programming mind frame at the time of the interview.
I disagree completely that good programmers can always come up with good algorithms on the spot. I disagree that even a majority would. You clearly haven't been on the other side of the desk in recent memory or you would understand that interviews are things programmers don't do very well. They tend not to be "social" and don't often like talking about themselves. Thus, they're in an uncomfortable situation in which they've probably spent a TON of time preparing themselves for the kinds of interview questions they've come to expect, not "Quick! think up an elegant solution that's highly optimized right now!"
Now of course there are plenty of programmers that ARE comfortable in those situations, and lots that CAN think logically in such situations, but you're discriminating against a possibly otherwise qualified candidate that can't play your game.
If critical thinking is important to your selection criteria, then make it such, but don't pretend that just because someone can't come up with an algorithm on the spot, they're not a good programmer.
As for people answering the question here on slashdot.. DUH. Most of us read slashdot while we're waiting for our code to compile, or on lunch break, or just when we're frustrated with a problem and need a distraction. Most of us are "in the zone" when we read slashdot, so of course you're getting responses from people here, and because they have the opportunity to think about it while not under pressure, you're getting some good responses.
I just think your interview style is targeted not at good programmers, but at critical thinkers (ie, people that can think quickly and under pressure, and when they least expect it). And, that's certainly a good trait to have, but please don't call people bad programmers if they don't have that trait.
While I agree that in theory, and in labratory conditions, Java is just as fast (sometimes faster) than C/C++, in practice it doesn't usually end up that way.
The way normal people write code, and the libraries and functions that normal people use, java is slow as snot. I don't care why that is, it just is, and it makes me steer away from Java client applications if there is something that is native or.NET available instead.
Real world results are different from labratory ones as far as Java is concerned in my book. And that's just my experience.
Unfortunately, asking a interviewee to write code on the spot only tests the interviewees critical thinking capabilities. No their programming skill.
When an interviewee comes to an interview, his state of mind is on passing HR related questions. He's prepared for questions like "Why did you leave your last job" or "What's your greatest flaw", not writing code on the spot.
Most programmers I know have to be "in the zone" to write good code, and can't just jump from one mode to another instantaneously. That's why programmers need to be given nice quiet areas and left alone for long periods of time to get stuff done. Constant interruptions and distractions prevent them from being "in the zone".
While critical thinking may be a good trait, it's not a very common one, especially to programmers. Maybe THAT is why so few of them can do what you ask, not that they're incapable, but rather that they just weren't expecting it and can't switch gears that fast.
Delphi now compiles to.NET code, and.NET runs on Mono, which runs on several platforms. It's not Windows Only. The compiler might be, but the output isn't.
Lifetime achievement awards are given to people towards the END of their lifetime, not in the middle of it. The reason is that people still have a lot to contribute in their lifetime, and giving such an award to someone in the middle basically snubs what they may do afterwards.
And, for the record, giving someone TWO lifetime achievement awards for the same thing is pretty stupid, so any work done after such an award will likely go unrecognized, at least by that organization.
Perhaps a better name for the award would have been "Contribution Award" or something along those lines, that recognizes contributions done to date, without the bad connotations of "lifetime achievement".
I agree, but that's not what I said. Even if they've changed their UA string to say IE, it will still report as running on Linux, unless they completely override the entire string (Mozilla/Firefox provide both UA string override and UA string). Apart from the fact that most users don't even know how to change their UA (Opera provides a nice GUI to do it, but Opera's share is pretty small, even on Linux), most would just change the Browser name reported.
Well, just because you're paranoid, doesn't mean everyone else is. What evidence do you have that any most people using Linux are changing their user agent strings from the defaults to masquerade strictly as a windows browser?
For all those 10 million desktops, i'm not seeing it translate to Web site hits.
That tells me that most of those desktops are essentially dumb terminals, running turnkey applications, rather than real user desktops where the user is free to do whatever they wish.
I'm sure someone will argue that browser agent strings aren't reliable, and that they can be forged, but most of the browsers actually report themselves as Linux, even if they pretend to be IE.
Theo's response is not really appropriate. Rather than talking about WHY OpenSSH is "Enterprise Class" he makes the argument that because it's being used in Enterprise, that means it is "Enterprise Class".
I'd rather he explain why OpenSSH is just as Enterprise Class as SSH is.
not to be off topic, but there are several options for reading, and converting those old documents. For example, a program like QuickView Plus (used to be included with Windows 95 years ago) can still read those old documents. This is only a viewer, but you can copy and paste into somethign else.
You can't write anywhere on the filesystem, you can only write where your account has rights to, but that might be a location a priviledged account also has access to.
Perhaps you should actually read the reason why a priviledge escalation could occur. From the bulletin:
"How could an attacker exploit the vulnerability? An attacker who successfully exploited this vulnerability could save code of their choice to the user's local file system. Although this code could not be run through this vulnerability directly, the operating system might open the file if it is saved to a sensitive location, or a user may activate the file inadvertently and cause the attacker's code to run."
In other words, if the file is written somewhere that a user with a higher privilege could execute, then it would become a privilege escalation. IE itself is not escalating any privileges.
You beg to differ how? Are you suggesting that Windows somehow blocks Mozilla from using any of those API's if they wanted to?
The majority of what's considered "undocumented" is shell API's, which are also userland API's. Having more intimate knowledge of the shell doesn't expose any new vulnerabilities that couldn't be there in any other application (including Mozilla).
Any program running in userland has the same risks as any other program running in userland if a vulnerability is found (say, one that allows arbitrary code execution). That's because anything one userland program can do (including operating system components running in userland) can be done by any other userland program.
While I agree with you to some extent, I think this process merely ends up with an "encyclopedia" of vulnerability types, and after that encyclopedia reaches a point where people can no longer keep everything in mind, just becomes useless garbage.
More than merely categorizing attacks, you need to a way to analyze code to account for them all. Relying on humans to remember all these when they code, or even when they review, is inherantly error prone.
You didn't really answer the question. I'll take that as a "No, I don't know what that really means. No, I don't know how it really effects security, i'm just assuming things".
What you're describing is security through obscurity. Mozilla has core libraries as well, and they are exposed to any application that wants to take advantage of them.
Of course you can get around this problem by statically linking all the code together, but then you create far more maintenance work.
Even if we accept your logic, do you really consider 32 versus 28 to be all that big of a difference?
Oh, it's ONLY 28? Would you drive a car that had 28 flaws in it, a large number of which were critical and could have killed you?
Thankfully, nobody dies if there's bugs in a browser, but certainly you can't argue that 32 versus 28 makes Mozilla any no more secure than IE in any meaningful way.
Doesn't this imply that the Mozilla-family problems are being found and patched before exploitation, while IE problems are taking longer to find and address?
No, not at all. All it means is that IE is still a juicier target.
Think like a malicious hacker for a few minutes. You know that Mozilla/Firefox is used primarily by people that are smart enough to ditch IE. You know that the people using IE are, on average, probably less sophisticated or knowledgable, and possibly even downright ignorant or stupid. You also know that IE has 8-10x as many machines out there.
Slashdot Mirror
That would work, except that no "other product" would claim it either. So what happens when you search the market and find 20 programs that claim to do what you want, but none of them will guarantee their work?
You have our current market.
"most" free software is complete and utter crap. "most" free software never gets past version .00000001. "most" free software doesn't get reviewed by very many eyes at all.
some free software projects are certainly of much better quality and get massive peer review, but that number is pretty small compared to the vast sea of crap free software out there that doesn't.
Freshmeat lists nearly 70,000 projects. You can't possibly believe that "most" of those are of even moderate quality, or that "most" of them get any real peer review.
Even if we accepted your inaccurate tautology, it wouldn't change the fact that having "fewer" bugs wouldn't make you any less liable. All it takes is one to put you in financial ruin if such liability were required. Simply put, no open source developer could afford to write code, much like no unlicensed and uninsured doctor can afford to practice medicine.
You raise an interesting point, however, let's look at how a bridge is built versus how software is built.
When you build a bridget, an architect designs every detail of that bridge. An engineer ensures that the bridge is structurally sound, and develops the methods used to build it.
The people that actually BUILD the bridge, are, for all intents and purposes, monkeys. Skilled monkeys, to be sure, but monkey's no less. They do what they're told, and have no "creative input" into the building of the bridge.
In software, typically everyone working on it has creative input of some kind or another. There are no standardized ways to do the jobs they're told to do, and they often have to engineer their own solutions, and depending on their experience and skill can choose some pretty poor ways to do it.
Software engineers ARE engineers in every sense of the word, because they're DOING engineering tasks. That doesn't mean their qualified to BE an engineer, they just are by default.
Until such time as the software can be 100% specified by a qualified engineer, and no creative input is required by the workers, you won't get a well engineered product. In fact, if that were possible, you wouldn't even NEED programmers. The software could be specified, and then other software could build it based on the specifications.
So, until programmers are no longer needed, you're not going to have well engineered software.
I still think you're ignoring the obvious. You only hire what you consider to be good programmers, because those are the people that pass your test. While indeed, you do get good programmers, you're also NOT hiring good programmers that simply "froze up" during your interview, or were simply not mentally in the programming mind frame at the time of the interview.
I disagree completely that good programmers can always come up with good algorithms on the spot. I disagree that even a majority would. You clearly haven't been on the other side of the desk in recent memory or you would understand that interviews are things programmers don't do very well. They tend not to be "social" and don't often like talking about themselves. Thus, they're in an uncomfortable situation in which they've probably spent a TON of time preparing themselves for the kinds of interview questions they've come to expect, not "Quick! think up an elegant solution that's highly optimized right now!"
Now of course there are plenty of programmers that ARE comfortable in those situations, and lots that CAN think logically in such situations, but you're discriminating against a possibly otherwise qualified candidate that can't play your game.
If critical thinking is important to your selection criteria, then make it such, but don't pretend that just because someone can't come up with an algorithm on the spot, they're not a good programmer.
As for people answering the question here on slashdot.. DUH. Most of us read slashdot while we're waiting for our code to compile, or on lunch break, or just when we're frustrated with a problem and need a distraction. Most of us are "in the zone" when we read slashdot, so of course you're getting responses from people here, and because they have the opportunity to think about it while not under pressure, you're getting some good responses.
I just think your interview style is targeted not at good programmers, but at critical thinkers (ie, people that can think quickly and under pressure, and when they least expect it). And, that's certainly a good trait to have, but please don't call people bad programmers if they don't have that trait.
While I agree that in theory, and in labratory conditions, Java is just as fast (sometimes faster) than C/C++, in practice it doesn't usually end up that way.
.NET available instead.
The way normal people write code, and the libraries and functions that normal people use, java is slow as snot. I don't care why that is, it just is, and it makes me steer away from Java client applications if there is something that is native or
Real world results are different from labratory ones as far as Java is concerned in my book. And that's just my experience.
Unfortunately, asking a interviewee to write code on the spot only tests the interviewees critical thinking capabilities. No their programming skill.
When an interviewee comes to an interview, his state of mind is on passing HR related questions. He's prepared for questions like "Why did you leave your last job" or "What's your greatest flaw", not writing code on the spot.
Most programmers I know have to be "in the zone" to write good code, and can't just jump from one mode to another instantaneously. That's why programmers need to be given nice quiet areas and left alone for long periods of time to get stuff done. Constant interruptions and distractions prevent them from being "in the zone".
While critical thinking may be a good trait, it's not a very common one, especially to programmers. Maybe THAT is why so few of them can do what you ask, not that they're incapable, but rather that they just weren't expecting it and can't switch gears that fast.
Delphi now compiles to .NET code, and .NET runs on Mono, which runs on several platforms. It's not Windows Only. The compiler might be, but the output isn't.
Indeed, though I wouldn't quite put it that way.
Lifetime achievement awards are given to people towards the END of their lifetime, not in the middle of it. The reason is that people still have a lot to contribute in their lifetime, and giving such an award to someone in the middle basically snubs what they may do afterwards.
And, for the record, giving someone TWO lifetime achievement awards for the same thing is pretty stupid, so any work done after such an award will likely go unrecognized, at least by that organization.
Perhaps a better name for the award would have been "Contribution Award" or something along those lines, that recognizes contributions done to date, without the bad connotations of "lifetime achievement".
GoogleBrowser. While who knows what Google has up their sleeves, they've said they have no plans to create their own branded browser.
I agree, but that's not what I said. Even if they've changed their UA string to say IE, it will still report as running on Linux, unless they completely override the entire string (Mozilla/Firefox provide both UA string override and UA string). Apart from the fact that most users don't even know how to change their UA (Opera provides a nice GUI to do it, but Opera's share is pretty small, even on Linux), most would just change the Browser name reported.
Well, just because you're paranoid, doesn't mean everyone else is. What evidence do you have that any most people using Linux are changing their user agent strings from the defaults to masquerade strictly as a windows browser?
For all those 10 million desktops, i'm not seeing it translate to Web site hits.
That tells me that most of those desktops are essentially dumb terminals, running turnkey applications, rather than real user desktops where the user is free to do whatever they wish.
I'm sure someone will argue that browser agent strings aren't reliable, and that they can be forged, but most of the browsers actually report themselves as Linux, even if they pretend to be IE.
Theo's response is not really appropriate. Rather than talking about WHY OpenSSH is "Enterprise Class" he makes the argument that because it's being used in Enterprise, that means it is "Enterprise Class".
I'd rather he explain why OpenSSH is just as Enterprise Class as SSH is.
No, there's still a commercial version of QVP available, Quick View Plus 8
o cuments/word_files/quickviewplus8formats.pdf
Here's a list of supported document formats:
http://www.avantstar.com/stellent/groups/public/d
not to be off topic, but there are several options for reading, and converting those old documents. For example, a program like QuickView Plus (used to be included with Windows 95 years ago) can still read those old documents. This is only a viewer, but you can copy and paste into somethign else.
Perhaps, however this is something you can do in Mozilla as well, which is exactly my point.
You can't write anywhere on the filesystem, you can only write where your account has rights to, but that might be a location a priviledged account also has access to.
Perhaps you should actually read the reason why a priviledge escalation could occur. From the bulletin:
"How could an attacker exploit the vulnerability?
An attacker who successfully exploited this vulnerability could save code of their choice to the user's local file system. Although this code could not be run through this vulnerability directly, the operating system might open the file if it is saved to a sensitive location, or a user may activate the file inadvertently and cause the attacker's code to run."
In other words, if the file is written somewhere that a user with a higher privilege could execute, then it would become a privilege escalation. IE itself is not escalating any privileges.
I take it you are still not answering the actual questions asked.
You beg to differ how? Are you suggesting that Windows somehow blocks Mozilla from using any of those API's if they wanted to?
The majority of what's considered "undocumented" is shell API's, which are also userland API's. Having more intimate knowledge of the shell doesn't expose any new vulnerabilities that couldn't be there in any other application (including Mozilla).
Any program running in userland has the same risks as any other program running in userland if a vulnerability is found (say, one that allows arbitrary code execution). That's because anything one userland program can do (including operating system components running in userland) can be done by any other userland program.
While I agree with you to some extent, I think this process merely ends up with an "encyclopedia" of vulnerability types, and after that encyclopedia reaches a point where people can no longer keep everything in mind, just becomes useless garbage.
More than merely categorizing attacks, you need to a way to analyze code to account for them all. Relying on humans to remember all these when they code, or even when they review, is inherantly error prone.
You didn't really answer the question. I'll take that as a "No, I don't know what that really means. No, I don't know how it really effects security, i'm just assuming things".
What you're describing is security through obscurity. Mozilla has core libraries as well, and they are exposed to any application that wants to take advantage of them.
Of course you can get around this problem by statically linking all the code together, but then you create far more maintenance work.
Even if we accept your logic, do you really consider 32 versus 28 to be all that big of a difference?
Oh, it's ONLY 28? Would you drive a car that had 28 flaws in it, a large number of which were critical and could have killed you?
Thankfully, nobody dies if there's bugs in a browser, but certainly you can't argue that 32 versus 28 makes Mozilla any no more secure than IE in any meaningful way.
Doesn't this imply that the Mozilla-family problems are being found and patched before exploitation, while IE problems are taking longer to find and address?
No, not at all. All it means is that IE is still a juicier target.
Think like a malicious hacker for a few minutes. You know that Mozilla/Firefox is used primarily by people that are smart enough to ditch IE. You know that the people using IE are, on average, probably less sophisticated or knowledgable, and possibly even downright ignorant or stupid. You also know that IE has 8-10x as many machines out there.
Which would YOU write for?