That picture probably isn't inaccurate. I recall a worm from some time ago (maybe it was CodeRed?) which had a bug in the random number generator; everyone here laughed about it, and then a day later a new version surfaced in which that bug had been fixed.
Because patents get published. Theoretically, you'd only get a patent if your invention was unobvious; giving you a patent (which you can then use to extort money from other people) is better than having your invention remain unpublished because you're not interested in doing anything with it.
The patent system fails where it gives patents for inventions which would be rediscovered and published anyway.
The unstructured network is a good idea except for one flaw: previously infected machines dont have part 2 of the virus.
That's not necessary. Have an unstructured network, capable of broadcasts, build itself and wait (while still exchanging connections, of course). Listen. If the worm becomes widespread, you'll be able to hear it. Now, when you want to do something, contact one of the nodes which tried to infect you.
This way, you not only don't need those 20 fixed machines, but you don't need to have part 2 written in advance. As long as the worm is widespread, you can insert your (signed) payload whenever you want.
Certain subject lines are going to be more effective at spreading the worm; and which lines are most effective will vary depending upon the people involved (eg, in France, subject lines which are in French will probably be more effective).
Consider a mailing worm which has a 99% chance of re-using its "parent's" subject line, and a 1% chance of using a new subject line, randomly chosen from the host's mail spool. The "bad" subject lines will rapidly die out, since nobody will be fooled by them, while the "good" subject lines will spread (at 99% of the normal rate). Survival of the fittest, applied to subject lines of email worms.
Even better, when the virus "mutates" (the 1% chance of picking a new subject line), it will pick a new subject line which is appropriate to the culture in which it finds itself.
Come on, if you're going to write a worm, do it right.
Don't use 20 predetermined machines from which to fetch updates; generate an unstructured network while you're spreading (remember who infected you, and trade connections randomly).
Don't fetch and install any updates provided to you; use RSA signatures to verify that they are legitimate.
Don't use canned, easy to filter, subject lines in your email messages; borrow subject lines from your host's mail spool (optionally, do so with only a small probability -- let evolution determine which subject lines are the most effective).
In short: If you're going to release some software which you want to see on millions of machines around the world, try not to embarrass yourself.
While VoIP (or at least, VoIP-connected-to-the-standard-telco-system) is pretty much the same as normal phone service, trying to apply exactly the same regulations isn't going to work.
For example, phone companies are supposed to track where phone calls originate (for 911 dispatchers, for example). That's not going to be possible with VoIP.
There should certainly be some sort of regulations, but simply saying "it's phone service, the same rules apply" is dumb.
Traditionally, people have tried to keep their routing tables small. When you're routing in hardware, the larger your routing table, the slower (or more expensive) your routing hardware is. As a result, you want to have single routes which apply to entire groups of hosts (eg, "packets for nodes 0-127 go through port 0, packets for nodes 128-255 go through port 1").
Because the routing is being done in software instead, the cost driver is dramatically reduced; consequently, it becomes cost-effective to have a routing table with an entry for each node.
Note that even in software, this approach doesn't really scale: If each node has a table entry for each other node, the memory cost is quadratic. This isn't a problem for a few thousand nodes, but this sort of routing would never work for the internet.
Wonder if they'll ultimately be forced to release this code?
They won't. One of the major principles of contract law is that if a contract is confusing, the confusion is resolved in favour of the party which did not write or choose the contract.
Given that there's widespread disagreement about how far "GPL taint" extends, I'm pretty sure that any dispute here would be resolved in favour of the loadable modules not needing to be released.
Except that almost all of the code in question was either originally copyrighted by IBM or SGI (jfs, xfs, RCU, etc). So if you logic applies to the copyright that SCO holds, then by same logic, SCO has no case.
I don't think it's as clearcut as that. IBM's UNIX license says: "Such right to use includes the right to modify such SOFTWARE PRODUCT and to prepare derivative works based on such SOFTWARE PRODUCT, provided the resulting materials are treated hereunder as part of the original SOFTWARE PRODUCT."
IANAL, but if the IBM code was originally written as a derivative work of UNIX -- and I seem to recall hearing that it was -- then it sounds like this clause causes that code to be treated as part of UNIX (and therefore it can't be put into Linux without SCO's permission).
I'm not saying that SCO is right here, but when I cut out the cheerleading and look at the details of what SCO seems to be arguing, I personally get worried.
Ok, let's put down the flamethrowers for a moment, and try to understand what SCO's lawyers are saying.
When they say "the GPL is pre-empted by copyright law", they don't mean that the GPL is invalid. What they mean is this: You can't GPL something you don't own. In other words, the fact that the code in dispute was distribute "under the GPL license" is irrelevant -- the company which did that (IBM) didn't own the code, so the fact that they "licensed" the code under the GPL is irrelevant.
You would think that after Klez, the people who write these virus scanners and those who administer mail servers would realize that viruses sometimes spoof the "From:" field.
The situation is even worse than that: Most (all?) of the virus scanners sending me autoreplies correctly identified the virus as being Sobig -- which always uses spoofed source addresses.
Sending autoreplies is sometimes useful, but these scanners should at very least have a table which tells them, for each virus, whether an autoreply should be sent (ie, a table which specifies if a virus uses spoofed source addresses).
Re:Let's hear from all of the excited /. readers!
on
FreeBSD 4.9 Code Freeze
·
· Score: 5, Funny
Slashcode must have eaten my tags.
Re:Let's hear from all of the excited /. readers!
on
FreeBSD 4.9 Code Freeze
·
· Score: 4, Informative
I, for one, agree here. 4.9-RELEASE isn't really all that exciting. Of course, it's not supposed to be exciting -- it's from the STABLE branch; new and exciting features don't belong in the STABLE branch.
Now, if there was a completely new scheduler or virtual memory system, or a couple data-corruption on unmount bugs, that would be exciting. But in FreeBSD, that sort of thing doesn't get into the STABLE branch.
... blowing up buses full of 7 year-old schoolchildren while carrying dozens of picklejars full of nails and screws so that the scrapnel rips apart as much human flesh as possible...
You misspelled "collateral damage".
I don't agree with the Palestinian suicide bombings, but all the evidence that I've seen suggests that Israel poses a far more immediate threat to most Palestinians than Iraq ever posed to the US; so if we're going to complain about killing civilians, let's start at home.
Court sealed documents don't have the same terms as the SCO NDA (me thinks).
I haven't read the NDA, so I can't really compare the two; but in this case I think it suffices to say that if SCO presents the 'stolen' code and it is sealed in court, we're probably not going to be seeing a complete accounting here on slashdot.
What will SCO do if the users declare to see the code and DO NOT sign the NDA? That essentially means that the lawsuit is invalid?
No, they get thrown in jail for contempt of court. Judges can, and often do, require that evidence disclosed during court proceedings (and in discovery, etc.) be held under non-disclosure if it is personal or commercially sensitive.
Maybe. But where do you plan on spending the money, and on what?
By itself, this sort of database is going to be pretty useless; but if anyone is considering providing more services to help these people in the future, this sort of database would be invaluable.
It's one thing to say "lots of homeless people are mentally ill, we should do something about it"; it's quite something else to have statistics saying "we're doing pretty well, treating mentally ill homeless people, except that every few months they move between jurisdictions, at which point we lose track of them -- we need to cooperate better to make sure that these people continue to get medical treatment even if they move".
Only if you believe the marketing. More likely, it will be somewhere around $299 (PDA) + $699 (SCO license) + $50 (shipping and handling) + 15% (taxes) = $1205.20
How do you industrious Slashdot readers go about fixing a mess like this (on a tight budget, no less) without getting a mains-induced glimpse at the great beyond?
There's two obvious answers here: 1. Hire an electrician. 2. If you're going to mess with it yourself, unplug it first. 220V AC isn't a problem when you've got a three-foot airgap.
it will also make it impossible to recover a server if you accidentally delete/usr
No. The libraries used by stuff in/bin and/sbin are being moved into/lib, so everything which is being changed from static to dynamic will still work even if/usr is gone.
Also note that/rescue is still static (and crunched).
How do you plan on getting solar power in the middle of the night? How do you get wind power when there isn't any wind?
Nuclear, gas, coal, and hydro power can all run at 90%+ of their peak capacity 90%+ of the time. With solar and wind power, you're lucky to be above 50% of peak capacity more than 50% of the time.
Wind and Solar power would not solve this problem -- they would make it worse.
The entire reason we have a power grid is to improve reliability. When a power plant needs to be taken down for maintainance, power is brought in from somewhere else; without the grid, we'd have blackouts every time plants were shut down for maintainance.
Solar and wind power are far less reliable than fossil and nuclear power. As a result, using them would require a larger, more expensive, grid in order to maintain the same quality of service.
Having distributed generation might be a good idea, but it would need to be distributed *reliable* generation; wind and solar just don't make the grade.
Slashdot Mirror
That picture probably isn't inaccurate. I recall a worm from some time ago (maybe it was CodeRed?) which had a bug in the random number generator; everyone here laughed about it, and then a day later a new version surfaced in which that bug had been fixed.
And that is good for inovation how?
Because patents get published. Theoretically, you'd only get a patent if your invention was unobvious; giving you a patent (which you can then use to extort money from other people) is better than having your invention remain unpublished because you're not interested in doing anything with it.
The patent system fails where it gives patents for inventions which would be rediscovered and published anyway.
Unfortunately for the virus, there is a 99% chance that a randomly chosen subject from the mail spool will read something like "ENLARGE YOUR PENIS!"
If that's really a concern, pick a random subject line from the *outgoing* mail spool.
The unstructured network is a good idea except for one flaw: previously infected machines dont have part 2 of the virus.
That's not necessary. Have an unstructured network, capable of broadcasts, build itself and wait (while still exchanging connections, of course). Listen. If the worm becomes widespread, you'll be able to hear it. Now, when you want to do something, contact one of the nodes which tried to infect you.
This way, you not only don't need those 20 fixed machines, but you don't need to have part 2 written in advance. As long as the worm is widespread, you can insert your (signed) payload whenever you want.
Certain subject lines are going to be more effective at spreading the worm; and which lines are most effective will vary depending upon the people involved (eg, in France, subject lines which are in French will probably be more effective).
Consider a mailing worm which has a 99% chance of re-using its "parent's" subject line, and a 1% chance of using a new subject line, randomly chosen from the host's mail spool. The "bad" subject lines will rapidly die out, since nobody will be fooled by them, while the "good" subject lines will spread (at 99% of the normal rate). Survival of the fittest, applied to subject lines of email worms.
Even better, when the virus "mutates" (the 1% chance of picking a new subject line), it will pick a new subject line which is appropriate to the culture in which it finds itself.
Come on, if you're going to write a worm, do it right.
Don't use 20 predetermined machines from which to fetch updates; generate an unstructured network while you're spreading (remember who infected you, and trade connections randomly).
Don't fetch and install any updates provided to you; use RSA signatures to verify that they are legitimate.
Don't use canned, easy to filter, subject lines in your email messages; borrow subject lines from your host's mail spool (optionally, do so with only a small probability -- let evolution determine which subject lines are the most effective).
In short: If you're going to release some software which you want to see on millions of machines around the world, try not to embarrass yourself.
While VoIP (or at least, VoIP-connected-to-the-standard-telco-system) is pretty much the same as normal phone service, trying to apply exactly the same regulations isn't going to work.
For example, phone companies are supposed to track where phone calls originate (for 911 dispatchers, for example). That's not going to be possible with VoIP.
There should certainly be some sort of regulations, but simply saying "it's phone service, the same rules apply" is dumb.
Traditionally, people have tried to keep their routing tables small. When you're routing in hardware, the larger your routing table, the slower (or more expensive) your routing hardware is. As a result, you want to have single routes which apply to entire groups of hosts (eg, "packets for nodes 0-127 go through port 0, packets for nodes 128-255 go through port 1").
Because the routing is being done in software instead, the cost driver is dramatically reduced; consequently, it becomes cost-effective to have a routing table with an entry for each node.
Note that even in software, this approach doesn't really scale: If each node has a table entry for each other node, the memory cost is quadratic. This isn't a problem for a few thousand nodes, but this sort of routing would never work for the internet.
Wonder if they'll ultimately be forced to release this code?
They won't. One of the major principles of contract law is that if a contract is confusing, the confusion is resolved in favour of the party which did not write or choose the contract.
Given that there's widespread disagreement about how far "GPL taint" extends, I'm pretty sure that any dispute here would be resolved in favour of the loadable modules not needing to be released.
Maybe it's just MSIE being wierd, but the story appeared in a really small font.
The "printable version" is far easier to read.
Except that almost all of the code in question was either originally copyrighted by IBM or SGI (jfs, xfs, RCU, etc). So if you logic applies to the copyright that SCO holds, then by same logic, SCO has no case.
I don't think it's as clearcut as that. IBM's UNIX license says: "Such right to use includes the right to modify such SOFTWARE PRODUCT and to prepare derivative works based on such SOFTWARE PRODUCT, provided the resulting materials are treated hereunder as part of the original SOFTWARE PRODUCT."
IANAL, but if the IBM code was originally written as a derivative work of UNIX -- and I seem to recall hearing that it was -- then it sounds like this clause causes that code to be treated as part of UNIX (and therefore it can't be put into Linux without SCO's permission).
I'm not saying that SCO is right here, but when I cut out the cheerleading and look at the details of what SCO seems to be arguing, I personally get worried.
Ok, let's put down the flamethrowers for a moment, and try to understand what SCO's lawyers are saying.
When they say "the GPL is pre-empted by copyright law", they don't mean that the GPL is invalid. What they mean is this: You can't GPL something you don't own. In other words, the fact that the code in dispute was distribute "under the GPL license" is irrelevant -- the company which did that (IBM) didn't own the code, so the fact that they "licensed" the code under the GPL is irrelevant.
You would think that after Klez, the people who write these virus scanners and those who administer mail servers would realize that viruses sometimes spoof the "From:" field.
The situation is even worse than that: Most (all?) of the virus scanners sending me autoreplies correctly identified the virus as being Sobig -- which always uses spoofed source addresses.
Sending autoreplies is sometimes useful, but these scanners should at very least have a table which tells them, for each virus, whether an autoreply should be sent (ie, a table which specifies if a virus uses spoofed source addresses).
Slashcode must have eaten my tags.
I, for one, agree here. 4.9-RELEASE isn't really all that exciting. Of course, it's not supposed to be exciting -- it's from the STABLE branch; new and exciting features don't belong in the STABLE branch.
Now, if there was a completely new scheduler or virtual memory system, or a couple data-corruption on unmount bugs, that would be exciting. But in FreeBSD, that sort of thing doesn't get into the STABLE branch.
... blowing up buses full of 7 year-old schoolchildren while carrying dozens of picklejars full of nails and screws so that the scrapnel rips apart as much human flesh as possible ...
You misspelled "collateral damage".
I don't agree with the Palestinian suicide bombings, but all the evidence that I've seen suggests that Israel poses a far more immediate threat to most Palestinians than Iraq ever posed to the US; so if we're going to complain about killing civilians, let's start at home.
Court sealed documents don't have the same terms as the SCO NDA (me thinks).
I haven't read the NDA, so I can't really compare the two; but in this case I think it suffices to say that if SCO presents the 'stolen' code and it is sealed in court, we're probably not going to be seeing a complete accounting here on slashdot.
What will SCO do if the users declare to see the code and DO NOT sign the NDA? That essentially means that the lawsuit is invalid?
No, they get thrown in jail for contempt of court. Judges can, and often do, require that evidence disclosed during court proceedings (and in discovery, etc.) be held under non-disclosure if it is personal or commercially sensitive.
Maybe. But where do you plan on spending the money, and on what?
By itself, this sort of database is going to be pretty useless; but if anyone is considering providing more services to help these people in the future, this sort of database would be invaluable.
It's one thing to say "lots of homeless people are mentally ill, we should do something about it"; it's quite something else to have statistics saying "we're doing pretty well, treating mentally ill homeless people, except that every few months they move between jurisdictions, at which point we lose track of them -- we need to cooperate better to make sure that these people continue to get medical treatment even if they move".
All for $299 USD
Only if you believe the marketing. More likely, it will be somewhere around $299 (PDA) + $699 (SCO license) + $50 (shipping and handling) + 15% (taxes) = $1205.20
How do you industrious Slashdot readers go about fixing a mess like this (on a tight budget, no less) without getting a mains-induced glimpse at the great beyond?
There's two obvious answers here:
1. Hire an electrician.
2. If you're going to mess with it yourself, unplug it first. 220V AC isn't a problem when you've got a three-foot airgap.
it will also make it impossible to recover a server if you accidentally delete /usr
/bin and /sbin are being moved into /lib, so everything which is being changed from static to dynamic will still work even if /usr is gone.
/rescue is still static (and crunched).
No. The libraries used by stuff in
Also note that
How do you plan on getting solar power in the middle of the night? How do you get wind power when there isn't any wind?
Nuclear, gas, coal, and hydro power can all run at 90%+ of their peak capacity 90%+ of the time. With solar and wind power, you're lucky to be above 50% of peak capacity more than 50% of the time.
Wind and Solar power would not solve this problem -- they would make it worse.
The entire reason we have a power grid is to improve reliability. When a power plant needs to be taken down for maintainance, power is brought in from somewhere else; without the grid, we'd have blackouts every time plants were shut down for maintainance.
Solar and wind power are far less reliable than fossil and nuclear power. As a result, using them would require a larger, more expensive, grid in order to maintain the same quality of service.
Having distributed generation might be a good idea, but it would need to be distributed *reliable* generation; wind and solar just don't make the grade.
Now, hydrogen doesn't have nearly as many hazardous issues to deal with (that we know of) as nuclear power
The dangers of nuclear power are overrated. I'd much rather have a Plutonium RTG in my basement than a hydrogen fuel cell (and associated fuel lines).