It would be interesting to see the number of different copyright notices contained within all that source code, and then to present the notices in groups, like GPL GPL2, etc..
Also, I would really like to find "patient 0" for sourcecode. For example, is there a common library or utility function (perhaps Hex2Ascii?) that *everybody* uses? Well, who wrote it first?
And in a similar vein, who are the "top 5-10-100" authors of open source code by use, reuse, KLOC, etc.. Not of too much use unless I were awarding the Nobel prize for programming, or perhaps creating a list of individuals for the RIAA to sue, after their done with their other useless lawsuits.:)
But seriously, spyware has little to do with Microsoft and their shoddy products. MS is definitely to blame for inadequate security, poor mimicry GUI designs, and an attrocious "embrace and extend" attitude towards open standards.
That said, Spyware is more the result of the combination of the insane ROI for spywarers coupled with poor user education. One might argue that Windows allows users to have too many privileges yet this perception only minimally impairs the dedicated keystroke logger.
Fault anyone, fault doubleclick. And the wholly inadequate privacy and confidentiality laws of the US governement.
How does this really change anything? Most applications can, today, be patched w/o a reboot - but the vendor isn't willing to take that chance
I often cue up multiple application patches, ignore the [Reboot] dialog and the program restarts without incidence.
The main problem is that individual application owners aren't willing to take the risk (read: they do not fully understand the code their offshoring overlords provided them) so simply mandate that a reboot is required.
While the changes in the OS supporting incremental patch management may be great (if decades belated), it isn't likely to impact data centers much either - DCs schedule patches during maintenance windows when a reboot just makes sense and they operate in an HA/cluster configuration that will tolerate the downing of an individual node for maintenance.
I put this article strongly into the dumb pile - it's a no-op other than the media grab to stay off more individuals from threatening-to-switch-to-linux-but-really-just-try ing-to-negotiate-a-better-license.
This really should be indexed for inflation. By next month, the $100 laptop project should be changed to compensate for those on a fixed income.
I thought we would have learned by now that refusing to index the cost and benefit of items (Alternative Minimum Tax, 401(k) maximum contributions, defined pension plans) is just the wrong way to go.
By the time the $100 laptop takes off, $100 will buy you 4 gallons of milk, 3 loaves of bread, and 5 sticks of butter. And who wants to compute when there's buttery milky bread to injest!
What a waste of silicon, to have a 50MB install image loaded on a CD (or DVD) when that media can hold so much more! I think it is cheaper to have the sources located on the same media than provide and fund a website to download the same resources. It's also easier, this way, to keep the sources in sync with the actual binaries loaded on the install kit.
Add to this everyone else's comments that geeze, nobody needs the source - it already is available separately in a completely optional downloadable format.
My take is - hey, the sources occupy so much little space (when compressed), that maybe we should only distribute the sources and people can compile it themselves. Oh, but I guess that would disuade the script kiddies from running linux...
Accctually, you couldn't still go to the www..com site because it would 302 redirect you to a site that, ending in xxx, would be blocked.
You'd want to setup a reverse proxy on the.com website. Umm, not that I would consider doing such a thing.;-)
Well stated and very true; client-side javascript has been a problem for a very long time.
The one hope I have for Ajax is that it be so widely used and adopted as to properly separate middleware calls from presentation logic. This way, XML documents can be very tightly checked against a schema (and use an application firewall built for schema validation) and something simple like urlscan will suffice for keeping the presentation logic 'in check'.
Unfortunately, those application firewalls often have to be "dumbed down" to urlscan or mod_security levels, based on the high support requirements which they require as a direct result of the huge increase in client side javascript that renders the rules engine mostly useless.
To wit, I'd like to hear how any of this application level firewalls are protecting against Ajax? (Well, perhaps an XML firewall like the recently-bought-out Datapower) Or how to teach an application firewall that 1) the cookies may change as a result of client-side javascript, 2) hidden form values may change as a result of client-side javascript, or 3) completely new forms may be created and submitted as a result of client-side javascript.
Application firewalls will continue to be a niche player - or deployed en masse as a stop gap measure to satisfy regulatory compliance requirements.
What needs first and foremost is to integrate security into the SDLC. Until that happens, we will simply continue to change the type, model, and price of fancy bandaids.
Slashdot Mirror
Also, I would really like to find "patient 0" for sourcecode. For example, is there a common library or utility function (perhaps Hex2Ascii?) that *everybody* uses? Well, who wrote it first?
And in a similar vein, who are the "top 5-10-100" authors of open source code by use, reuse, KLOC, etc.. Not of too much use unless I were awarding the Nobel prize for programming, or perhaps creating a list of individuals for the RIAA to sue, after their done with their other useless lawsuits. :)
But seriously, spyware has little to do with Microsoft and their shoddy products. MS is definitely to blame for inadequate security, poor mimicry GUI designs, and an attrocious "embrace and extend" attitude towards open standards.
That said, Spyware is more the result of the combination of the insane ROI for spywarers coupled with poor user education. One might argue that Windows allows users to have too many privileges yet this perception only minimally impairs the dedicated keystroke logger.
Fault anyone, fault doubleclick. And the wholly inadequate privacy and confidentiality laws of the US governement.
I often cue up multiple application patches, ignore the [Reboot] dialog and the program restarts without incidence.
The main problem is that individual application owners aren't willing to take the risk (read: they do not fully understand the code their offshoring overlords provided them) so simply mandate that a reboot is required.
While the changes in the OS supporting incremental patch management may be great (if decades belated), it isn't likely to impact data centers much either - DCs schedule patches during maintenance windows when a reboot just makes sense and they operate in an HA/cluster configuration that will tolerate the downing of an individual node for maintenance.
I put this article strongly into the dumb pile - it's a no-op other than the media grab to stay off more individuals from threatening-to-switch-to-linux-but-really-just-try ing-to-negotiate-a-better-license.
I thought we would have learned by now that refusing to index the cost and benefit of items (Alternative Minimum Tax, 401(k) maximum contributions, defined pension plans) is just the wrong way to go.
By the time the $100 laptop takes off, $100 will buy you 4 gallons of milk, 3 loaves of bread, and 5 sticks of butter. And who wants to compute when there's buttery milky bread to injest!
Add to this everyone else's comments that geeze, nobody needs the source - it already is available separately in a completely optional downloadable format.
My take is - hey, the sources occupy so much little space (when compressed), that maybe we should only distribute the sources and people can compile it themselves. Oh, but I guess that would disuade the script kiddies from running linux...
Accctually, you couldn't still go to the www..com site because it would 302 redirect you to a site that, ending in xxx, would be blocked. You'd want to setup a reverse proxy on the .com website. Umm, not that I would consider doing such a thing. ;-)
They've had the virus out in beta since Windows 98, so it's good to see them beta the antidote now.
!:/me slaps the New York Times around a bit with a large trout.
Oh wait, that's called XMPP, SIP, and H.232 technologies.
See: http://www.tipic.com/taxonomy/view/or/29
The one hope I have for Ajax is that it be so widely used and adopted as to properly separate middleware calls from presentation logic. This way, XML documents can be very tightly checked against a schema (and use an application firewall built for schema validation) and something simple like urlscan will suffice for keeping the presentation logic 'in check'.
Actually, by the time the 12 monkey man was on the plane, it was too late. You see, the vials were opened as part of a TSA security check!
To wit, I'd like to hear how any of this application level firewalls are protecting against Ajax? (Well, perhaps an XML firewall like the recently-bought-out Datapower) Or how to teach an application firewall that 1) the cookies may change as a result of client-side javascript, 2) hidden form values may change as a result of client-side javascript, or 3) completely new forms may be created and submitted as a result of client-side javascript.
Application firewalls will continue to be a niche player - or deployed en masse as a stop gap measure to satisfy regulatory compliance requirements.
What needs first and foremost is to integrate security into the SDLC. Until that happens, we will simply continue to change the type, model, and price of fancy bandaids.
"RIAA, you're doing a heck of a job!"