You are comparing two open source systems, one which is focused on security and the other which is not. Two very different code bases. You need to ask why Linux is not as secure as OpenBSD?
You are the one who claimed security and open source go hand in hand. But apparently they don't. Thanks for clearing that up.
Does this mean that you put OpenBSD and/or Linux under the umbrella of "Unix" but not Solaris and AIX?
It means that there is no open source software that is certified for use in some of the most security-conscious environments, despite your insistence that open source development must lead to more secure software.
Would you like to elaborate on these more flexible and powerful security models?
No. I'd have to look things up, or you'll accuse me of getting minor details wrong, and you'll manage to dredge up a lame comeback such as SELinux or some sort of ACL support anyway.
Windows networks come crashing to their knees when a user receives an infected email. You have got to be joking.
The point is, what is the cost of having your network go down once every so often, versus lacking all the features Outlook & Office provide in the mean time. I'm dead serious.
Rare occurance. Yes. Yes. And it has been fixed quick smart too.
Well, tell me about it. This is all about sharing, right?
And looking at the track record, perfected by the OpenBSD crew via open source.
No, it was perfected via painstaking attention to detail. In all those years nobody ever found the bug, which pretty much kills your "hundreds of thousands of eyes" theory.
I know it from experience.
Good for you. Your logic and your arguments need work though.
Do you think hundreds of thousands of eyes reviewing code is not better than a typical corporate team of eyes?
Totally unsubstantiated claim. I have every reason to believe that this kind of review never actually happens. The person most likely to fix a bug in code is the person who wrote that code. It also does not explain why Linux, which has far more people working on it than OpenBSD, is not more secure than OpenBSD.
The numbers I have been giving show capabilities of software. Unless the admins fixed broken code without giving it back, the admins here are irrelevant. You are showing worst cases which can easily be bad admin.
Which shows that proper administration is much more important to the security of a system than the question whether that system runs open or closed source software.
I firmly beleive that the average open source software is more secure and has less bugs than closed source
I know you believe that. Personally I believe that even if this were true, closed source software easily makes up for it in features and support (e.g. documentation).
Also "average open source software" is a bit vague isn't it. Does that "average" include all the stillborn projects at Sourceforge?
Conservative as in putting security before features?
Yes. Sometimes features are more important than security. And not all security is equal.
You want to posit this kind of argument that there is such as thing as "perfect security", and that OpenBSD (and other open source software) exemplifies this.
But that is bunk. Unix security is lackluster at best. It is the typical "good enough" type system. Windows NT, Solaris and AIX offer far more flexible and powerful security models -- if you need them. But if you don't need that kind of security, you can get by without it. In fact most people do.
If you choose a worst case I will choose Microsoft
So choose Microsoft. Does Windows crash when you load <font size="1666666"> in Mozilla?
You're either exposed or out of action until the hole is fixed.
Like, such as, irony of ironies, with the current OpenSSH hole? Did you check the source to see where the alleged vulnerability is at? Do you know people who did? I'd be interested to hear.
Furthermore it is interesting to note that SSH, the topic under discussion, was originally conceived and delivered as a commercial product. Not a strictly "open source" one.
Personally I use almost exclusively open source software. And I use it because the source is available. Not because I "believe" it to be secure, or even because I necessarily think it is "best of breed".
Security? A comparison of 2001 CERT advisories shows that closed source software constituted 72%.
So what? That might mean that closed source software has wider deployment. It might mean that closed source software is scrutinized more closely. It might even mean that closed source software is used in more places where security matters.
alldas.org defacement statistics per OS place Linux, an open source OS, at 22%, while Solaris, which is closed source, clocks in at 4%.
I also note that you failed to answer my question: if open source makes for secure software, then why do we need something like OpenBSD at all? Why are not all open source OS's as secure as OpenBSD?
The bottom line is that the distinction closed/open should make very little difference when evaluating the security aspect of any particular installation.
Stability? Netcraft shows that the web servers with the top 10 average [netcraft.com] and the top 19 maximum [netcraft.com] uptimes are Open Source.
Again, irrelevant. It might mean that open source people will go to great lengths to avoid rebooting their machines. It might even mean that open source software is conservative/stagnant. Unless the reboots actually hurt business there is no inherent advantage to long uptimes.
They get great stability and security through honest desire and mass co-operation.
Great stability and security are achieved by paying a lot of attention to stability and security. The development method is strictly secondary.
Linux, FreeBSD and OpenBSD has NEVER crashed on me in normal circumstances
What can I say. Try harder. For example take a look at how Linux MM will happily let a process run amok with a high probability of wrecking the box.
Learning OpenBSD for someone who is knowledgable about network security is far from steep learning.
That might be true, but is hardly any consolation if OpenBSD does not do what you need it to do.
Even in light of the recent vulnerability, Apache actually has a good security history. The last time it was mentioned in a CERT advisory was 1996. IIS has been mentioned 8 times since.
If you are going to make a blanket statement comparing security and reliability of open vs. closed source software, then I think you should compare the best of both Worlds.
Hey Pavlov, I'm saying no such thing. The only thing I would like to impress on you is the fact that despite all the propaganda on all sides, source availability has little to do with the security or reliability of software. Source availability means that the source is available. Source availability says nothing about the quality of the source.
OpenBSD is secure because Theo and friends are obsessed with security. Not because the source code is available. Otherwise, you need to explain to me why not ALL open source projects are as secure as OpenBSD.
Open source is nice in the way it fulfills demand that is otherwise too expensive for the market to bear. In the case of OpenBSD for instance the audience is too small to support a business. That is not to say that people are not interested in security, just that they recognize that this security comes at a steep cost ((re)training, missing features, maintenance).
Finally, two points.
1) The "default install" that you are referring to is very austere. Very few machines can be made useful running only the "default install". This is a direct result of OpenBSD favoring security over features. Maybe it's better to be safe than sorry but in the real world safety costs money too.
2) Most programming is propriety, closed-source in-house development. Every application is different. Wholesale comparisons such as "best of both worlds" just don't make sense. Compare, what? The security of an Internet fridge to that of an embedded control system?
Well, maybe, probably. Though for sound mixing there are a few decent programs there (at least I've done my part) and for graphics there are also a number of good (i.e. very workable) tools. 3D modeling, I am not aware of there being anything even remotely close to Windows/Mac packages, so that would be a real gap.
I think you are right with your point about maturity and completeness. On the other hand I simply don't agree with the necessity to have everything in one program, or for the need to have that program to be usable by absolutely every idiot. If you are capable enough to do great graphics on a computer then likely you can also learn how to edit a textfile. And this saves developers a lot of time writing wack code for preference dialogs and other "rubbish".
Yes. You CAN separate technical skill from artistry. A character in a Disney film will look the same no matter how it moves and what perspective it's viewed from. The proportions stay the same. The characters move realistically.
Obviously that requires a great deal of technical skill, but it follows from the artistic decision whether you think it is important whether the perspective is correct, the colors are natural, etcetera. Picasso didn't think it was very important for example.
I never asked anything like that.
Okay, sorry, didn't mean to put words in your mouth.
Write as much code as possible yourself. This way it snugly fits the requirements and you can absolutely verify its accuracy. Specialize as much as reasonably possible.
Avoid automatic code generation and specialized languages. You will end up with huge swaths of completely unreadable code that is impossible to understand and often unnecessarily inefficient.
Use the lowest level language feasible. Keep control over as much as you can afford. This is an investment that starts to pay off once libraries and auxiliary utilities start changing underneath you.
Code top-down. Work towards solving the most demanding problems first, and factor frequently used functions into functional modules later. It is no use writing code to anticipate a situation that you will never encounter.
One thing that I've found to be useful in general is this: don't confuse the goal with the metric.
It's fine to have a methodology in place to try and minimize the number of completely obvious faults and mistakes. But don't become a slave to the methodology. The user does not care that you have followed every rule in the book if in the end the program does not work.
Mistakes can be costly. Guidelines help prevent some of them. But institute an elaborate framework to idiot-proof your development process and the world will build a better idiot.
But what do you mean by pure technical skill? That the drawings faithfully mimic nature? That the motions are smooth and natural?
Those are artistic qualities as much as they are technical achievements. They are just as important to the appreciation of the movie as the story or the characters. In fact if you were to remove the "technical skill" from a Disney movie then not much would remain. It would no longer even _be_ a Disney movie. Thus the technical skill and the artistic message in a Disney movie are closely related. To appreciate the "technical skill" of a Disney movie is simply to appreciate the Disney esthetic.
Which is all good and well. But then to ask "which other movie maker makes better Disney movies than Disney" is I think a bit disingenuous.
there will be millions of Mozilla-users who won't accept a "use IE instead" because they *can't* use IE.
Actually there is an alternative perspective. Instead of "locking out Mozilla users" you can say that you are "adding value for IE users".
Re:Windows has us on this one.
on
Is RPM Doomed?
·
· Score: 1
The central repository idea has problems of its own. You cannot easily move programs and data from machine to machine when they depend on such a repository because the repository is (and has to be) unique from machine to machine. Manipulating the repository would require then new tools a la regedit.
Really the problem here is not so much RPM per se. I think you could create a system that resolved all the dependencies for you automatically and I think it could be done with existing tools.
The problem is simply that there is not a sole authority controlling the direction of Linux as a desktop platform. Red Hat comes closest, SuSE a good second. The problem is that it is simply not in the interest of a Linux vendor to make his system exactly the same as all the other systems; because then what would compel people to choose this product over that product?
You might imagine Red Hat providing a for-charge service that resolved any dependancy problems on Red Hat distro's, but would that works for Mandrake users as well? As long as there are different distros there will be conflicts.
I didn't mean to imply that the parent is a communist. I was merely trying to show that the idea is hardly a new one. And yes, personally I disagree with the parent. But I did not mean to slander him, if that is what you mean.
Also, while some means of transport might very well be best attended to by the state, I harbor sincere doubts whether you would go so far as to agree with Karl Marx that ALL means of transport should be in the hands of the state.
And after all these words we have not even adressed the "means of communication" issue yet, which I am sure you will agree is more germane to the matter at hand.
I say let's all move for congress to take all communicaitons hardware and make it an independant co-op agency. Make it illegal to have for-profit communications. It has become a public necessity and it should not be in the hands of greedy or controlling people.
"6. Centralisation of the means of communication and transport in the hands of the state."
-- Karl Marx & Friedrich Engels, The Manifesto of the Communist Party
Eh? The P2P network stuff is primitive because it just isn't a very sophisticated idea. Napster was the bomb because they had more or less the right idea -- creating an index of songs. The P2P networks were born because you can't do that anymore.
So it is nonsense to suggest that P2P networks will evolve to start indexing MD5 checksums or whatever, because it is precisely that kind of indexing that these networks were created to circumvent in the first place. Should such a system nevertheless come into being, then the next move will be pressure on ISPs to reject transport of any "unlicensed" traffic. TCP ports will be for sale like the frequency spectrum.
Well, it's always possible to make things more complicated. The advantage of keeping things simple is that it turns sed, awk, grep, cat and all the others into potential mail processing tools.
"Those that give up freedom for security deserve neither", is what your sig says -- but here you are, suggesting that Microsoft curb freedoms (i.e. easy of use) to allow for greater security.
Slashdot Mirror
Anonymous? Why would you do that?
Also "average open source software" is a bit vague isn't it. Does that "average" include all the stillborn projects at Sourceforge?
Yes. Sometimes features are more important than security. And not all security is equal.You want to posit this kind of argument that there is such as thing as "perfect security", and that OpenBSD (and other open source software) exemplifies this.
But that is bunk. Unix security is lackluster at best. It is the typical "good enough" type system. Windows NT, Solaris and AIX offer far more flexible and powerful security models -- if you need them. But if you don't need that kind of security, you can get by without it. In fact most people do.
So choose Microsoft. Does Windows crash when you load <font size="1666666"> in Mozilla? Like, such as, irony of ironies, with the current OpenSSH hole? Did you check the source to see where the alleged vulnerability is at? Do you know people who did? I'd be interested to hear.Furthermore it is interesting to note that SSH, the topic under discussion, was originally conceived and delivered as a commercial product. Not a strictly "open source" one.
Personally I use almost exclusively open source software. And I use it because the source is available. Not because I "believe" it to be secure, or even because I necessarily think it is "best of breed".
alldas.org defacement statistics per OS place Linux, an open source OS, at 22%, while Solaris, which is closed source, clocks in at 4%.
I also note that you failed to answer my question: if open source makes for secure software, then why do we need something like OpenBSD at all? Why are not all open source OS's as secure as OpenBSD?
The bottom line is that the distinction closed/open should make very little difference when evaluating the security aspect of any particular installation.
Again, irrelevant. It might mean that open source people will go to great lengths to avoid rebooting their machines. It might even mean that open source software is conservative/stagnant. Unless the reboots actually hurt business there is no inherent advantage to long uptimes. Great stability and security are achieved by paying a lot of attention to stability and security. The development method is strictly secondary. What can I say. Try harder. For example take a look at how Linux MM will happily let a process run amok with a high probability of wrecking the box. That might be true, but is hardly any consolation if OpenBSD does not do what you need it to do. What about the 13 Apache vulnerabilities since 1999? Easy. Ping of death was fixed within 48 hours on Windows. I'll grant that the Linux fix got there faster. So what?OpenBSD is secure because Theo and friends are obsessed with security. Not because the source code is available. Otherwise, you need to explain to me why not ALL open source projects are as secure as OpenBSD.
Open source is nice in the way it fulfills demand that is otherwise too expensive for the market to bear. In the case of OpenBSD for instance the audience is too small to support a business. That is not to say that people are not interested in security, just that they recognize that this security comes at a steep cost ((re)training, missing features, maintenance).
Finally, two points.
1) The "default install" that you are referring to is very austere. Very few machines can be made useful running only the "default install". This is a direct result of OpenBSD favoring security over features. Maybe it's better to be safe than sorry but in the real world safety costs money too.
2) Most programming is propriety, closed-source in-house development. Every application is different. Wholesale comparisons such as "best of both worlds" just don't make sense. Compare, what? The security of an Internet fridge to that of an embedded control system?
Open source does not mean:
If only because we cannot reliably quantify any of these things.
You are not communicating with the computer. You are instructing it.
Well, maybe, probably. Though for sound mixing there are a few decent programs there (at least I've done my part) and for graphics there are also a number of good (i.e. very workable) tools. 3D modeling, I am not aware of there being anything even remotely close to Windows/Mac packages, so that would be a real gap.
I think you are right with your point about maturity and completeness. On the other hand I simply don't agree with the necessity to have everything in one program, or for the need to have that program to be usable by absolutely every idiot. If you are capable enough to do great graphics on a computer then likely you can also learn how to edit a textfile. And this saves developers a lot of time writing wack code for preference dialogs and other "rubbish".
Obviously that requires a great deal of technical skill, but it follows from the artistic decision whether you think it is important whether the perspective is correct, the colors are natural, etcetera. Picasso didn't think it was very important for example.
I never asked anything like that.
Okay, sorry, didn't mean to put words in your mouth.
- Write as much code as possible yourself. This way it snugly fits the requirements and you can absolutely verify its accuracy. Specialize as much as reasonably possible.
- Avoid automatic code generation and specialized languages. You will end up with huge swaths of completely unreadable code that is impossible to understand and often unnecessarily inefficient.
- Use the lowest level language feasible. Keep control over as much as you can afford. This is an investment that starts to pay off once libraries and auxiliary utilities start changing underneath you.
- Code top-down. Work towards solving the most demanding problems first, and factor frequently used functions into functional modules later. It is no use writing code to anticipate a situation that you will never encounter.
- Work with the best!
Just another perspective.One thing that I've found to be useful in general is this: don't confuse the goal with the metric.
It's fine to have a methodology in place to try and minimize the number of completely obvious faults and mistakes. But don't become a slave to the methodology. The user does not care that you have followed every rule in the book if in the end the program does not work.
Mistakes can be costly. Guidelines help prevent some of them. But institute an elaborate framework to idiot-proof your development process and the world will build a better idiot.
But what do you mean by pure technical skill? That the drawings faithfully mimic nature? That the motions are smooth and natural?
Those are artistic qualities as much as they are technical achievements. They are just as important to the appreciation of the movie as the story or the characters. In fact if you were to remove the "technical skill" from a Disney movie then not much would remain. It would no longer even _be_ a Disney movie. Thus the technical skill and the artistic message in a Disney movie are closely related. To appreciate the "technical skill" of a Disney movie is simply to appreciate the Disney esthetic.
Which is all good and well. But then to ask "which other movie maker makes better Disney movies than Disney" is I think a bit disingenuous.
Actually there is an alternative perspective. Instead of "locking out Mozilla users" you can say that you are "adding value for IE users".
The central repository idea has problems of its own. You cannot easily move programs and data from machine to machine when they depend on such a repository because the repository is (and has to be) unique from machine to machine. Manipulating the repository would require then new tools a la regedit.
Really the problem here is not so much RPM per se. I think you could create a system that resolved all the dependencies for you automatically and I think it could be done with existing tools.
The problem is simply that there is not a sole authority controlling the direction of Linux as a desktop platform. Red Hat comes closest, SuSE a good second. The problem is that it is simply not in the interest of a Linux vendor to make his system exactly the same as all the other systems; because then what would compel people to choose this product over that product?
You might imagine Red Hat providing a for-charge service that resolved any dependancy problems on Red Hat distro's, but would that works for Mandrake users as well? As long as there are different distros there will be conflicts.
I didn't mean to imply that the parent is a communist. I was merely trying to show that the idea is hardly a new one. And yes, personally I disagree with the parent. But I did not mean to slander him, if that is what you mean.
Also, while some means of transport might very well be best attended to by the state, I harbor sincere doubts whether you would go so far as to agree with Karl Marx that ALL means of transport should be in the hands of the state.
And after all these words we have not even adressed the "means of communication" issue yet, which I am sure you will agree is more germane to the matter at hand.
How is it bad?
-- Karl Marx & Friedrich Engels, The Manifesto of the Communist Party
The super sharers are lazy and cheap. And opinionated. Probably the worst customer you could cater to.
You can't very well legislate away bad programming.
Eh? The P2P network stuff is primitive because it just isn't a very sophisticated idea. Napster was the bomb because they had more or less the right idea -- creating an index of songs. The P2P networks were born because you can't do that anymore.
So it is nonsense to suggest that P2P networks will evolve to start indexing MD5 checksums or whatever, because it is precisely that kind of indexing that these networks were created to circumvent in the first place. Should such a system nevertheless come into being, then the next move will be pressure on ISPs to reject transport of any "unlicensed" traffic. TCP ports will be for sale like the frequency spectrum.
Moderation and CRC checks imply assent. With that plausible deniability goes out of the window and filesharing tumbles after it.
This effectively amounts to giving RIAA the list of files it needs to shut down basically anyone.
Give it up already.
That's like asking whether the open-source community has the editors and the subscribers to make an interesting website.
Good question.
Well, it's always possible to make things more complicated. The advantage of keeping things simple is that it turns sed, awk, grep, cat and all the others into potential mail processing tools.
"Those that give up freedom for security deserve neither", is what your sig says -- but here you are, suggesting that Microsoft curb freedoms (i.e. easy of use) to allow for greater security.