There's exactly one reason why this wasn't done before. DVDs can be mailed. Their form factor permits it. That's the only reason. Well, that and the fact that Blockbuster and the other companies loved charging $4 per rental. All NetFlix has done is shift around the cost model a bit.
Yet another bullshit patent. These should be laughed out of court.
Great. Then you can set up YOUR server to let everything right in. It's your option to get plenty of spam! Maybe the rest of us will use a delay, though.
Making the tether out of a mesh is a pretty cool idea, but all you've done is extend the lifetime by some factor. What you really want to do is find a way to repair the damage relatively easily.
Picture two mesh tethers between the endpoints. Each tether is made of a series of lines. The lines come out of the tether and are _unwoven_ from the mesh weave. They are then looped back around and _reweaved_ into the tether going back in the other direction. Each line within a tether is actually participating in a complete loop, there are back again. Each line is an unbroken circle.
The tether is then _moved_ through the continuous loop, unweaving and weaving at each end. In this way the tether acts like a belt.
If a break occurs, then movement of the belt/tether will eventually bring the break to one of the terminals, where it can be repaired. The weave localizes the damage and ensures that the line will not simply fly off into space. The repaired line is then rewoven into the loop.
A belt-like tether like this can last indefinitely.
The real issue that's going to be litigated here is to what extent SCO can claim damages from another company if the infringement is tiny. The very best thing that SCO can muster, in this case, is that they've identified a subroutine or two that seem to be close or identifical to something they claim is their own code. Let's suppose that this is true. What effect does this small infringment have on the entirety of Linux? Can they claim that Linux is an infringing product when only a tiny part of it contains (arguably) any SCO code?
The court is going to have to struggle with this part/whole issue. If I had to guess, I'd say that if it hit a jury, the jury would tend to be fairly absolute -- as in, you copied this tiny bit, so now you're liable for the whole thing. A judge is probably going to weight the infraction versus the whole.
And I really don't know what the law is on this. Maybe a legal type can help us out here.
I agree. I haven't gone through it in detail yet, and as such I probably shouldn't say a thing. The author swerves horribly wrongly when he tries to equate a BitTorrent "timestep" with a K2B timestep. Let's say you're putting out something big, like the Linux distribution. A BT timestep is 250k of stuff...once that block makes it out, it begins to multiply across clients, and multiply some more. That's a lot of capacity. A K2B timestep occurs only when the entire file is communicated. And why does the author feel that, somehow, K2B does a better job of constructing a distribution tree for content? I see no evidence that the tree it constructs is any better than BT. BT's ability to dynamically adapt a tree looks pretty much absent, to me.
The whole analysis is justification for the lack of a swarming capability in K2B.
Plus, anyone who puts a link to his justification for not writing a cross-platform app in Java on the front page is pretty suspect, right off the bat. It's harder to write with automatic garbage collection? Yeah, right. If you can't set a reference to null in Java, you don't have any business trying to write a C app.
As a Java developer this is what I am interested in...Java produces very large numbers of small files. Any file system that handles this more efficiently is going to make for faster compilation.
Now if Bram would just get busy and figure out how to swarm a multimedia feed, we could solve the bandwidth problem for that.
Radio on the net, video on the net...the problem is the multiplying lag factor. You need to organize the swarm into tiers, by lag. Tough but doable. Add support for IP broadcast, where available...
I like the idea; the problem is getting uptake on it. You need to encourage a lot of people. The way to do this is to get the "big" ISPs in on the scheme immediately. Participants should alter their mail transfer programs to tag the SUBJECT line of the messages with the word Untrusted. This will cause receivers to know, and significant embarrassment for those not participating...which will cause their mail system to be upgraded to participating status.
Unless the bad effects of not participating are directly visible (as in subject line), it's gonna take too long.
If you read SCO's entire complaint, it boils down to only a couple of points:
1. "Linux can only support 4 processors, where commercial grade Unix can support 32". I suspect that this isn't true. 2. It is impossible to create enterprise-class operating systems without access to "enterprise class" testing environments, and open source developers cannot have had access to these. This is in direct conflict with their economic argument about using low cost Intel equipement -- since it is low cost, there is good access to it. 3. IBM "misused" source to improve the capability of the Linux OS.
Their entire complaint is a litany of noise with these three exceptions, which form the true core of their complaint.
Once again, Linux is open source. Just point out the file and line numbers where it has infringed.
Once again, such bullshit. Linux is 100% open source. If there are parts of Linux that are infringing, just indicate exactly where the infringement is. That they have not included this information either indicates that it doesn't really exist, or that they don't want to reveal just how small the suspected infringing area really is. We all know that if any actual infringing code was located in the Linux OS it would be gone and replaced with a non-contentious equivalent in no time at all.
Which is why SCO is being so deliberately vague about all of this. They don't want an infringement to be eliminated; they want it to stay in the Linux code base so they can screw over users of Linux.
This is an attack on a development methodology more than anything else. What they're saying is, unless you can PROVE the lineage of your code is clean, we're going to have to assume that it isn't.
I suspect that IBM's lawyers are going to be smart enough to know all this, and will be able to effectively disarm SCO's actions. If there are infringing parts of the code, these will be revealed in a public forum (the courts).
In the meantime, I suggest that the best recourse for a receiver of this letter is to repond, indicating that the entity known as "Linux" is actually composed of thousands of parts, each independently produced, and that SCO needs to provide information indicating which component is infringing.
Fair enough. So what you're saying is that you can't put your mp3 files in a public place, intending for them to be downloaded. Maybe that's reasonable.
I think intent is a problem. There are a crapload of things that can happen today on a computer system that having nothing to do with the intent of the person who owns it.
If the search engine isn't the real issue...I can see the point of the suit.
This seems right up their alley...this kid was running a general purpose search engine. It indexes everything it finds. It returns results. He made no money off of it. He was intimidated into settling, pure and simple.
Can I run a search engine now? Exactly HOW are google and alta vista immune from similar suits? Simple -- they can pay lawyers who could kick the crap out of the RIAA.
It's a travesty of justice. I wish one of the multi-letter organizations would help this guy.
Firebird is somewhat generic, but seriously -- my point here is that the AOL legal department didn't exactly look hard. I do consider Firebird to be a pretty major open source database project. It's worth of a lot more attention than it's gotten.
The "lack of confusion" issue doesn't really hold water. With that reasoning I can go ahead and release the JBoss office suite and the Apache graphing package.
They "researched it for months", and didn't come up with the fact that one of the most significant open source database efforts had the same name? That's pretty crappy research, if you ask me. Fire that guy.
It seems that there are a lot of people who think that the Interbase/Starbase/Interbase/Firebird group is after publicity. That's plain stupid.
I've worked with it, on and off, for almost 18 years. That's hard to believe. My first job, while still in college, was coding automated test suites for Cognos' rebranding of Interbase.
It's a badass DB when it comes to self-maintenance. I've never encountered any other database that could just run, uninterrupted, for a couple of YEARS, underneath some pretty heavy duty stuff (industrial equipment).
We could all do the world a favor if we really, truly start using the P2P systems of the world as a general repository for information. Find some public domain stuff and share it. The more we do this, the more evidence there is of "substantial noninfringing use".
If you read the patent, it reads like a description of CORBA. The OMG started working on CORBA in 1989. That's all the prior art that should be needed.
You don't seriously want to be the spammer who's going to walk into court and try and convince a jury that it's ok for YOU to send data to people, but not ok for them to send data to you, do you?
Note my refinement above. I am not DDOSing anybody. I am just a lowly email user whose email client can check a service to find out where an email really came from. I am then probing that address.
The DDOS effect comes from the fact that if they send out several million emails, several million people might respond with probes. There is no direct decision to begin an attack. If no crap email is sent out, no attack occurs. It's a one-for-one, tit-for-tat.
Illegal is so many ways I can't count them (IANAL but I read/., which is better)
Maybe you should try and count them.
It is an attack to deprive them of $$
So what.
Its a conspiracy because you are working in tandum with others
Do I have the right to ping or attempt to identify the source of an email sent to me? Can I automate this process? What if I can send a spam email to a central server, and in response, it gives me an address on the internet that I can probe to get more information. My little automated gadget then probes that address. I'm not conspiring with anybody -- I'm requesting that the source of an email be given to me, and I'm checkin' it out.
It affects other resources on the internet
Yes -- upstream from the spammer, certainly. I don't have a problem with that.
I could go on, but I'm tired
No, I just think you ran out of things to say. Try again.
If they have the right to send me an email, I have the right to figure out where it came from and probe that address. A little automated help to do this certainly can't hurt anyone.
Cloudmark SpamNet could easily factor this kind of probe into their reporting system.
P.S. The AOL client would make a hell of a DDOS'er.
Voluntary DDOS on Spammers
on
AOL Sues Spammers
·
· Score: 3, Interesting
I was noodling around this spam problem and was thinking that maybe somebody who isn't me might write a little program, something that looks like SETI, but isn't...this little sucker allows you to participate in a voluntary DDOS attack on a spammer(s). Said program might verify that the "to be attacked" address was in a known spam database, or something like that. Problems:
1. How do we know the target of the attack is genuinely a dick? 2. How do we know we have the _right_ target addresses? 3. Who initiates the attack? Who terminates it?
I think those are solvable problems. This doesn't have to be a single mechanism, either.
We are many. They are few. No spammer/complicitor could withstand a deliberate DDOS that didn't end, and was voluntary.
A DDOS arms race out there on the internet is something that will happen sooner or later.
Is this illegal? Hey, we are just sending them a few bytes of information. They can just hit the delete key if they don't want it.
Please beat up this idea. I'm sure it's been posted before.:)
Logging is an easy one for AOP. Here are some more interesting things you can do:
1. Security processing...weave security checks into your code. 2. Transaction monitoring. 3. Automatic event propagation (get rid of those nasty JavaBeans listeners).
If, in a given situation, you call several methods in order, and that pattern is repeated across many other methods, each of those calls is a candidate for AOP, where you weave the calls in directly through pattern matching, rather than typing.
It can result in dramatically reduced code. It also _enforces_ behaviors (like when you forget to add that one line that does the security check).
Without AOP you are programming by exceptions, not by rule.
Buying broadband is interesting and all that, but what about sharing it? When neighbors get together and link up with wireless and a hub, it's usually to avoid paying for another connection. What if both have a connection, and you have software that can join them together? Then you can get a nice doubling of speed. My neighbor can use my bandwidth when I'm not using it, and vice versa.
If several people get together, you can put together a lot of bandwidth in a hurry. Neato.
Slashdot Mirror
There's exactly one reason why this wasn't done before. DVDs can be mailed. Their form factor permits it. That's the only reason. Well, that and the fact that Blockbuster and the other companies loved charging $4 per rental. All NetFlix has done is shift around the cost model a bit.
Yet another bullshit patent. These should be laughed out of court.
Great. Then you can set up YOUR server to let everything right in. It's your option to get plenty of spam! Maybe the rest of us will use a delay, though.
Making the tether out of a mesh is a pretty cool idea, but all you've done is extend the lifetime by some factor. What you really want to do is find a way to repair the damage relatively easily.
Picture two mesh tethers between the endpoints. Each tether is made of a series of lines. The lines come out of the tether and are _unwoven_ from the mesh weave. They are then looped back around and _reweaved_ into the tether going back in the other direction. Each line within a tether is actually participating in a complete loop, there are back again. Each line is an unbroken circle.
The tether is then _moved_ through the continuous loop, unweaving and weaving at each end. In this way the tether acts like a belt.
If a break occurs, then movement of the belt/tether will eventually bring the break to one of the terminals, where it can be repaired. The weave localizes the damage and ensures that the line will not simply fly off into space. The repaired line is then rewoven into the loop.
A belt-like tether like this can last indefinitely.
The real issue that's going to be litigated here is to what extent SCO can claim damages from another company if the infringement is tiny. The very best thing that SCO can muster, in this case, is that they've identified a subroutine or two that seem to be close or identifical to something they claim is their own code. Let's suppose that this is true. What effect does this small infringment have on the entirety of Linux? Can they claim that Linux is an infringing product when only a tiny part of it contains (arguably) any SCO code?
The court is going to have to struggle with this part/whole issue. If I had to guess, I'd say that if it hit a jury, the jury would tend to be fairly absolute -- as in, you copied this tiny bit, so now you're liable for the whole thing. A judge is probably going to weight the infraction versus the whole.
And I really don't know what the law is on this. Maybe a legal type can help us out here.
I agree. I haven't gone through it in detail yet, and as such I probably shouldn't say a thing. The author swerves horribly wrongly when he tries to equate a BitTorrent "timestep" with a K2B timestep. Let's say you're putting out something big, like the Linux distribution. A BT timestep is 250k of stuff...once that block makes it out, it begins to multiply across clients, and multiply some more. That's a lot of capacity. A K2B timestep occurs only when the entire file is communicated. And why does the author feel that, somehow, K2B does a better job of constructing a distribution tree for content? I see no evidence that the tree it constructs is any better than BT. BT's ability to dynamically adapt a tree looks pretty much absent, to me.
The whole analysis is justification for the lack of a swarming capability in K2B.
Plus, anyone who puts a link to his justification for not writing a cross-platform app in Java on the front page is pretty suspect, right off the bat. It's harder to write with automatic garbage collection? Yeah, right. If you can't set a reference to null in Java, you don't have any business trying to write a C app.
As a Java developer this is what I am interested in...Java produces very large numbers of small files. Any file system that handles this more efficiently is going to make for faster compilation.
Now if Bram would just get busy and figure out how to swarm a multimedia feed, we could solve the bandwidth problem for that.
Radio on the net, video on the net...the problem is the multiplying lag factor. You need to organize the swarm into tiers, by lag. Tough but doable. Add support for IP broadcast, where available...
I like the idea; the problem is getting uptake on it. You need to encourage a lot of people. The way to do this is to get the "big" ISPs in on the scheme immediately. Participants should alter their mail transfer programs to tag the SUBJECT line of the messages with the word Untrusted. This will cause receivers to know, and significant embarrassment for those not participating...which will cause their mail system to be upgraded to participating status.
Unless the bad effects of not participating are directly visible (as in subject line), it's gonna take too long.
Damn dude, you're good. IBM's lawyers should hire you to go over the thing.
I think you're right. By releasing Caldera, they may have relinquished any rights they had!
I'll also indicate this:
If you read SCO's entire complaint, it boils down to only a couple of points:
1. "Linux can only support 4 processors, where commercial grade Unix can support 32". I suspect that this isn't true.
2. It is impossible to create enterprise-class operating systems without access to "enterprise class" testing environments, and open source developers cannot have had access to these. This is in direct conflict with their economic argument about using low cost Intel equipement -- since it is low cost, there is good access to it.
3. IBM "misused" source to improve the capability of the Linux OS.
Their entire complaint is a litany of noise with these three exceptions, which form the true core of their complaint.
Once again, Linux is open source. Just point out the file and line numbers where it has infringed.
Once again, such bullshit. Linux is 100% open source. If there are parts of Linux that are infringing, just indicate exactly where the infringement is. That they have not included this information either indicates that it doesn't really exist, or that they don't want to reveal just how small the suspected infringing area really is. We all know that if any actual infringing code was located in the Linux OS it would be gone and replaced with a non-contentious equivalent in no time at all.
Which is why SCO is being so deliberately vague about all of this. They don't want an infringement to be eliminated; they want it to stay in the Linux code base so they can screw over users of Linux.
This is an attack on a development methodology more than anything else. What they're saying is, unless you can PROVE the lineage of your code is clean, we're going to have to assume that it isn't.
I suspect that IBM's lawyers are going to be smart enough to know all this, and will be able to effectively disarm SCO's actions. If there are infringing parts of the code, these will be revealed in a public forum (the courts).
In the meantime, I suggest that the best recourse for a receiver of this letter is to repond, indicating that the entity known as "Linux" is actually composed of thousands of parts, each independently produced, and that SCO needs to provide information indicating which component is infringing.
Or just ignore their f'ing letter.
Fair enough. So what you're saying is that you can't put your mp3 files in a public place, intending for them to be downloaded. Maybe that's reasonable.
I think intent is a problem. There are a crapload of things that can happen today on a computer system that having nothing to do with the intent of the person who owns it.
If the search engine isn't the real issue...I can see the point of the suit.
This seems right up their alley...this kid was running a general purpose search engine. It indexes everything it finds. It returns results. He made no money off of it. He was intimidated into settling, pure and simple.
Can I run a search engine now? Exactly HOW are google and alta vista immune from similar suits? Simple -- they can pay lawyers who could kick the crap out of the RIAA.
It's a travesty of justice. I wish one of the multi-letter organizations would help this guy.
Firebird is somewhat generic, but seriously -- my point here is that the AOL legal department didn't exactly look hard. I do consider Firebird to be a pretty major open source database project. It's worth of a lot more attention than it's gotten.
The "lack of confusion" issue doesn't really hold water. With that reasoning I can go ahead and release the JBoss office suite and the Apache graphing package.
They "researched it for months", and didn't come up with the fact that one of the most significant open source database efforts had the same name? That's pretty crappy research, if you ask me. Fire that guy.
It seems that there are a lot of people who think that the Interbase/Starbase/Interbase/Firebird group is after publicity. That's plain stupid.
I've worked with it, on and off, for almost 18 years. That's hard to believe. My first job, while still in college, was coding automated test suites for Cognos' rebranding of Interbase.
It's a badass DB when it comes to self-maintenance. I've never encountered any other database that could just run, uninterrupted, for a couple of YEARS, underneath some pretty heavy duty stuff (industrial equipment).
We could all do the world a favor if we really, truly start using the P2P systems of the world as a general repository for information. Find some public domain stuff and share it. The more we do this, the more evidence there is of "substantial noninfringing use".
If you read the patent, it reads like a description of CORBA. The OMG started working on CORBA in 1989. That's all the prior art that should be needed.
You don't seriously want to be the spammer who's going to walk into court and try and convince a jury that it's ok for YOU to send data to people, but not ok for them to send data to you, do you?
Note my refinement above. I am not DDOSing anybody. I am just a lowly email user whose email client can check a service to find out where an email really came from. I am then probing that address.
The DDOS effect comes from the fact that if they send out several million emails, several million people might respond with probes. There is no direct decision to begin an attack. If no crap email is sent out, no attack occurs. It's a one-for-one, tit-for-tat.
Maybe you should try and count them.
It is an attack to deprive them of $$
So what.
Its a conspiracy because you are working in tandum with others
Do I have the right to ping or attempt to identify the source of an email sent to me? Can I automate this process? What if I can send a spam email to a central server, and in response, it gives me an address on the internet that I can probe to get more information. My little automated gadget then probes that address. I'm not conspiring with anybody -- I'm requesting that the source of an email be given to me, and I'm checkin' it out.
It affects other resources on the internet
Yes -- upstream from the spammer, certainly. I don't have a problem with that.
I could go on, but I'm tired
No, I just think you ran out of things to say. Try again.
If they have the right to send me an email, I have the right to figure out where it came from and probe that address. A little automated help to do this certainly can't hurt anyone.
Cloudmark SpamNet could easily factor this kind of probe into their reporting system.
P.S. The AOL client would make a hell of a DDOS'er.
I was noodling around this spam problem and was thinking that maybe somebody who isn't me might write a little program, something that looks like SETI, but isn't...this little sucker allows you to participate in a voluntary DDOS attack on a spammer(s). Said program might verify that the "to be attacked" address was in a known spam database, or something like that. Problems:
:)
1. How do we know the target of the attack is genuinely a dick?
2. How do we know we have the _right_ target addresses?
3. Who initiates the attack? Who terminates it?
I think those are solvable problems. This doesn't have to be a single mechanism, either.
We are many. They are few. No spammer/complicitor could withstand a deliberate DDOS that didn't end, and was voluntary.
A DDOS arms race out there on the internet is something that will happen sooner or later.
Is this illegal? Hey, we are just sending them a few bytes of information. They can just hit the delete key if they don't want it.
Please beat up this idea. I'm sure it's been posted before.
If they think the JBoss guys copied code, why don't they just point out the file and line numbers. It's open source, isn't it?
Logging is an easy one for AOP. Here are some more interesting things you can do:
1. Security processing...weave security checks into your code.
2. Transaction monitoring.
3. Automatic event propagation (get rid of those nasty JavaBeans listeners).
If, in a given situation, you call several methods in order, and that pattern is repeated across many other methods, each of those calls is a candidate for AOP, where you weave the calls in directly through pattern matching, rather than typing.
It can result in dramatically reduced code. It also _enforces_ behaviors (like when you forget to add that one line that does the security check).
Without AOP you are programming by exceptions, not by rule.
Buying broadband is interesting and all that, but what about sharing it? When neighbors get together and link up with wireless and a hub, it's usually to avoid paying for another connection. What if both have a connection, and you have software that can join them together? Then you can get a nice doubling of speed. My neighbor can use my bandwidth when I'm not using it, and vice versa.
If several people get together, you can put together a lot of bandwidth in a hurry. Neato.