The real problem is that most humans don't know what they're doing or why they're doing it half the time, and these studies simply point out some of the implications of that...
Why would I as a corporate admin, ever choose to pay for what I can get free? The blunt answer is so that it keeps working next year and the year after and so on. So that if/when you do have a problem you get an answer better than "Fix it yourself" or "Read The Fine Manual". Basically, corporate wants to pay so that if/when they have a problem someone is interested, and not just because it's an interesting problem. The free support may even be better than paid support, but if nobody is interested, you're SOL.
"in order to address the concerns of security, privacy and intellectual property. The plan, revealed for the first time to NEWSWEEK, is... Palladium, and it's one of the riskiest ventures the company has ever attempted."
When addressing concerns of security, privacy and intellectual property is a "risky venture", it's hard to take any of it seriously. Sounds like Microsoft can't patch a gopher hole and is grasping at straws.
Nope. Open Source DECREASES the window of exposure. With open source everybody, the good "examiner/reviewer" and the bad attacker, has he ability to find a flaw by analyzing source as soon as the source is released. With closed source the attacker needs to analyze the assembly code or needs to drive black box attacks from the outside. The latter method is also quite useable with open source. So, other things equal, residual flaws will be discovered earlier with open source and the window of exposure will be smaller with open source. the flawed system has "a flaw" since it is installed and running somewhere and such it is open for an attack even if no one ever will know how to attack it. Correct. Open source will tend to start out better because the coder knows that the flaws are a bit more exposed and cannot be "safely hidden".
True, but just because they can doesn't mean that they do. One of the great myths about open source is that *anyone* can just dip in and discover a bug and how to fix it. That simply isn't true. Yes, but. First thing in eradicating bugs is to be able to reproduce it. Then you need to somehow bring together knowledge of the bug and knowledge of the program. Open Source increases the options, and over time tends toward more bug-free programs.
As someone not in the know, I can still make some educated guesses. IBM support is very good, and very expensive. The "grassroots" support for IBM laptops is probably effectively better than IBM's. It's just not the kind of support that IBM is good at. "the smaller companies can undercut on price and geeks are thrifty" The whole desktop business is going in the direction of WalMart's cheap Lindows computers, high-volume low-margin commodity. Even RedHat is not particularly interested in the "desktop" business. A laptop is really just a very portable desktop.
It's hard to imagine that Thinkpads would suddenly stop running Linux. Most of the people running Linux on laptops will continue to do so, with or without overt support from IBM. The support for Linux on IBM Thinkpads may well work better if it does *not* come from within IBM. IBM needs to focus on what they do well, big expensive hardware that does not make mistakes and furthermore catches any and all of the mistakes that "can't happen". Anything that resembles consumer electronics is best left to somebody else. I've got a Compaq Presario (among others). Based on that one computer I would never buy any Compaq server. IBM sells big-business grade, not hacker-grade. Product and support are part of it, but most important, the customer is buying a piece of IBM.
*complete* specs for.xls,.doc,.ppt et al. _Microsoft_ doesn't have complete specs for.xls.doc.ppt et al I don't doubt you, but imagine the fun if Microsoft is liable for consequential damages like lost profits due to incomplete specs.
and their intellectual property placed firmly into the public domain all source code for Windows should be destroyed And the difference is? One advantage of open source. The coders have some incentive to not embarass themselves.
Could I read just one article on Slashdot that doesn't rehash Microsoft bashing (the Nimda thing) that's old news? I'll stop bringing it up when I get less than a 200 Nimda attempts a day on my server, OK? Now for the coup de grace. Apache finally gets an exploit. Assuming unpatched on 32-bit Linux or BSD, he will get more trouble from the Nimda attempts than from Apache attempts. (Windows and 64-bit UNIX do need to be patched.)
what is the point of hacking to 'own' someones system? "They" is not "you". "Your" misdeeds are traceable back to "them" not to "you". That's one of the key points of Code Red. The victims advertise.
Too bad MS shipped the Nimda virus with their Korean version of.Net Visual Studio
Come on. This really looks childish. That's an irrelevant story. Just let the facts speak for themselves or you lose credibility.
Ok. Facts. Security is a perimeter type thingee. Everything is relevant, particularly any odd anecdotal accounts of lapses. Credibility. Slashdot tries to make the headlines "interesting". Should I see what's up or go back to work? I've seen no indications that Slashdot has ever attempted to be "fair, balanced, unbiased". What is ironic is that Slashdot has become the best source of unbiased information for supporting Microsoft software. Microsoft is big and arrogant. The only effective antidote is public ridicule.
You are right that PHP was designed for a web-based environment. PHP originally stood for Personal Home Page. To turn your html into php, just change the.html to.php Embed your programming in <?php and ?> tags. All variables have a $ prefix. Somehow they managed to NOT screw up the language design. PHP4 is good! Access to APIs such as sql servers is through native calls, rather than attempting some kind of worst common denominator. Arrays are comparable to Perl Arrays and or Hash, simultaneously. Very handy for result sets which are accessed by name and/or column name, simultaneously.
"PHP now has register_globals turned off by default" This is to prevent malicious browsers from setting what are supposed to be program variables. info.php as <?phpinfo()?%gt is your friend.
if Microsoft had resolved an issue (i know stop laughing and read on) in 24 hours would it have been posted on here in this manner?? I suspect it would have had a different slant to it Considering it took something over three days before a search for Code Red on microsoft.com returned anything when microsoft apparently already had a patch for a couple of weeks, methinks the slant would be incredulity.
ALL software has bugs and issues and exploits Agreed, with the possible exception of some stuff by Donald Knuth. but all software eventually gets patched Nope. dBASE5 for DOS has a serious bug which will never be patched. (Under certain conditions, "reading" a file will cause the initial 6 bytes of several other files to be reqritten with stale cached data. Ugly.)
Just try that in Microsoft Windows. Webserver downtime what? About 10 or 15 seconds, I'd guess.
Copy the config.status from the old apache install directory. Copy modules (I have 'fastcgi' and 'php4') in src/modules from the old directory. Call config.status, type 'make'. Make a backup copy of the old httpd Type 'make install' 'apachectl stop' and 'apachectl start'
Ok, ok, I'm a newbie and still not quite used to the idea of replacing a program while it's still running. Kudos on the ordering of the steps. Murphy's Law might get the better of you, but it will have to work pretty hard to do it.
We dont know how long Apache/CERT knew about the flaw. Apache probably already had the patch ready to go, just wanted to make sure vendors that redistribute Apache (ie, Red Hat, Suse, etc) were aware of the flaw The irony is that it is the vendors of Apache for Microsoft Windows who are most in need of the patch. On 32-bit Linux or BSD seems like it's just a pretty lame DoS attempt. I would expect more trouble from Code Red and friends filling up error logs.
Apache exploits are pretty hard to come by these days. Miss this one and it will be a long dry spell until anybody finds another one. Like a media feeding frenzy, rationality seems to vanish. Two hour notice and a broken patch, judging from other posts. ISS comes off looking pretty juvenile. There seems to be some indications that Apache was aware of this from another source, so there is some possibility that ISS jumped the gun to avoid being shunted out of the limelight.
Overall Apache comes out smelling like a rose.
"On the Windows and Netware platforms, Apache runs one multithreaded child process to service requests. The teardown and subsequent setup time to replace the lost child process presents a significant interruption of service. As the Windows and Netware ports create a new process and reread the configuration, rather than fork a child process, this delay is much more pronounced than on other platforms." "... Using any multithreaded model, all concurrent requests currently served by the affected child process will be lost."
Sounds like a good reason to run Apache on Linux/BSD/UNIX. (Well they did claim that Apache 1.3 wasn't really stable on Microsoft Windows;)
Linux will always have bugs Any MS marketing execs probably passed out cold when they read this
Yep. Methinks IBM "gets it" and Microsoft can't. Reality. Just because a program has bugs does not mean that you can find any or will ever run into one. If you are paying high dollars for a Linux system, you want "other people" to be running into the bugs and fixing them as much as possible. Much cheaper.
Linus sees using a debugger as a crutch for not understanding what is going on in your code. A debugger is a tool like any other. A wrench is a tool like any other. Not very good at hammering nails though. A debugger is good for showing state through *one* execution path and makes it easy to catch superficial bugs that show up that way. Something like an operating system needs to stay valid over *all* execution paths and a debugger tends to be more counterproductive. Then you get the fun situations where a program works if it's being debugged and not if it's not.
The real problem is that most humans don't know what they're doing or why they're doing it half the time, and these studies simply point out some of the implications of that...
Like the visible part of an iceberg.
for people who don't like to think.
More accurately, for people who have better things to think about.
Why would I as a corporate admin, ever choose to pay for what I can get free?
The blunt answer is so that it keeps working next year and the year after and so on. So that if/when you do have a problem you get an answer better than "Fix it yourself" or "Read The Fine Manual". Basically, corporate wants to pay so that if/when they have a problem someone is interested, and not just because it's an interesting problem. The free support may even be better than paid support, but if nobody is interested, you're SOL.
"in order to address the concerns of security, privacy and intellectual property. The plan, revealed for the first time to NEWSWEEK, is... Palladium, and it's one of the riskiest ventures the company has ever attempted."
When addressing concerns of security, privacy and intellectual property is a "risky venture", it's hard to take any of it seriously. Sounds like Microsoft can't patch a gopher hole and is grasping at straws.
I think this was tried sometime back with the results of the Psychic Friends Network being slightly more helpful.
Nope. Open Source DECREASES the window of exposure.
With open source everybody, the good "examiner/reviewer" and the bad attacker, has he ability to find a flaw by analyzing source as soon as the source is released.
With closed source the attacker needs to analyze the assembly code or needs to drive black box attacks from the outside.
The latter method is also quite useable with open source. So, other things equal, residual flaws will be discovered earlier with open source and the window of exposure will be smaller with open source.
the flawed system has "a flaw" since it is installed and running somewhere and such it is open for an attack even if no one ever will know how to attack it.
Correct. Open source will tend to start out better because the coder knows that the flaws are a bit more exposed and cannot be "safely hidden".
True, but just because they can doesn't mean that they do. One of the great myths about open source is that *anyone* can just dip in and discover a bug and how to fix it. That simply isn't true.
Yes, but.
First thing in eradicating bugs is to be able to reproduce it.
Then you need to somehow bring together knowledge of the bug and knowledge of the program.
Open Source increases the options, and over time tends toward more bug-free programs.
It's really dificult to notice a flaw in CLOSED source code.
Only if you never use the program.
As someone not in the know, I can still make some educated guesses.
IBM support is very good, and very expensive. The "grassroots" support for IBM laptops is probably effectively better than IBM's. It's just not the kind of support that IBM is good at.
"the smaller companies can undercut on price and geeks are thrifty"
The whole desktop business is going in the direction of WalMart's cheap Lindows computers, high-volume low-margin commodity. Even RedHat is not particularly interested in the "desktop" business. A laptop is really just a very portable desktop.
It's hard to imagine that Thinkpads would suddenly stop running Linux. Most of the people running Linux on laptops will continue to do so, with or without overt support from IBM. The support for Linux on IBM Thinkpads may well work better if it does *not* come from within IBM.
IBM needs to focus on what they do well, big expensive hardware that does not make mistakes and furthermore catches any and all of the mistakes that "can't happen". Anything that resembles consumer electronics is best left to somebody else. I've got a Compaq Presario (among others). Based on that one computer I would never buy any Compaq server.
IBM sells big-business grade, not hacker-grade. Product and support are part of it, but most important, the customer is buying a piece of IBM.
*complete* specs for .xls, .doc, .ppt et al. .xls .doc .ppt et al
_Microsoft_ doesn't have complete specs for
I don't doubt you, but imagine the fun if Microsoft is liable for consequential damages like lost profits due to incomplete specs.
and their intellectual property placed firmly into the public domain
all source code for Windows should be destroyed
And the difference is?
One advantage of open source. The coders have some incentive to not embarass themselves.
Could I read just one article on Slashdot that doesn't rehash Microsoft bashing (the Nimda thing) that's old news?
I'll stop bringing it up when I get less than a 200 Nimda attempts a day on my server, OK?
Now for the coup de grace. Apache finally gets an exploit. Assuming unpatched on 32-bit Linux or BSD, he will get more trouble from the Nimda attempts than from Apache attempts. (Windows and 64-bit UNIX do need to be patched.)
what is the point of hacking to 'own' someones system?
"They" is not "you". "Your" misdeeds are traceable back to "them" not to "you".
That's one of the key points of Code Red. The victims advertise.
"Xbox Live has military grade security to ensure no cheaters, no hackers, and no viruses."
Whose military? The Three Stooges come to mind, somehow.
Too bad MS shipped the Nimda virus with their Korean version of .Net Visual Studio
Come on. This really looks childish. That's an irrelevant story. Just let the facts speak for themselves or you lose credibility.
Ok. Facts.
Security is a perimeter type thingee. Everything is relevant, particularly any odd anecdotal accounts of lapses.
Credibility. Slashdot tries to make the headlines "interesting". Should I see what's up or go back to work? I've seen no indications that Slashdot has ever attempted to be "fair, balanced, unbiased". What is ironic is that Slashdot has become the best source of unbiased information for supporting Microsoft software.
Microsoft is big and arrogant. The only effective antidote is public ridicule.
You are right that PHP was designed for a web-based environment. PHP originally stood for Personal Home Page. .html to .php
To turn your html into php, just change the
Embed your programming in <?php and ?> tags.
All variables have a $ prefix.
Somehow they managed to NOT screw up the language design. PHP4 is good!
Access to APIs such as sql servers is through native calls, rather than attempting some kind of worst common denominator.
Arrays are comparable to Perl Arrays and or Hash, simultaneously. Very handy for result sets which are accessed by name and/or column name, simultaneously.
"PHP now has register_globals turned off by default"
This is to prevent malicious browsers from setting what are supposed to be program variables. info.php as <?phpinfo()?%gt is your friend.
if Microsoft had resolved an issue (i know stop laughing and read on) in 24 hours would it have been posted on here in this manner?? I suspect it would have had a different slant to it
Considering it took something over three days before a search for Code Red on microsoft.com returned anything when microsoft apparently already had a patch for a couple of weeks, methinks the slant would be incredulity.
ALL software has bugs and issues and exploits
Agreed, with the possible exception of some stuff by Donald Knuth.
but all software eventually gets patched
Nope. dBASE5 for DOS has a serious bug which will never be patched. (Under certain conditions, "reading" a file will cause the initial 6 bytes of several other files to be reqritten with stale cached data. Ugly.)
meanwhile the MS VM remains solid and fast for most client-side apps.
So does GWBASIC. Your point is?
Just try that in Microsoft Windows.
Webserver downtime what? About 10 or 15 seconds, I'd guess.
Copy the config.status from the old apache install directory.
Copy modules (I have 'fastcgi' and 'php4') in src/modules from the old directory.
Call config.status, type 'make'.
Make a backup copy of the old httpd
Type 'make install'
'apachectl stop' and 'apachectl start'
Ok, ok, I'm a newbie and still not quite used to the idea of replacing a program while it's still running. Kudos on the ordering of the steps. Murphy's Law might get the better of you, but it will have to work pretty hard to do it.
We dont know how long Apache/CERT knew about the flaw. Apache probably already had the patch ready to go, just wanted to make sure vendors that redistribute Apache (ie, Red Hat, Suse, etc) were aware of the flaw
The irony is that it is the vendors of Apache for Microsoft Windows who are most in need of the patch. On 32-bit Linux or BSD seems like it's just a pretty lame DoS attempt. I would expect more trouble from Code Red and friends filling up error logs.
Apache exploits are pretty hard to come by these days. Miss this one and it will be a long dry spell until anybody finds another one. Like a media feeding frenzy, rationality seems to vanish. Two hour notice and a broken patch, judging from other posts. ISS comes off looking pretty juvenile. There seems to be some indications that Apache was aware of this from another source, so there is some possibility that ISS jumped the gun to avoid being shunted out of the limelight.
Overall Apache comes out smelling like a rose.
"On the Windows and Netware platforms, Apache runs one multithreaded child
process to service requests. The teardown and subsequent setup time to
replace the lost child process presents a significant interruption of
service. As the Windows and Netware ports create a new process and reread
the configuration, rather than fork a child process, this delay is much
more pronounced than on other platforms."
"... Using any multithreaded model, all concurrent requests currently served by the affected child process will be lost."
Sounds like a good reason to run Apache on Linux/BSD/UNIX.
(Well they did claim that Apache 1.3 wasn't really stable on Microsoft Windows;)
Linux will always have bugs
Any MS marketing execs probably passed out cold when they read this
Yep. Methinks IBM "gets it" and Microsoft can't.
Reality. Just because a program has bugs does not mean that you can find any or will ever run into one. If you are paying high dollars for a Linux system, you want "other people" to be running into the bugs and fixing them as much as possible. Much cheaper.
Linus sees using a debugger as a crutch for not understanding what is going on in your code.
A debugger is a tool like any other.
A wrench is a tool like any other. Not very good at hammering nails though.
A debugger is good for showing state through *one* execution path and makes it easy to catch superficial bugs that show up that way. Something like an operating system needs to stay valid over *all* execution paths and a debugger tends to be more counterproductive. Then you get the fun situations where a program works if it's being debugged and not if it's not.