It'll be interesting to see how/if Real pulls through now that Helix is mostly open source. The only other example that comes to mind of a company that started with a proprietary product and then took it open when the sky darkened is Netscape. I'd wager Real may be looking at a similar fate. AOL would have probably devoured them already if not for their current financial system. It's pretty clear that AOL likes Real in the same way they like Nullsoft, as Real is distributed with Netscape.
So the question is... will Real survive, will they be eaten up by a bigger fish, or will they tank and GPL their source?
If this was just a matter of click-wrap licensing, M$ wouldn't be able to get away with what they're doing here, which is basically saying "We have a lien on your business because you're in a contract with us." BlueLight probably had engaged in a so-called "Open|Select License Agreement" with Microsoft, which is their form of site licensing. I'm pretty certain that to get such a license agreement, you have to physically sign a contract and give Bill a sizeable check each time you renew your license.
If this is the case, and it probably is... what Microsoft is doing here is scary and legal. It's no different than you leasing a multifunction copier from Xerox and then making plans to sell your business and Xerox asking a court to enjoin you from doing so due to their unsecured interest in your company.
Real has realized that if they do not embrace OSS, they will be swept under the rug by the combined might of M$ (Windows Media) and AOL (Nullsoft Winamp).
If we see a real open-source Real-compatible player out there soon, it will fill a huge void in the rich media world. Combined with the existence of WMA codecs, we will at last have a simple, spam-free player that just works. No one uses RealOne or WMP or even QuickTime because they want to. These players are slow, intrusive, proprietary, and often loaded with spyware. Bring on the OSS alternative!
>I would rather each department of the government
>be allowed to implement its own solutions, at least
>based on my experiences working for large corporations
>(where the right hand often doesn't know what the right
>middle finger is doing).
Point taken... however, that's a tenet that applies to private industry moreso than the US military. The Department of Defense as a whole is rigorously structured, with the most flexible bits being the research-oriented agencies like DARPA (and look what we got from them, or at least funded by them. I like this interweb thingy.)
For the rest of the military, though, standardization is very important. With reports of military boxes running NT and with clever admin passwords like "Administrator" and "password", I'd argue that a standardized, secure and uniform approach would be appropriate here. The sooner the better, with reasonable transition times. This report, however swiss cheesy to joe/.er, is a step forward for the nation. (Doesn't that sound good?:P)
I'll wager that the feds' decision not to mark, say, other MTAs is safe may be due to lack of adoption in the public and age of the code. Let's face it, Sendmail touches just about every email sent, anytime and anywhere. It's old code that has its nuances known. Sure, it's not a daemon but a demon, but by the DoD's logic, it can be trusted while something like qmail cannot.
>They are making progress in their own little way.:)
Military intelligence... if we ever understood it, we'd be arrested and our brains classified.:P
While the Navy has its much-farted-upon attempt to build Win2k-powered "Smart Ships", the NSA has been developing SELinux (Security Enhanced Linux), their homebrew kernel.
It seems that the right hand doesn't see what the left hand is doing. That's the USA federal government for you. However, based on the existance of the "safe" FOSS list, perhaps the DoD is rethinking their investments in eN Tee. I sure hope so, for the sake of national security. Meh.
... to gut my Dell Inspiron 7500 laptop with the stupid monitor latches that won't stop breaking, get some chassis fans and a flip-top thing for an old-school NES (mine is missing that flipping cartridge thing) and make myself a Lintendo. w00t.
Routing, whether to/dev/null|Null0|127.0.0.1 or to a real address isn't really CPU intensive at all... until you have to route hundreds of requests per millisecond. Then things start getting icky. Hardware emulation of a null interface may help... but you're still _routing_. There's still computation involved, ergo the potential for denial of service on the router. So null routes supplemented by specialized hardware are a defense, but not a solution, and as the above mentioned article says, that wouldn't work with full-scale real address spoofing.
The fact that Darwin appears to have a CISC-oriented design begs the hunch that Apple doesn't want to tie themselves to the MPPC platform. This could mean one of two things:
1) Apple wants to ensure that should Motorola ever tank on them, they have the ability to port OS X to a wider range of processors, and/or
2) Apple has specific possible platforms for OS X in mind in the future. x86 immediately comes to mind. Granted, this is a rumor that has run its course a million times over, but don't jump to conclusions. This may not mean an OS X port to x86. Looking at OS X and its multiple APIs (Carbon, Cocoa, Classic, "native Java"...) perhaps Apple may be plotting to roll out some sort of cross-platform API that would enable Mac OS X apps to run on, say, Windows. Support for such an API close to the kernel, as Apple would be capable of producing, would make such an API much faster on the Mac than, say, applications based on certain browser cum cross-platform COM system.
> I don't understand how nuking XP and NT will
> solve DDOS. Surely you can launch a DOS attack
> from linux and FreeBSD just as easily.
You might want to count the number of DDoS blackhat tools on
this page if you believe that. Look how many specifically mention IIS, for one. The actions taken by most of these tools require root priveleges for most Unices (true, that's not too hard for a cracker to get provided the admin is dumb, but compare to the extremely-insecure-out-of-box state of Windows in general, and 9x and XP in particular (XP having the Raw Sockets API, which can be compared to a sign that says "use me as a zombie", and 9x having no security whatsoever).
The Linux fans cheered this technology because it probably wouldn't be hard to de-WinCEXP it. KDE 3 or fluxbox and that nifty electromagnetic pen thingy? Niiiiiice.
Let Bill keep making the gadgets and let us keep hacking it, I say. Less Redmond money spent on DRM and evil things.
Most of the reasons why have been said before but to sum it up...
Sending quench packets back to the routers feeding you DDoS packets, and eventually back to the host in question, is a good idea in theory. Kinda like communism. But in practice it won't work. First of all, there are the CPU strain resources on the routers and hosts. With DDoS, you have thousands if not more hosts all banging on your router, and your router is going to get a cardio workout going through its tables and deciding what gets throttled. Secondly, the return addresses on DDoS zombie packets are forged a good 80% of the time, meaning that you'll probably only hit 2 or 3 routers upstream with your quench packets.
A better solution? Null routes come to mind, but there are the CPU issues again. I'd like to see some "technology" similar to this where a customer of a commercial ISP could modify firewall rules on the _ISP's_ router to control traffic coming into their netblock. Perhaps a few routers upstream too. This really appears to be the only logical "quick fix" at the network level for DDoS.
A better fix would be to keep those zombies from ever coming into play by nuking everyone's NT/XP boxes, but that'll have to wait until penguins or daemons rule the planet.
Slashdot Mirror
It'll be interesting to see how/if Real pulls through now that Helix is mostly open source. The only other example that comes to mind of a company that started with a proprietary product and then took it open when the sky darkened is Netscape. I'd wager Real may be looking at a similar fate. AOL would have probably devoured them already if not for their current financial system. It's pretty clear that AOL likes Real in the same way they like Nullsoft, as Real is distributed with Netscape.
So the question is... will Real survive, will they be eaten up by a bigger fish, or will they tank and GPL their source?
If this was just a matter of click-wrap licensing, M$ wouldn't be able to get away with what they're doing here, which is basically saying "We have a lien on your business because you're in a contract with us." BlueLight probably had engaged in a so-called "Open|Select License Agreement" with Microsoft, which is their form of site licensing. I'm pretty certain that to get such a license agreement, you have to physically sign a contract and give Bill a sizeable check each time you renew your license.
If this is the case, and it probably is... what Microsoft is doing here is scary and legal. It's no different than you leasing a multifunction copier from Xerox and then making plans to sell your business and Xerox asking a court to enjoin you from doing so due to their unsecured interest in your company.
Real has realized that if they do not embrace OSS, they will be swept under the rug by the combined might of M$ (Windows Media) and AOL (Nullsoft Winamp).
If we see a real open-source Real-compatible player out there soon, it will fill a huge void in the rich media world. Combined with the existence of WMA codecs, we will at last have a simple, spam-free player that just works. No one uses RealOne or WMP or even QuickTime because they want to. These players are slow, intrusive, proprietary, and often loaded with spyware. Bring on the OSS alternative!
>I would rather each department of the government
/.er, is a step forward for the nation. (Doesn't that sound good? :P)
>be allowed to implement its own solutions, at least
>based on my experiences working for large corporations
>(where the right hand often doesn't know what the right
>middle finger is doing).
Point taken... however, that's a tenet that applies to private industry moreso than the US military. The Department of Defense as a whole is rigorously structured, with the most flexible bits being the research-oriented agencies like DARPA (and look what we got from them, or at least funded by them. I like this interweb thingy.)
For the rest of the military, though, standardization is very important. With reports of military boxes running NT and with clever admin passwords like "Administrator" and "password", I'd argue that a standardized, secure and uniform approach would be appropriate here. The sooner the better, with reasonable transition times. This report, however swiss cheesy to joe
I'll wager that the feds' decision not to mark, say, other MTAs is safe may be due to lack of adoption in the public and age of the code. Let's face it, Sendmail touches just about every email sent, anytime and anywhere. It's old code that has its nuances known. Sure, it's not a daemon but a demon, but by the DoD's logic, it can be trusted while something like qmail cannot.
:)
:P
>They are making progress in their own little way.
Military intelligence... if we ever understood it, we'd be arrested and our brains classified.
While the Navy has its much-farted-upon attempt to build Win2k-powered "Smart Ships", the NSA has been developing SELinux (Security Enhanced Linux), their homebrew kernel.
It seems that the right hand doesn't see what the left hand is doing. That's the USA federal government for you. However, based on the existance of the "safe" FOSS list, perhaps the DoD is rethinking their investments in eN Tee. I sure hope so, for the sake of national security. Meh.
... to gut my Dell Inspiron 7500 laptop with the stupid monitor latches that won't stop breaking, get some chassis fans and a flip-top thing for an old-school NES (mine is missing that flipping cartridge thing) and make myself a Lintendo. w00t.
Routing, whether to /dev/null|Null0|127.0.0.1 or to a real address isn't really CPU intensive at all... until you have to route hundreds of requests per millisecond. Then things start getting icky. Hardware emulation of a null interface may help... but you're still _routing_. There's still computation involved, ergo the potential for denial of service on the router. So null routes supplemented by specialized hardware are a defense, but not a solution, and as the above mentioned article says, that wouldn't work with full-scale real address spoofing.
The fact that Darwin appears to have a CISC-oriented design begs the hunch that Apple doesn't want to tie themselves to the MPPC platform. This could mean one of two things:
1) Apple wants to ensure that should Motorola ever tank on them, they have the ability to port OS X to a wider range of processors, and/or
2) Apple has specific possible platforms for OS X in mind in the future. x86 immediately comes to mind. Granted, this is a rumor that has run its course a million times over, but don't jump to conclusions. This may not mean an OS X port to x86. Looking at OS X and its multiple APIs (Carbon, Cocoa, Classic, "native Java"...) perhaps Apple may be plotting to roll out some sort of cross-platform API that would enable Mac OS X apps to run on, say, Windows. Support for such an API close to the kernel, as Apple would be capable of producing, would make such an API much faster on the Mac than, say, applications based on certain browser cum cross-platform COM system.
Just some speculation here.
> I don't understand how nuking XP and NT will
> solve DDOS. Surely you can launch a DOS attack
> from linux and FreeBSD just as easily.
You might want to count the number of DDoS blackhat tools on this page if you believe that. Look how many specifically mention IIS, for one. The actions taken by most of these tools require root priveleges for most Unices (true, that's not too hard for a cracker to get provided the admin is dumb, but compare to the extremely-insecure-out-of-box state of Windows in general, and 9x and XP in particular (XP having the Raw Sockets API, which can be compared to a sign that says "use me as a zombie", and 9x having no security whatsoever).
The Linux fans cheered this technology because it probably wouldn't be hard to de-WinCEXP it. KDE 3 or fluxbox and that nifty electromagnetic pen thingy? Niiiiiice. Let Bill keep making the gadgets and let us keep hacking it, I say. Less Redmond money spent on DRM and evil things.
Most of the reasons why have been said before but to sum it up...
Sending quench packets back to the routers feeding you DDoS packets, and eventually back to the host in question, is a good idea in theory. Kinda like communism. But in practice it won't work. First of all, there are the CPU strain resources on the routers and hosts. With DDoS, you have thousands if not more hosts all banging on your router, and your router is going to get a cardio workout going through its tables and deciding what gets throttled. Secondly, the return addresses on DDoS zombie packets are forged a good 80% of the time, meaning that you'll probably only hit 2 or 3 routers upstream with your quench packets.
A better solution? Null routes come to mind, but there are the CPU issues again. I'd like to see some "technology" similar to this where a customer of a commercial ISP could modify firewall rules on the _ISP's_ router to control traffic coming into their netblock. Perhaps a few routers upstream too. This really appears to be the only logical "quick fix" at the network level for DDoS.
A better fix would be to keep those zombies from ever coming into play by nuking everyone's NT/XP boxes, but that'll have to wait until penguins or daemons rule the planet.