Then how do you account for automobiles?
Or bicycles? Riding horses?
The Segway is the only common mode of transport where you actually stand up the entire time. And yet it's the only one that suffers from fools yelling "lazy". If you can stand, then get rid of your car, your bike, and stay off public transit, too. Oh, and get up out of that chair and stop surfing the net, too!
Re: The "proof" of which has "better" "security" will be how widespread this worm is compared to slammer or code red or nimda.
It's not so easy to compare as that. Unless you consider an OS being widely deployed to be a security flaw -- in which case Linux is doomed to be as bad as Windows if it succeeds...
If an OS, let's call it X, is rare, worms can't spread quickly, just because they can't find instances to spread to. The effects of this are very non-linear, with the popular OS being at a very major disadvantage.
If X is rare, few felons will have the expertise to attack it.
If X is rare, few felons will have the motivation to attack it.
Conversely, if X is widespread, and hated among felons, it will be an attractive target.
If X is commonly business-critical, a great deal of publicity comes with each attack, and felons can get glory from the press and praise from their felonious peers.
The bottom line is that there are many factors beyond the security of an OS in how widespread a worm becomes. In addition to the issues I listed above, consider how quicly patches get pushed out, which depends both on OS support for security patch distribution and administrator attentiveness. Consider the bandwidth of the typical connection, the nature of the hole, how likely it is to be blocked by non-OS firewalls, etc. etc.
So I'm afraid the MS vs Linux security question isn't going to be settled at all by comparing this worm's spread to any other worm, nor even by comparing any large population of worms.
Sorry -- it would be nice if the world were so simple.
I'm not a chemist either, but I remember enough from my metalurgy class at MIT to add something here -- plus I have practical experience with both polymers and metals in adverse circumstances: boats.
What you say is true, but misses the real issue: Polymers are generally *relatively* stable, compared to most things. And right next to the polymer is something which is decidedly NOT stable!
Have you heard of thermite? The thermite reaction involves the oxidation of aluminum, and aluminum is VERY hungry. It will actually steal oxygen from from iron oxide (rust) under the right circumstances -- and release a lot of heat in the process. (But aluminum oxide is more voluminous and stronger than aluminum, and quickly seals off exposed aluminum behind a thin layer of oxide. That's why your beer can isn't on fire inside your fridge.
But exposed aluminum is very reactive. Freshly-machined shavings of aluminum can catch fire.
It's the aluminum that's reacting. What is it reacting with? Several possibilities that I see: 1) Impurities in the polymer. 2) Impurities in the alumnimum deposition. 3) Impurities in the adhesive. 4) Impurities migrating through the polymer. 5) Impurities migrating in from the edge via the adhesive and/or the metal layer itself.
It could be a combination:
Dissimilar metals in contact set up a battery, if anything is available to complete the circuit. For example, put a brass screw into salt water, and before you know it, all the zinc will disolve and the screw will crumble into copper dust. Either metal by itself will do just fine in salt water -- so long as they're not touching.
Impurities in the aluminum might be stable unless they get, e.g. moisture migration along the adhesive from the outside edge.
Impurities could be in the polymer, or generated from degradation of same, but that wouldn't explain the observed failure pattern, so I think we can tentatively rule those out as contributing factors.
From this, what you say about storing them under low humidity and temperature makes sense -- but I bet this only comes from theory. It would take a LOT of CD's and a LOT of time, and a LOT of work to reach this conclusion validly through statistical observation.
How about a "CarbonCopy OS"?
Besides, after all the proprietary HTML elements they've come up with for IE, chemical elements are a natural area for them to branch out.
That's not the history I remember. The Xerox Alto started being distributed outside Xerox in 1974. The VAX 11/780 came out in 1978. The CADR, I believe, came out in 1979, and LMI Inc. was founded in 1981, the same year as the Apollo. But if I got my years wrong, maybe you can relate the years as you remember them.
Your years are about right. What's misleading, though is 1) suggesting that the Alto was "commercially distributed", as opposed to being made available to various educational institutions, and 2) suggesting that the Alto is in the same category. The Alto was an important ancestor, but it lacked the address space, horsepower, and disk space needed for commercialization, and wasn't ever commercialized.
It's also puzzling that you leave out Symbolics from your chronology; the LM-1 (a commercial repackaging of the CADR) is what came out in '79; the CADR was in use for quite some time before that within MIT.
Even in the late 1980's, you could get a Sun workstation with color screen for a few thousand dollars, while a black-and-white Lisp machine with similar performance would set you back tens of thousands of dollars.
Yes, that's true, depending on what you mean by "similar performance". Sun went agressively after the low end of the market, with tiny configurations. These weren't very useful configurations (no disks, in many cases!) but got their foot in the door. But we're talking about a decade later here. There is no question that after a while, price/performance (if it was hardware speed that was important, not programmer speed) began to favor high-volume conventional architectures (for economic, not architectural reasons)
.
Not for a modern view of source level debugging. Until Genera 8, the Symbolics debugger would still show you an instruction backtrace for compiled Lisp code, and for interpreted code might give you an S-expression if you asked really nicely. None of that was tied to the source code in a way that any modern IDE does, or in the way that even GNU Emacs did at the time for C. (As an aside, Symbolics didn't use real overlapping windows as late as the late 1980's because of the oddball ways window contents were aliased into rectangular arrays.)
I'm afraid your memory or your experience has led you astray here. Perhaps you were not aware that there were two debuggers? Perhaps you were not aware that with a single keystroke in either debugger, you could edit the precise location of the call in question?
And as for overlapping vs non-overlapping windows -- in fact, windows could overlap from the very first. This was a UI style issue, not
any issue of how bitmaps were handled. I used to occasionally overlap windows back in those days; these days, I generally maximize my windows and switch between them, for the same reasons Symbolics windows were full-screen by default. (But not always, and the market and world at large has clearly concluded that overlapping windows are preferred).
Many of the techniques that are common in today's advanced programming and debugging environments were pioneered on the Lisp Machine, and there are many useful debugging features that are still not available in today's C/C++/Java environments.
I think Smalltalk-80 has a much bigger claim to that than the Lisp Machine. In retrospect, it's just amazing to me how far ahead the Smalltalk-80 system was (you can try it out for yourself: go to www.squeak.org).
If you can name any Lisp machine debugging features absent from modern Java IDEs, I'd certainly like to know about them.
Smalltalk certainly deserves credit. Many of the ideas Lisp built on came from Smalltalk. (However, Smalltalk-80 post-dates the infusion of smalltalk ideas into Lisp by quite a few years).
However, there are still a lot of lisp-debugger features missing. Edit & continue is just now beginning to make it into some environments -- but can you go back to an earlier frame, change the arguments, and re-invoke that frame (discarding the more recent ones cleanly (i.e. properly executing finally clauses, etc.)? Can you type in a new function, and invoke it -- without adding it to the source code first?
And sadly, I have yet to encounter a debugger as robust as the Lisp machine debugger. The uniform poor quality of debuggers has always been a mystery to me.
Finally, I think you and Chris are in agreement in saying that it was not lack of features that was the problem with Lisp. I'm pretty sure Chris would agree with your final paragraph; I know I do. But I would go further, and argue that even the right design tradeoff does not yield success; good marketing, good business practices, good sales, and good financing are all important to success. But the most critical is perhaps good timing. Compare the fates of Dylan and Java for another perspective on how each of these factors affect success.
Slashdot Mirror
Then how do you account for automobiles? Or bicycles? Riding horses? The Segway is the only common mode of transport where you actually stand up the entire time. And yet it's the only one that suffers from fools yelling "lazy". If you can stand, then get rid of your car, your bike, and stay off public transit, too. Oh, and get up out of that chair and stop surfing the net, too!
It's not so easy to compare as that. Unless you consider an OS being widely deployed to be a security flaw -- in which case Linux is doomed to be as bad as Windows if it succeeds...
If an OS, let's call it X, is rare, worms can't spread quickly, just because they can't find instances to spread to. The effects of this are very non-linear, with the popular OS being at a very major disadvantage.
If X is rare, few felons will have the expertise to attack it.
If X is rare, few felons will have the motivation to attack it.
Conversely, if X is widespread, and hated among felons, it will be an attractive target.
If X is commonly business-critical, a great deal of publicity comes with each attack, and felons can get glory from the press and praise from their felonious peers.
The bottom line is that there are many factors beyond the security of an OS in how widespread a worm becomes. In addition to the issues I listed above, consider how quicly patches get pushed out, which depends both on OS support for security patch distribution and administrator attentiveness. Consider the bandwidth of the typical connection, the nature of the hole, how likely it is to be blocked by non-OS firewalls, etc. etc.
So I'm afraid the MS vs Linux security question isn't going to be settled at all by comparing this worm's spread to any other worm, nor even by comparing any large population of worms.
Sorry -- it would be nice if the world were so simple.
Remember, Disney blocks access to their OWN works. "Last chance to buy XXX for the next 10 years." seems to accompany each release on DVD.
They don't seem to do it to drive up prices. My ownly theory is that they want to encourage piracy.
I'm not a chemist either, but I remember enough from my metalurgy class at MIT to add something here -- plus I have practical experience with both polymers and metals in adverse circumstances: boats.
What you say is true, but misses the real issue: Polymers are generally *relatively* stable, compared to most things. And right next to the polymer is something which is decidedly NOT stable!
Have you heard of thermite? The thermite reaction involves the oxidation of aluminum, and aluminum is VERY hungry. It will actually steal oxygen from from iron oxide (rust) under the right circumstances -- and release a lot of heat in the process. (But aluminum oxide is more voluminous and stronger than aluminum, and quickly seals off exposed aluminum behind a thin layer of oxide. That's why your beer can isn't on fire inside your fridge.
But exposed aluminum is very reactive. Freshly-machined shavings of aluminum can catch fire.
It's the aluminum that's reacting. What is it reacting with? Several possibilities that I see:
1) Impurities in the polymer.
2) Impurities in the alumnimum deposition.
3) Impurities in the adhesive.
4) Impurities migrating through the polymer.
5) Impurities migrating in from the edge via the adhesive and/or the metal layer itself.
It could be a combination:
Dissimilar metals in contact set up a battery, if anything is available to complete the circuit. For example, put a brass screw into salt water, and before you know it, all the zinc will disolve and the screw will crumble into copper dust. Either metal by itself will do just fine in salt water -- so long as they're not touching.
Impurities in the aluminum might be stable unless they get, e.g. moisture migration along the adhesive from the outside edge.
Impurities could be in the polymer, or generated from degradation of same, but that wouldn't explain the observed failure pattern, so I think we can tentatively rule those out as contributing factors.
From this, what you say about storing them under low humidity and temperature makes sense -- but I bet this only comes from theory. It would take a LOT of CD's and a LOT of time, and a LOT of work to reach this conclusion validly through statistical observation.
How about a "CarbonCopy OS"? Besides, after all the proprietary HTML elements they've come up with for IE, chemical elements are a natural area for them to branch out.
That's not the history I remember. The Xerox Alto started being distributed outside Xerox in 1974. The VAX 11/780 came out in 1978. The CADR, I believe, came out in 1979, and LMI Inc. was founded in 1981, the same year as the Apollo. But if I got my years wrong, maybe you can relate the years as you remember them.
Your years are about right. What's misleading, though is 1) suggesting that the Alto was "commercially distributed", as opposed to being made available to various educational institutions, and 2) suggesting that the Alto is in the same category. The Alto was an important ancestor, but it lacked the address space, horsepower, and disk space needed for commercialization, and wasn't ever commercialized.
It's also puzzling that you leave out Symbolics from your chronology; the LM-1 (a commercial repackaging of the CADR) is what came out in '79; the CADR was in use for quite some time before that within MIT.
Even in the late 1980's, you could get a Sun workstation with color screen for a few thousand dollars, while a black-and-white Lisp machine with similar performance would set you back tens of thousands of dollars.
Yes, that's true, depending on what you mean by "similar performance". Sun went agressively after the low end of the market, with tiny configurations. These weren't very useful configurations (no disks, in many cases!) but got their foot in the door. But we're talking about a decade later here. There is no question that after a while, price/performance (if it was hardware speed that was important, not programmer speed) began to favor high-volume conventional architectures (for economic, not architectural reasons)
.Not for a modern view of source level debugging. Until Genera 8, the Symbolics debugger would still show you an instruction backtrace for compiled Lisp code, and for interpreted code might give you an S-expression if you asked really nicely. None of that was tied to the source code in a way that any modern IDE does, or in the way that even GNU Emacs did at the time for C. (As an aside, Symbolics didn't use real overlapping windows as late as the late 1980's because of the oddball ways window contents were aliased into rectangular arrays.)
I'm afraid your memory or your experience has led you astray here. Perhaps you were not aware that there were two debuggers? Perhaps you were not aware that with a single keystroke in either debugger, you could edit the precise location of the call in question?
And as for overlapping vs non-overlapping windows -- in fact, windows could overlap from the very first. This was a UI style issue, not any issue of how bitmaps were handled. I used to occasionally overlap windows back in those days; these days, I generally maximize my windows and switch between them, for the same reasons Symbolics windows were full-screen by default. (But not always, and the market and world at large has clearly concluded that overlapping windows are preferred).
Many of the techniques that are common in today's advanced programming and debugging environments were pioneered on the Lisp Machine, and there are many useful debugging features that are still not available in today's C/C++/Java environments. I think Smalltalk-80 has a much bigger claim to that than the Lisp Machine. In retrospect, it's just amazing to me how far ahead the Smalltalk-80 system was (you can try it out for yourself: go to www.squeak.org). If you can name any Lisp machine debugging features absent from modern Java IDEs, I'd certainly like to know about them.
Smalltalk certainly deserves credit. Many of the ideas Lisp built on came from Smalltalk. (However, Smalltalk-80 post-dates the infusion of smalltalk ideas into Lisp by quite a few years).
However, there are still a lot of lisp-debugger features missing. Edit & continue is just now beginning to make it into some environments -- but can you go back to an earlier frame, change the arguments, and re-invoke that frame (discarding the more recent ones cleanly (i.e. properly executing finally clauses, etc.)? Can you type in a new function, and invoke it -- without adding it to the source code first?
And sadly, I have yet to encounter a debugger as robust as the Lisp machine debugger. The uniform poor quality of debuggers has always been a mystery to me.
Finally, I think you and Chris are in agreement in saying that it was not lack of features that was the problem with Lisp. I'm pretty sure Chris would agree with your final paragraph; I know I do. But I would go further, and argue that even the right design tradeoff does not yield success; good marketing, good business practices, good sales, and good financing are all important to success. But the most critical is perhaps good timing. Compare the fates of Dylan and Java for another perspective on how each of these factors affect success.