Slashdot Mirror

So out of curiosity, I removed all (Updated) lines from the results,and all blatantly duplicate exploits, and also any non-linux exploits, just to see how they matched up. Keep in mind that I kept alot of the php, apache , and other exploits in the list but did not add them to windows despite that these also affect windows and should be included. The numbers I got were 784 to 672, Linux to Windows. Then, because in the windows list they strictly kept to vulnerabilities that only affected windows and not multiple platforms, I took out any vulnerabilties from the linux list that would 100% for certain be cross-platform and affect Windows as well. The list reduced to 669, which is right on par with Windows (keeping in mind that I left some exploits in the list because I was only say 80% or 90% sure and so I gave Windows the benefit of the doubt). Just out of curiosity, I then tookout any linux vulnerabilities that were specific to one vendor(i.e. Red Hat, Suse, Gentoo, Debian) for a number of reasons which I won't get into. This brought it down to 639. That last number doesn't really represent anything other than a curiosity of mine.

I was originally going to have a disclaimer stating that these numbers are accurate probably to within +-30, but since they were so close, I don't think it's necessary. One observation I've noted is that the Linux vulnerabilities are spread over a far greater variety of applications. Another thing worth noting is that it looks like Windows can not easily be effectively secured as long as security updates are done as they are currently. Most linux distros (Red Hat/Fedora, Suse, Debian, Gentoo, etc.. off the top of my head) provide a central repository that will update everything on your system for you. This appears to be a much more optimal method of applying updates. If nothing else, these results show that not just core functionality, but also supporting functionalities must be kept up to date and are just as much of a security problem, if not more so. Linux distributions support such update methodolgies natively, Windows does not.

It appears that Linux is the winner here no matter how you look at it, and we didn't even begin to look at severity or the time from disclosure to time patched (which isn't available using the information in the report, but my inclination is to say that open source wins hands down here, call me biased if you will). For the files that I referenced and modified to get these numbers, you can get the windows list here and the first linux list here (the one with 784 exploits, not 669). These lists are not 100% accurate as I'm sure the regexs I used missed some things, or were too greedy in other cases. I also did some manual pruning that wasnt appropriate to be done with regexs, which I'm sure wasn't 100% accurate either, but these lists are close.
Regards,
Steve

So out of curiosity, I removed all (Updated) lines from the results,and all blatantly duplicate exploits, and also any non-linux exploits, just to see how they matched up. Keep in mind that I kept alot of the php, apache , and other exploits in the list but did not add them to windows despite that these also affect windows and should be included. The numbers I got were 784 to 672, Linux to Windows. Then, because in the windows list they strictly kept to vulnerabilities that only affected windows and not multiple platforms, I took out any vulnerabilties from the linux list that would 100% for certain be cross-platform and affect Windows as well. The list reduced to 669, which is right on par with Windows (keeping in mind that I left some exploits in the list because I was only say 80% or 90% sure and so I gave Windows the benefit of the doubt). Just out of curiosity, I then tookout any linux vulnerabilities that were specific to one vendor(i.e. Red Hat, Suse, Gentoo, Debian) for a number of reasons which I won't get into. This brought it down to 639. That last number doesn't really represent anything other than a curiosity of mine.

I was originally going to have a disclaimer stating that these numbers are accurate probably to within +-30, but since they were so close, I don't think it's necessary. One observation I've noted is that the Linux vulnerabilities are spread over a far greater variety of applications. Another thing worth noting is that it looks like Windows can not easily be effectively secured as long as security updates are done as they are currently. Most linux distros (Red Hat/Fedora, Suse, Debian, Gentoo, etc.. off the top of my head) provide a central repository that will update everything on your system for you. This appears to be a much more optimal method of applying updates. If nothing else, these results show that not just core functionality, but also supporting functionalities must be kept up to date and are just as much of a security problem, if not more so. Linux distributions support such update methodolgies natively, Windows does not.

It appears that Linux is the winner here no matter how you look at it, and we didn't even begin to look at severity or the time from disclosure to time patched (which isn't available using the information in the report, but my inclination is to say that open source wins hands down here, call me biased if you will). For the files that I referenced and modified to get these numbers, you can get the windows list here and the first linux list here (the one with 784 exploits, not 669). These lists are not 100% accurate as I'm sure the regexs I used missed some things, or were too greedy in other cases. I also did some manual pruning that wasnt appropriate to be done with regexs, which I'm sure wasn't 100% accurate either, but these lists are close.
Regards,
Steve

Hey, I'd write a long reply, but Niles Eldridge has already said it better than I ever could. Not sure if I have permission to pass this along, but eh whatever:) Here is a thing Niles wrote that is about the sixth extinction, extremely informative.
Regards,
Steve

Here is a cellular automata simulator I've written. Right now I'm working on a simulator for Conway's Game of Life, here. Next I'm doing an interactive whiteboard using AJAX and then I was thinking about a ray caster like the one in the article but a bit more optimized and possible doing textures. The possibilities with <canvas> are pretty significant, I think we're on the verge of a web revolution.
Regards,
Steve

Here is a cellular automata simulator I've written. Right now I'm working on a simulator for Conway's Game of Life, here. Next I'm doing an interactive whiteboard using AJAX and then I was thinking about a ray caster like the one in the article but a bit more optimized and possible doing textures. The possibilities with <canvas> are pretty significant, I think we're on the verge of a web revolution.
Regards,
Steve

The canvas is W3C compliant. Read this. It works in Safari, Firefox 1.5+ , and I heard Opera 9.1 beta or something like that. Its better than forcing users to use a plugin, an FPS in javascript is really cool (in a geek kind of way). I've done some work with the canvas too here in case anyone is interested.
Regards,
Steve

There have been a few ray casting engines for the canvas that have been written and improved upon over each other. Here is the first known ray caster written with the canvas, it is grainy, but can get around 24 FPS on the right system, you can also adjust the amount of jaggedness for a loss of some framerate. I've developed a few things with the canvas. Most recently this, but am currently working on Conway's Game of Life, and then an optimized ray caster to try and get more FPS out of it. Interesting thing to note is that the canvas widget currently only has a 2d context, but is supposed to get a 3d context as well sometime in the future. That would be really cool to have native 3D rendering support in a browser, until then though writing a 3d engine using the 2d canvas is a fun experiment. I'm curremtly testing AJAX to see if it can hold its own in real time communication with the server so that a multiplayer FPS can be made, its looking like something is plausible so I urge anyone who can to try and make it a reality. I'll give it a shot if I get some spare time.
Regards,
Steve