My calc was flawed (the # of 9s in my head didn't match what I typed.)
I'm citing your comment as a "reasonable standard" for enterprise grade equipment in another comment I'm writing, walking through the author's paper and clarifying important points.
I read through the article, and was honestly shocked at some of the claims the author made when describing Windows in relation to Linux.
Note that the purpose of this post is not to say "omg windows >>>> linux all you penguin lovers rot in hell" like a lot of this story will be. I am merely trying to clarify some of the author's points.
"Myth: Safety in Small Numbers"
"Furthermore, we should see more successful attacks against Apache than against IIS, since the implication of the myth is that the problem is one of numbers, not vulnerabilities.
Yet this is precisely the opposite of what we find, historically."
Running through 3GB of archived log files, from Apache running on 2003 Enterprise Server, I have concluded the following:
54% of attacks against IIS (Unicode traversal, buffer overflow, cgi, alternate data streams, etc.)
46% of attacks against Apache (htpasswd.exe, httpd.conf,.htaccess, some odd batchfile script attacks with args to copy httpd.conf into htdocs, etc.)
"Precisely the opposite" is hardly the right phrase to use in this situation. Sampling error among different web sites (due to different audiences, traffic rates, etc.) could easily account for the fact that IIS out-edged Apache here.
As for the *successful* part of the author's claim, there was a 0% success rate across all queries directed at servers I either have access to logs on, or directly control. I have also experienced Apache servers being compromised (more often due to user-induced security holes than design flaws.) but in the end, the user leaving a filedrop which allows php scripts to execute, and such, is as dangerous as a buffer overflow. They are each different but functionally equivilant ways to circumvent the security of the system it is running on.
"But it does notexplain why Windows is nowhere to be found in the top 50 list. Windows does not reset its uptime counter. Obviously, no Windows-based web site has been able to run long enough without rebooting to rank among the top 50 for uptime."
Part of the Windows operating system's underlying design involves its file locking symantics. Files in-use by the operating system, providing needed functionality, can't be easily replaced while the system is running. Windows solution? The in-use-file replacement tool is able to change the bits on disk, but not the memory addresses they map to. So, the copy in memory doesn't match the copy on disk -- and the copy in memory is the old (flawed) copy. This is rectified by...you guessed it...refreshing the copy in memory. And what's the easiest way to do this? Reboot the server and reload it from the disk, if the module you're talking about happens to be, say, the Local Security Authority or the Windows Kernel.
I mentioned (with some flawed math) (http://slashdot.org/comments.pl?sid=126724&cid=10 600161) in more detail the reasons Windows servers are often down there on the patches. I did miscalculate availablilty. My servers average in the 99.9952% range. Which means they're down for a few hours a year. Sure, not carrier grade, but not too shabby either. Well within the reasonable expectations of most businesses. (Source: http://slashdot.org/comments.pl?sid=126724&cid=106 00658 by hehman) Note that the situations where Windows is likely to be used probably aren't nuclear power plants, airplane control software, etc. Thus, the additional powers of 9 aren't really a factor.
"Myth: Open Source is Inherently Dangerous"
I agree with the author here. Having the source code doesn't really have an impact as to whether or not a hacker can find an exploit -- there are enough tools to automate exploit finding in streamed data, especially web connections.
"Myth: Conclusions Based on Single Metrics"
Another valid point. One can spin statistics any way you want to, and have the math be perfectly valid, to reach a meaningless conclusion. Anyone who's taken statis
The author bashes Enterprise Server 2003 as being unstable, quoting MS's average uptime of around 59 days as evidence of this.
What people forget to mention is that MS security patches seem to like reboots, do the way filelocking works on Windows. Thus, whenever a "critical" flaw is released, they have to either patch it with a workaround (firewall rules, etc.) or they need to reboot the server.
When I was running an internal-only Enterprise 2003 server (behind several firewalls, no public IP) the only reboots I ever experienced were those related to environmental factors: the power went out for longer than the UPS could keep the server online for; etc.
After I started maintaining an externally-accessible 2003 server, I configured autopatching on it from Windows Update, and it reboots itself about once a month.
According to my calculations, this still meets the 99.9999% reliability that MS claims the server to be able to provide, on enterprise-grade hardware (and what I am running on is decidedly not enterprise-grade, unless eMachines has recently broken into the enterprise market and I forgot to read the press release.) Reboots take about 4 minutes to shut down, restart, wait for the services to resolve themselves, and try again. If I was so inclined, I could tweak this to be lower (1 whole minute is that the web server loads before the network module does, can't find an IP to bind to because IP isn't enabled yet, and fails to load, then waits to retry.)
It's a different design philosophy. My systems don't get "crufty" and crash, but they do have to be rebooted to apply security fixes. However, 4 minutes a month isn't a hardship, and anyone who says it is needs to either look into something transparently redundant, fault-tolerant, or reevaulate why they are so dependant on that one system in the first place.
Yes, and I own a portable MP3 player, and have the connections necessary to make it play through my car's stereo, but I still burn mp3s onto CD and play them through the mp3cd player in my dash.
Why?
Because it's easier that way. And because there are less parts to worry about.
Portable is good for personal use...dockable is okay (Delphi SkyFi receiver comes to mind.)
I prefer individual devices for different settings. In-dash, desktop, pc-attached, personal.
They're not really going to deploy this over broadband, are they?
if SBC has a properly-installed multicast architecture, then it's possibly feasible, but do you have any idea the amount of bandwidth that's going to require?
Either they're running fibre to the door, and have datacenters full of the new clustering Cisco routers, or they're going to run into some hardware limits REAL fast.
HP's embedded network printers that I've seen work just the same as regular printers in Windows....just they're on a TCP socket instead of a physical port.
I've never had a problem with RDP and printing, but ymmv.
I think its because at 0.5c, time has dialated to the point that the added velocities of the light together is canceleld out by the fact that it takes longer for the light to cross the same space you're in, due to time going slower?
and velocity is distance over time...so make t go up, as v goes up, and you'll still get some sane answer.
It wouldn't make *less* Windows apps, if the.NET CLR could be installed on non-Windows platforms. It would, however, make non-Windows-devloped applications run on Windows without being recompiled..NET CLR is a bytecode interpreter/just-in-time compiler. You can code.NET in VB.Net or C#, depending on your preferences; they both compile down to the common bytecode, which is then executed by the.Net Common Language Runtime. Similar to Java, except the CLR actually hosts several languages with bytecode, rather than just a single one.
If MS released the.NET CLR, officially, for other OSes (i.e. their runtime deal) they could gain a huge developer base.
They wouldn't really have to open-source the entire language; just the runtime. Provide enough specifications that people could write a legitimate Linux.NET CLR or something.
That'd be a java killer right there. C# beats Java hands down in my opinion (and I like Java a fair amount.)
Personally, I fully support the war on drugs -- even "harmless" drugs such as marijuana. After watching people go from "straight-edge" never-do-that type personalities, to becoming complete wastes-of-oxygen in very short duration to their usage, I feel entitled to have a strong opinion on it.
It is not, however, being pursued correctly. Users should be prosecuted, but not with jail. Make it like violating the law on underaged consumption of alcohol. Driving or not, you lose your driver's license, fines, etc. Make the fines for being caught with low-schedule controlled substances something insane, and require mandatory forfiture of driver's license, any other federal licenses acquired (FFL, hell even a HAM radio license.) Can't pay? Tough shit. Your posessions will be siezed and sold at auction.
Putting recreational drug users in jail only crowds prisons -- but they definitely should prosecute them.
As for distributors, or those with "more" dangerous substances, those are the ones they should be going with. Make the fine for distributors a mandatory year in jail per gram carried over 4 grams. Anyone with about an eighth or lower, fines...more than that, felony.
This is one of the few areas I staunchly support the conservatives on...I consider myself a rather good liberal, but drugs and gun control are two places I think very differently.
In SeaQuest 2032 or whatever, the earth's atmosphere was destroyed by global warming; there weren't enough rainforests to process CO2. So they build massive CO2 scrubbing refineries.
Personally, I like OE2K3's blocking of bad filetypes...It's great for the lusers who I gave it to, who used to download those things and run them. Now their computer tells them not to...and they don't.
Why does Slashdot seem to think that every piece of DRM, no matter where implemented or why, is a bad thing?
It's perfectly appropriate in this case. You are not permitted by law to download copies of books...or photocopy books in the copy machine, beyond a certain number of pages.
So why do we want to break Google's DRM, used in exactly the way DRM should be used? You have free access to something you wouldn't otherwise access, but you still don't own it, and thus can't copy it.
Slashdot,and F/OSS in general, distaste for authority is never going to allow it to be taken seriously. Until people learn to get a clue that they don't need to break something just because it exists and they don't like it, F/OSS will never be taken seriously precisely for this reason.
If I don't like some new windows you installed, I can't break them. That's illegal.
Why is it any different to break the obfuscation of the material Google is letting you access as a courtesy?
All of my code I've used that makes use of register_globals sanity checks everything...strip all codes, tags, slashes, etc. out of every input, and check to make sure the submission comes from a valid established and authenticated session.
Those things make it pretty good, in my experience.
I know in Windows, you can assign the mouse cursor to numpad arrow keys.
Enable that, and bind the knobs to NUMPADUP and NUMPADDOWN, NUMPADLEFT, NUMPADRIGHT respectively, and you're set.
My calc was flawed (the # of 9s in my head didn't match what I typed.)
I'm citing your comment as a "reasonable standard" for enterprise grade equipment in another comment I'm writing, walking through the author's paper and clarifying important points.
I read through the article, and was honestly shocked at some of the claims the author made when describing Windows in relation to Linux.
.htaccess, some odd batchfile script attacks with args to copy httpd.conf into htdocs, etc.)
Note that the purpose of this post is not to say "omg windows >>>> linux all you penguin lovers rot in hell" like a lot of this story will be. I am merely trying to clarify some of the author's points.
"Myth: Safety in Small Numbers"
"Furthermore, we should see more successful attacks against Apache than against IIS, since the implication of the myth is that the problem is one of numbers, not vulnerabilities.
Yet this is precisely the opposite of what we find, historically."
Running through 3GB of archived log files, from Apache running on 2003 Enterprise Server, I have concluded the following:
54% of attacks against IIS (Unicode traversal, buffer overflow, cgi, alternate data streams, etc.)
46% of attacks against Apache (htpasswd.exe, httpd.conf,
"Precisely the opposite" is hardly the right phrase to use in this situation. Sampling error among different web sites (due to different audiences, traffic rates, etc.) could easily account for the fact that IIS out-edged Apache here.
As for the *successful* part of the author's claim, there was a 0% success rate across all queries directed at servers I either have access to logs on, or directly control. I have also experienced Apache servers being compromised (more often due to user-induced security holes than design flaws.) but in the end, the user leaving a filedrop which allows php scripts to execute, and such, is as dangerous as a buffer overflow. They are each different but functionally equivilant ways to circumvent the security of the system it is running on.
"But it does notexplain why Windows is nowhere to be found in the top 50 list. Windows does not reset its uptime counter. Obviously, no Windows-based web site has been able to run long enough without rebooting to rank among the top 50 for uptime."
Part of the Windows operating system's underlying design involves its file locking symantics. Files in-use by the operating system, providing needed functionality, can't be easily replaced while the system is running. Windows solution? The in-use-file replacement tool is able to change the bits on disk, but not the memory addresses they map to. So, the copy in memory doesn't match the copy on disk -- and the copy in memory is the old (flawed) copy. This is rectified by...you guessed it...refreshing the copy in memory. And what's the easiest way to do this? Reboot the server and reload it from the disk, if the module you're talking about happens to be, say, the Local Security Authority or the Windows Kernel.
I mentioned (with some flawed math) (http://slashdot.org/comments.pl?sid=126724&cid=10 600161) in more detail the reasons Windows servers are often down there on the patches. I did miscalculate availablilty. My servers average in the 99.9952% range. Which means they're down for a few hours a year. Sure, not carrier grade, but not too shabby either. Well within the reasonable expectations of most businesses. (Source: http://slashdot.org/comments.pl?sid=126724&cid=106 00658 by hehman) Note that the situations where Windows is likely to be used probably aren't nuclear power plants, airplane control software, etc. Thus, the additional powers of 9 aren't really a factor.
"Myth: Open Source is Inherently Dangerous"
I agree with the author here. Having the source code doesn't really have an impact as to whether or not a hacker can find an exploit -- there are enough tools to automate exploit finding in streamed data, especially web connections.
"Myth: Conclusions Based on Single Metrics"
Another valid point. One can spin statistics any way you want to, and have the math be perfectly valid, to reach a meaningless conclusion. Anyone who's taken statis
yeah.......we'll go with that.
Thinking 4 "nines" in my head, I typed 4 nines after the decimal point.
They're not quite the same thing.
I do but not with me, I believe it to be on a brochure I have back at my office.
So, when I get back there, I'd be happy to look for you.
The author bashes Enterprise Server 2003 as being unstable, quoting MS's average uptime of around 59 days as evidence of this.
What people forget to mention is that MS security patches seem to like reboots, do the way filelocking works on Windows. Thus, whenever a "critical" flaw is released, they have to either patch it with a workaround (firewall rules, etc.) or they need to reboot the server.
When I was running an internal-only Enterprise 2003 server (behind several firewalls, no public IP) the only reboots I ever experienced were those related to environmental factors: the power went out for longer than the UPS could keep the server online for; etc.
After I started maintaining an externally-accessible 2003 server, I configured autopatching on it from Windows Update, and it reboots itself about once a month.
According to my calculations, this still meets the 99.9999% reliability that MS claims the server to be able to provide, on enterprise-grade hardware (and what I am running on is decidedly not enterprise-grade, unless eMachines has recently broken into the enterprise market and I forgot to read the press release.) Reboots take about 4 minutes to shut down, restart, wait for the services to resolve themselves, and try again. If I was so inclined, I could tweak this to be lower (1 whole minute is that the web server loads before the network module does, can't find an IP to bind to because IP isn't enabled yet, and fails to load, then waits to retry.)
It's a different design philosophy. My systems don't get "crufty" and crash, but they do have to be rebooted to apply security fixes. However, 4 minutes a month isn't a hardship, and anyone who says it is needs to either look into something transparently redundant, fault-tolerant, or reevaulate why they are so dependant on that one system in the first place.
Yes, and I own a portable MP3 player, and have the connections necessary to make it play through my car's stereo, but I still burn mp3s onto CD and play them through the mp3cd player in my dash.
Why?
Because it's easier that way. And because there are less parts to worry about.
Portable is good for personal use...dockable is okay (Delphi SkyFi receiver comes to mind.)
I prefer individual devices for different settings. In-dash, desktop, pc-attached, personal.
Will a single XM subscription allow you to listen on n many XM devices?
If my 1 XM subscription would allow me to listen on an XMPCR, car, computer, handheld, whatever, I'd be interested in it; otherwise, no.
I stand corrected. Thanks for the clarification!
They're not really going to deploy this over broadband, are they?
if SBC has a properly-installed multicast architecture, then it's possibly feasible, but do you have any idea the amount of bandwidth that's going to require?
Either they're running fibre to the door, and have datacenters full of the new clustering Cisco routers, or they're going to run into some hardware limits REAL fast.
HP's embedded network printers that I've seen work just the same as regular printers in Windows....just they're on a TCP socket instead of a physical port.
I've never had a problem with RDP and printing, but ymmv.
I think its because at 0.5c, time has dialated to the point that the added velocities of the light together is canceleld out by the fact that it takes longer for the light to cross the same space you're in, due to time going slower?
and velocity is distance over time...so make t go up, as v goes up, and you'll still get some sane answer.
I am not a physicist.
c:\windows||c:\winnt can be better represented by the environment variable
%WINDIR%\system32\drivers\etc\hosts
It wouldn't make *less* Windows apps, if the .NET CLR could be installed on non-Windows platforms. It would, however, make non-Windows-devloped applications run on Windows without being recompiled. .NET CLR is a bytecode interpreter/just-in-time compiler. You can code .NET in VB.Net or C#, depending on your preferences; they both compile down to the common bytecode, which is then executed by the .Net Common Language Runtime. Similar to Java, except the CLR actually hosts several languages with bytecode, rather than just a single one.
If MS released the .NET CLR, officially, for other OSes (i.e. their runtime deal) they could gain a huge developer base.
.NET CLR or something.
They wouldn't really have to open-source the entire language; just the runtime. Provide enough specifications that people could write a legitimate Linux
That'd be a java killer right there. C# beats Java hands down in my opinion (and I like Java a fair amount.)
Personally, I fully support the war on drugs -- even "harmless" drugs such as marijuana. After watching people go from "straight-edge" never-do-that type personalities, to becoming complete wastes-of-oxygen in very short duration to their usage, I feel entitled to have a strong opinion on it.
It is not, however, being pursued correctly. Users should be prosecuted, but not with jail. Make it like violating the law on underaged consumption of alcohol. Driving or not, you lose your driver's license, fines, etc. Make the fines for being caught with low-schedule controlled substances something insane, and require mandatory forfiture of driver's license, any other federal licenses acquired (FFL, hell even a HAM radio license.) Can't pay? Tough shit. Your posessions will be siezed and sold at auction.
Putting recreational drug users in jail only crowds prisons -- but they definitely should prosecute them.
As for distributors, or those with "more" dangerous substances, those are the ones they should be going with. Make the fine for distributors a mandatory year in jail per gram carried over 4 grams. Anyone with about an eighth or lower, fines...more than that, felony.
This is one of the few areas I staunchly support the conservatives on...I consider myself a rather good liberal, but drugs and gun control are two places I think very differently.
If the control sequence is embedded in the network protocol, that'd be no problem. Nobody has the equipment to mess around on cell bands anyways.
How do the CO2 scrubbers in space vehicles work?
In SeaQuest 2032 or whatever, the earth's atmosphere was destroyed by global warming; there weren't enough rainforests to process CO2. So they build massive CO2 scrubbing refineries.
Would something like that be viable?
If there's a physical connection, then you might lose a little due to attenuation of the medium, but not due to distance.
How tough would it be to remove 8- and 16-bit X86 instructions, and map them to 32-bit ones?
i.e. 8-bit pointers, 16-bit pointers padded with leading zeros internally.
Significantly reduce complexity.
Personally, I like OE2K3's blocking of bad filetypes...It's great for the lusers who I gave it to, who used to download those things and run them. Now their computer tells them not to...and they don't.
I propose mandatory, permanant subnet bans for anyone who quotes Fight Club in any kind of a discussion, ever.
I hate that movie so much, and the idiots it spawned, you have no idea.
Why does Slashdot seem to think that every piece of DRM, no matter where implemented or why, is a bad thing?
It's perfectly appropriate in this case. You are not permitted by law to download copies of books...or photocopy books in the copy machine, beyond a certain number of pages.
So why do we want to break Google's DRM, used in exactly the way DRM should be used? You have free access to something you wouldn't otherwise access, but you still don't own it, and thus can't copy it.
Slashdot,and F/OSS in general, distaste for authority is never going to allow it to be taken seriously. Until people learn to get a clue that they don't need to break something just because it exists and they don't like it, F/OSS will never be taken seriously precisely for this reason.
If I don't like some new windows you installed, I can't break them. That's illegal.
Why is it any different to break the obfuscation of the material Google is letting you access as a courtesy?
Just curious, then, where does that put bisexuals?
Sexuality is a long gamut of values...a simple 2, 3, or even 4-block characterization is too general.
All of my code I've used that makes use of register_globals sanity checks everything...strip all codes, tags, slashes, etc. out of every input, and check to make sure the submission comes from a valid established and authenticated session.
Those things make it pretty good, in my experience.