All software is more valuable when Open Source, however it may not be more valuable *to its author*. Short term, definitely. Long term,... but 'When additions require modifications to the base system, there may be resistance to incorporating the changes.' Open Source may be free, but it's not cheap.
Also your testing methodology seems to be backwards That's because it's a design methodology. Poor hindsight beats 20/20 foresight.
How the hell can you start integrating stuff together if you haven't made sure the basics work yet? That's just asking for a disaster, where you have a huge pile of crap that's completely broken and undebuggable. Sounds like evolution. Until you've got the stuff working together, you don't really know what the units are. Not the fat middle. The edges. All the edges. Theory vs practice. In theory there is no difference. In practice there is. You can unit test against a hypothetical universe. The real one tends to throw you curves in places you didn't know you had places.
There will be a very few critical transforms. Those few need to be designed excruciatingly carefully.
Much more interesting is how to code for robustness in the face of bugs you _don't_ know about. Cheap shot at how. First comes the integration. All testing in done in-vivo. Second comes the writing of the programs, bugs and all. Testing at this phase is extremely interested in finding both bugs anytime the consequences are out of proportion to the causes. Finally, you might get around to unit testing.
The bugs you most want to get rid of are the ones that only show up in the presence of another bug. There are plenty of doubles. I've even seen a triple. Curing either will "make it go away". Curing both gives rather more confidence that the system won't go into shambles under pressure.
Thank you for the third factor. Factor is the right term. This stuff is multiplicative not additive. There may be a forth factor. The old greek "pride goes before a fall" brought up-to-date when the Wyle E. Coyote finally gets something working and truns to grin at the audience just before... splat.
I have no wish to have to think about kernel device drivers while I'm trying to write an email. [Emphasis added] Me neither, but there are a lot of levels between what you see and the kernel. To whom are you sending it? Outlook wants to hide the email address and show you the nickname for the Address Book entry. (Imagine the "fun" when the worms/viruses/whatevers start messing with which nickname goes to which email;) From where did you get it? (Right-click an Options is hardly intuitive). Think of the postmark on "real mail". You want to know which postoffice, not which postal clerk, although that would help in some cases. "An active-x on this site may be unsafe" Which active-x?
The main reason worms can cause such havoc is that they find themselves in a monoculture. That makes it easy for the worms to cause havoc. The main reason worms cause so much havoc is the tendency to try to hide stuff from everybody. CDs use Your computer to install and set up stuff so they can play themselves. File extensions are hidden so you can click on a presumably well-named file and have the spreadsheet show up. A general tendency to have to click on everything to be sure you don't miss something. A belief that there's got to be a magic bullet that will make everything safe again. And the belief that with the magic bullet in place that everything is safe. People click on things they shouldn't click on. Look at why they click on them.
"Regulation = Standardisation = More Worms" You've got that right, but methinks there are secondary forces that are even stronger than the primary. There is a progression starting with Melissa. (Remember Melissa? Melissa was nice!) Methinks we're nowhere near seeing the end of it.
I'm an MEng and I've still written programs that crash You can design something so critically that if one bolt or one thread is below specified strength, the whole thing will crash. But normally you design with a safety factor so that a number of things can be off-spec or break and still have the whole thing hold together and function properly. Now, how do you do a safety-factor in programming;-)
What's the point? Why would you ever want to ENABLE autoplay for data CDs? Especially now, when MUSIC CDs come with the data track which on autoplay silently installs a shitty player that spies on what tracks you're listening to.
[Rant mode on] To make the world safe for Microsoft worms and viruses. [Rant mode off]
Autoplay can be convenient but should be allowed only if it stays on its best behavior. The CD does NOT have any rights to play itself. But this is just one of a number of such things. This isn't security, even basic security. This is what is required to stand any chance of any kind of security.
Somewhat ironic that Linux is now being praised for bundling everything out of the box--exactly what got MS in trouble (IE, WMP, MSN, etc). Except that RedHat bundles KDE along with Gnome, MySQL along with Postgresql, and I'm sure a bunch more. Now if Microsoft bundled Netscape along with IE, AOL along with MSN, etc., you'd have a point about hypocrisy.
Of course the discovery that hardware raid was better suddenly became their idea and not mine But that's the way you want it. If it's their idea, nobody will get away with something that sounds good but doesn't quite cut it. If it's your idea, somebody will find a way that software raid is "good enough".
Because of this situation, it works well. Better solutions tend to percolate up and bad solutions tend to percolate down. Lather, Rinse, Repeat.
If you need help now, you need help now rather than waiting a week or a month for better help. Slammer knocked out the internet for what? About an hour or so, seems like. A couple of Linux boxes in a data center were up but effectively unusable for about 24 hours. They were reachable and partly useable with very narrow PuTTY windows. Short datagrams got through. Long datagrams didn't. The ability to respond, quickly, kinda-sorta accurately is the key to containing the damage from things you've never seen before.
Oh I know it was totally sarcastic (The first rule of security is not not have a false sense of). What makes it hilarious is that for a first-cut rule of thumb, it's actually pretty accurate. One reason to use OpenBSD, even if security is of no concern, it that it's very unbuggy. They're after bugs. Security is just a convenient way to keep score.
Simple. Mozilla probably just didn't know what it was. Correct. (Although I agree completely with everything swillden has to say;) The missing ingrediants are executable by whom and from what directory. (and several other things I'm too dumb to know about;) When in doubt, don't.
"I send you this virus to have your advice." Legitimate use of email, but anthing the mail handler does to show off how smart it is will be wrong.
In the "going to have to try a lot harder to trick users into executing their code!" bit, it'll never be over until "trick" is the hard part, not "execute". That seems to be the major difference between Microsoft and Linux security. With Microsoft Windows, "trick" is the easy part. Hiding file extensions is just part of a culture designed to make it easy for programs to trick users. With Linux, it's possible (somebody had a very small fork-bomb in his sig), but it's much harder to bamboozle the users.
"Race condition in app may enable a local DoS of said app in pre-2.4.18 kernels. Problem located and fixed by app developer one week after introduction in a previous patch."
Just doesn't cause quite the same exhilirating sense of alarm as:
"Critical flaw in OS DCOM service allows a remote attacker to completely hijack machine. Problem located by hackers and known/used for an unknown length of time before vendor alerted. Fixed by vendor, but flaw in vendor's update system causes many failed patches to register as complete."
Well put. It's not the count that matters, it's what is being counted. There's also the question of whether you're really any safer after patching. It's well worthwhile patching the last hole (not the same as the most recent), but all the patches before that still leave a system with holes.
People tend to forget that more holes are found in Microsoft products partly because more people use Microsoft products. As a result, that's where the attackers focus a great deal of their energy. Linux would have the same problem if it had Microsoft's market share. [Emphasis added] More holes are found in Microsoft products primarily because there are more hole there to be found. Easy holes. Low hanging fruit holes. Linux holes still exist but are becoming harder and harder to find. When they are found, Linux holes tend to get fixed rather than band-aided. There is a pervasive philosophical difference in that Microsoft believes in hiding the guts of the system from its users, while Linux (and moreso *BSD) believes that the more the user knows about what is going on, the better. The end result is that Linux would be effectively more secure even if it were fundamentally less secure. (fat chance!)
We? You have a disparate mob here running the gamut from *BSD partisans down to us Windows users who find/. indespensible for keeping up with the latest in Microsoft wormage. (And a few astroturfers thrown into the brew;) SCO does not get to do battle on just one front. It would be wrong for the linux-community to attack SCO's servers, but I would strongly suspect that its not the linux-community or even some individuals in it that are doing the attacking. SCO has a lot of enemies and a habit of being nasty with its friends. Methinks that "the enemy of my enemy is my friend" does not apply here.
The biggest security hole is a false sense of security.
The "Big Linux Worm" is waiting to happen and it will a doozie. Almost certainly true. The questions are: 1. How long before "under control"? How difficult? 2. How long before eradication? How difficult? 3. Should I be worried about it?
Considering that the response to Microsoft worms has been much quicker and better on the Unix side of the fence than by Microsoft at least from Melissa, I'm not particularly worried. However, long-term survival without useable backups is questionable.
"Where is the Innovation? Microsoft, mostly. Exercise: Compare 1990 Microsoft software with 2000.... If systems research was relevant, we'd see new operating systems and new languages making inroads into the industry, the way we did in the '70s and '80s.... Linux's success may indeed be the single strongest argument for my thesis: The excitement generated by a clone of a decades-old operating system demonstrates the void that the systems software research community has failed to fill. Besides, Linux's cleverness is not in the software, but in the development model, hardly a triumph of academic CS (especially sofware engineering) by any measure.... Plus, commercial companies that 'own' standards, e.g. Microsoft, Cisco, deliberately make standards hard to comply with, to frustrate competition. Academia is a casualty."
And ultimately commerce is a casualty.
"There was a claim in the late 1970s and early 1980s that Unix had killed operating systems research because no one would try anything else. At the time, I didn't believe it. Today, I grudgingly accept that the claim may be true (Microsoft notwithstanding)."... Go back to thinking about and building systems. Narrowness is irrelevant; breadth is relevant: it's the essence of system. Work on how systems behave and work, not just how they compare. Concentrate on interfaces and architecture, not just engineering."
Not dead. Sleeping. Not your cup of tea, but expect Algol68 to be revived in 2068;)
That's why it's an appropriate question for Ask Slashdot.
You can get progress from building stuff on top of what you've got. You can get progress from getting better stuff to build on top of. Long term, the second matters more but there is nothing easy about it.
I have two distinct impressions of Unix. It has outlived its betters and it is deceptively simple. It would be surprising if some of that (soul?) were not in Plan 9.
Question, though: If SCO could be forced to GPL Unixware, would we want it?
Speaking only for myself, no. Too much like an abandoned cesspool. There might be some good [expletive deleted] in there, but if so, I'd rather deal with something inferior and uncontaminated.
A rather critical point, actually. I could guess at your position, you could guess at mine, but neither of us is beholden to the other for his opinion. If I happen to agree with you I will do so argumentatively. I know what I think and I do not care if you agree with me. That is what SCO is facing. I for one see no need to limit the fronts where SCO needs to do battle.
Slashdot Mirror
All software is more valuable when Open Source, however it may not be more valuable *to its author*. ...
Short term, definitely.
Long term,
but 'When additions require modifications to the base system, there may be resistance to incorporating the changes.'
Open Source may be free, but it's not cheap.
Also your testing methodology seems to be backwards
That's because it's a design methodology. Poor hindsight beats 20/20 foresight.
How the hell can you start integrating stuff together if you haven't made sure the basics work yet? That's just asking for a disaster, where you have a huge pile of crap that's completely broken and undebuggable.
Sounds like evolution.
Until you've got the stuff working together, you don't really know what the units are. Not the fat middle. The edges. All the edges.
Theory vs practice. In theory there is no difference. In practice there is.
You can unit test against a hypothetical universe. The real one tends to throw you curves in places you didn't know you had places.
There will be a very few critical transforms. Those few need to be designed excruciatingly carefully.
Much more interesting is how to code for robustness in the face of bugs you _don't_ know about.
Cheap shot at how.
First comes the integration. All testing in done in-vivo.
Second comes the writing of the programs, bugs and all.
Testing at this phase is extremely interested in finding both bugs anytime the consequences are out of proportion to the causes.
Finally, you might get around to unit testing.
The bugs you most want to get rid of are the ones that only show up in the presence of another bug. There are plenty of doubles. I've even seen a triple. Curing either will "make it go away". Curing both gives rather more confidence that the system won't go into shambles under pressure.
Thank you for the third factor. ... splat.
Factor is the right term. This stuff is multiplicative not additive.
There may be a forth factor. The old greek "pride goes before a fall" brought up-to-date when the Wyle E. Coyote finally gets something working and truns to grin at the audience just before
I have no wish to have to think about kernel device drivers while I'm trying to write an email. [Emphasis added]
Me neither, but there are a lot of levels between what you see and the kernel.
To whom are you sending it? Outlook wants to hide the email address and show you the nickname for the Address Book entry. (Imagine the "fun" when the worms/viruses/whatevers start messing with which nickname goes to which email;)
From where did you get it? (Right-click an Options is hardly intuitive). Think of the postmark on "real mail". You want to know which postoffice, not which postal clerk, although that would help in some cases.
"An active-x on this site may be unsafe" Which active-x?
The main reason worms can cause such havoc is that they find themselves in a monoculture.
That makes it easy for the worms to cause havoc. The main reason worms cause so much havoc is the tendency to try to hide stuff from everybody.
CDs use Your computer to install and set up stuff so they can play themselves.
File extensions are hidden so you can click on a presumably well-named file and have the spreadsheet show up.
A general tendency to have to click on everything to be sure you don't miss something.
A belief that there's got to be a magic bullet that will make everything safe again. And the belief that with the magic bullet in place that everything is safe.
People click on things they shouldn't click on. Look at why they click on them.
"Regulation = Standardisation = More Worms"
You've got that right, but methinks there are secondary forces that are even stronger than the primary. There is a progression starting with Melissa. (Remember Melissa? Melissa was nice!) Methinks we're nowhere near seeing the end of it.
I'm an MEng and I've still written programs that crash ;-)
You can design something so critically that if one bolt or one thread is below specified strength, the whole thing will crash. But normally you design with a safety factor so that a number of things can be off-spec or break and still have the whole thing hold together and function properly.
Now, how do you do a safety-factor in programming
What's the point? Why would you ever want to ENABLE autoplay for data CDs? Especially now, when MUSIC CDs come with the data track which on autoplay silently installs a shitty player that spies on what tracks you're listening to.
[Rant mode on]
To make the world safe for Microsoft worms and viruses.
[Rant mode off]
Autoplay can be convenient but should be allowed only if it stays on its best behavior. The CD does NOT have any rights to play itself. But this is just one of a number of such things. This isn't security, even basic security. This is what is required to stand any chance of any kind of security.
Somewhat ironic that Linux is now being praised for bundling everything out of the box--exactly what got MS in trouble (IE, WMP, MSN, etc).
Except that RedHat bundles KDE along with Gnome, MySQL along with Postgresql, and I'm sure a bunch more.
Now if Microsoft bundled Netscape along with IE, AOL along with MSN, etc., you'd have a point about hypocrisy.
Of course the discovery that hardware raid was better suddenly became their idea and not mine
But that's the way you want it. If it's their idea, nobody will get away with something that sounds good but doesn't quite cut it. If it's your idea, somebody will find a way that software raid is "good enough".
So what? NT's kernel has been fully pre-emptable/interuptable since the days of 3.51.
Then what's its excuse?
The way I describe it to my users is that Microsoft has a hard time trying to walk and chew gum at the same time.
Because of this situation, it works well.
Better solutions tend to percolate up and bad solutions tend to percolate down.
Lather, Rinse, Repeat.
If you need help now, you need help now rather than waiting a week or a month for better help. Slammer knocked out the internet for what? About an hour or so, seems like. A couple of Linux boxes in a data center were up but effectively unusable for about 24 hours. They were reachable and partly useable with very narrow PuTTY windows. Short datagrams got through. Long datagrams didn't. The ability to respond, quickly, kinda-sorta accurately is the key to containing the damage from things you've never seen before.
Oh I know it was totally sarcastic (The first rule of security is not not have a false sense of).
What makes it hilarious is that for a first-cut rule of thumb, it's actually pretty accurate. One reason to use OpenBSD, even if security is of no concern, it that it's very unbuggy. They're after bugs. Security is just a convenient way to keep score.
Simple. Mozilla probably just didn't know what it was.
Correct. (Although I agree completely with everything swillden has to say;)
The missing ingrediants are executable by whom and from what directory. (and several other things I'm too dumb to know about;)
When in doubt, don't.
"I send you this virus to have your advice."
Legitimate use of email, but anthing the mail handler does to show off how smart it is will be wrong.
In the "going to have to try a lot harder to trick users into executing their code!" bit, it'll never be over until "trick" is the hard part, not "execute".
That seems to be the major difference between Microsoft and Linux security. With Microsoft Windows, "trick" is the easy part. Hiding file extensions is just part of a culture designed to make it easy for programs to trick users. With Linux, it's possible (somebody had a very small fork-bomb in his sig), but it's much harder to bamboozle the users.
Well put.
It's not the count that matters, it's what is being counted.
There's also the question of whether you're really any safer after patching. It's well worthwhile patching the last hole (not the same as the most recent), but all the patches before that still leave a system with holes.
People tend to forget that more holes are found in Microsoft products partly because more people use Microsoft products. As a result, that's where the attackers focus a great deal of their energy. Linux would have the same problem if it had Microsoft's market share. [Emphasis added]
More holes are found in Microsoft products primarily because there are more hole there to be found. Easy holes. Low hanging fruit holes. Linux holes still exist but are becoming harder and harder to find. When they are found, Linux holes tend to get fixed rather than band-aided.
There is a pervasive philosophical difference in that Microsoft believes in hiding the guts of the system from its users, while Linux (and moreso *BSD) believes that the more the user knows about what is going on, the better. The end result is that Linux would be effectively more secure even if it were fundamentally less secure. (fat chance!)
If entering a zero into a database field causes Windows to crash, it's because a badly written device driver
If that is true, Microsoft is in even worse shape that I think it is.
We? /. indespensible for keeping up with the latest in Microsoft wormage. (And a few astroturfers thrown into the brew;)
You have a disparate mob here running the gamut from *BSD partisans down to us Windows users who find
SCO does not get to do battle on just one front. It would be wrong for the linux-community to attack SCO's servers, but I would strongly suspect that its not the linux-community or even some individuals in it that are doing the attacking. SCO has a lot of enemies and a habit of being nasty with its friends. Methinks that "the enemy of my enemy is my friend" does not apply here.
The biggest security hole is a false sense of security.
The "Big Linux Worm" is waiting to happen and it will a doozie.
Almost certainly true. The questions are:
1. How long before "under control"? How difficult?
2. How long before eradication? How difficult?
3. Should I be worried about it?
Considering that the response to Microsoft worms has been much quicker and better on the Unix side of the fence than by Microsoft at least from Melissa, I'm not particularly worried. However, long-term survival without useable backups is questionable.
Dead aim on a mouse with a bazooka.
That's the cure for Microsoft's problems with worms, but they won't listen, not for a long long time.
Point made.
... ... ...
...
;)
Blecht!
"Where is the Innovation?
Microsoft, mostly. Exercise: Compare 1990 Microsoft software with 2000.
If systems research was relevant, we'd see new operating systems and new languages making inroads into the industry, the way we did in the '70s and '80s.
Linux's success may indeed be the single strongest argument for my thesis: The excitement generated by a clone of a decades-old operating system demonstrates the void that the systems software research community has failed to fill.
Besides, Linux's cleverness is not in the software, but in the development model, hardly a triumph of academic CS (especially sofware engineering) by any measure.
Plus, commercial companies that 'own' standards, e.g. Microsoft, Cisco, deliberately make standards hard to comply with, to frustrate competition. Academia is a casualty."
And ultimately commerce is a casualty.
"There was a claim in the late 1970s and early 1980s that Unix had killed operating systems research because no one would try anything else. At the time, I didn't believe it. Today, I grudgingly accept that the claim may be true (Microsoft notwithstanding)."
Go back to thinking about and building systems. Narrowness is irrelevant; breadth is relevant: it's the essence of system.
Work on how systems behave and work, not just how they compare. Concentrate on interfaces and architecture, not just engineering."
Not dead. Sleeping.
Not your cup of tea, but expect Algol68 to be revived in 2068
Don't worry, we'll be waiting for you.
That's why it's an appropriate question for Ask Slashdot.
You can get progress from building stuff on top of what you've got.
You can get progress from getting better stuff to build on top of.
Long term, the second matters more but there is nothing easy about it.
I have two distinct impressions of Unix. It has outlived its betters and it is deceptively simple. It would be surprising if some of that (soul?) were not in Plan 9.
Question, though: If SCO could be forced to GPL Unixware, would we want it?
Speaking only for myself, no.
Too much like an abandoned cesspool. There might be some good [expletive deleted] in there, but if so, I'd rather deal with something inferior and uncontaminated.
A rather critical point, actually. I could guess at your position, you could guess at mine, but neither of us is beholden to the other for his opinion. If I happen to agree with you I will do so argumentatively. I know what I think and I do not care if you agree with me. That is what SCO is facing. I for one see no need to limit the fronts where SCO needs to do battle.