I wasn't talking about any type of integrity constraint, but specifically the type of "integrity constraints one can apply in a relational system",
Have you considered the type of constraints you CANNOT apply in a relational system?
Specifically, I mean that in a relational system one can apply integrity constraints in a declarative, relational manner. Ergo, if any other database system became able to apply such integrity constraints, it would become relational.
This is either a useless tautology or a terrible non-sequitur, depending on whether you want it to be useless but true or useful but false. Yes, if you do things relationally I suppose you're relational; but that's not the only way to do things.
This is either slightly confused or slightly confusing, but essentially true. Let me reword it a bit and see if we agree.
Hence if SCO knowingly distributed their Unix IP under the GPL they gave up their right to charge for it. the fact that they've been distributing the kernel since after they filed the lawsuit means that they are knowingly distributing their IP under the GPL,
No, their claim is that they're distributing their IP under their own license, and since their IP is entangled with the Linux kernel they're also distributing the Linux kernel under the GPL with some added restrictions.
THAT is where they get in trouble. Nobody cares how they license their own IP, or whether it's mixed in with Linux; the problem here comes when they slap their restrictions on other people's code in violation of the other people's licenses.
the fact that they've been distributing the kernel since after they filed the lawsuit means that they are knowingly distributing their IP under the GPL, and hence cannot charge a fee for it.
But they're not distributing it under the GPL -- it's under the GPL plus their own license. Again, the error wasn't distributing their *own* code; they have every right to do that, even under an impossible license. The error is distributing other people's code in violation of copyright.
Of course, they can fix this in a heartbeat -- just take their FTP server down.
Doing so violates the GPL and allows *every* contributor to the kernel who owns a copyright in the kernel to sue them for violation of the license.
And now, we're back in agreement.:-)
Of course, the judgement would be for pennies; most of the people involved lost nothing due to SCO's infringement. The loss is due to other things, such as their libels.
Entirely agreed, but what does this have to do with the DNCList?
If this law passes, and then if one of the telemarketers calls me, THEN (to quote you) they've been shown to have committed a crime for which the law says that they may be punished. Therefore, by your post's reasoning, I may then morally "oppress" that telemarketer.
In other words, your post doesn't include any reason why the DNCL would be bad.
I think free speech rights are too damned important to allow any cracks in the ediface,
I have a hard time figuring out your logic, but this really hits me hard. The DNC law is _not_ about free speech. Saying it is doesn't make it so. Making a phone call into someone else's private residence isn't free speech. It's something that every person has a right to forbid! There are already laws that allow this for individuals (stalking, restraining orders, etc); this law simply extends it to an entire class of calls which are especially annoying.
particularly when they allow the government and churchs to drive wedges into those cracks.
I don't think you meant what I'm reading, but I'm at a loss to guess what you actually meant. It looks like you're first saying that this DNCL puts cracks in the edifice of free speech, then you say that it allows churches and the gov't to drive wedges into the cracks. Huh?
If, for the sake of argument, the DNCL is breaking free speech, then surely its exemption of churches and politicians is its one *good* thing (or at least the one crack in its overall badness). If, on the other hand, the exemption of churches and politicians is a bad thing, surely the DNCL isn't breaking free speech. I don't see how you can have it both ways.
I also have to point out that the first amendment explicitly mentions only two types of expression: religious and political. In other words, it was explicitly intended to protect speech in order to allow those freedoms. Now, I'm not saying that this is at the expense of other types of speech, but I do have to point out that other types don't have the same explicit purposeful protection.
I have worked with SAIC as well, and my experience is the opposite for two out of three divisions. Admittedly not a random sample, but still, not bad. (The one where my experience wasn't that far from yours was also my first experience with them -- and it was still better than most of the companies I've worked with.)
No, it shouldn't be extreme design, because the customer isn't going to use your design; they're going to use your program.
but when the design is done, please, stay away.
The design's not done until the customer's satisfied; and the customer's not satisfied until the software's solving all the problems. So by your criteria, you need to be pairing.
Programming is art but should not be creative art ( most of time, there are exceptions ), you just make ideas to work and it requires both skill and consentration that is difficult is you have to stop and argue.
Programming can be drudgery. Would you want to use a system built by a drudge?
Do you also advocate avoiding peer review? Or do you simply want to postpone finding the problem until after the module's been built to depend on it? With pair programming you peer review comes in real-time (from your pair) as well as after the fact (from the next person who works with you on the code, which by convention cannot be the same person who paired with you to generate the code).
Admittedly, some arguments are wastes of time; but then some webbrowsing is as well. Solo coders can't get in wasteful arguments, but pair programmers can't get into wasteful webbrowsing. You win some, you lose some. More important is what you gain.
the integrity constraints one can apply in a relational system, which have never really been possible with any other approach.
Obviously untrue -- constraints are possible in ANY system. What's interesting is that the contraints in relational systems are designed to allow them to consistently model objects; and object systems _always_ model objects consistently. Thus, contraints in the relational sense are unneeded. (Other types are needed, of course.)
The 3000x benchmark only covered reads (although it was versus in-memory databases). That's still a useful benchmark; it's just not correct to quote it without its context.
The more general benchmarks show a much smaller advantage, of course. But it's still impressive and useful, within its domain -- and since it requires MUCH less code, its domain can extend to include things that we'd never use a RDBMS for.
Oh, and prevlayer does provide durability -- each command is journalled before the command executes.
Great post, I agree (and I like and use object prevalence). I just have one question:
What does your statement, "Allows you to manipulate the data inside the database before you get it," mean? How can you manipulate data you haven't gotten yet?
the fact that they're selling it as a replacement for an RDMBS is just silly.
It is and it isn't. It's not a replacement for a RDBMS; but it fits in many areas where a RDBMS has traditionally been used, but isn't actually a good idea.
It also fits in many areas where NO persistance is currently used: for example, word processing.
Thank you for playing(*). (*) I told you I was going to be pedantic.
Well, your message was pedantic (thank you, I appreciate your efforts to instruct in fine detail, and although they missed the point I believe the distinctions you draw are useful), but that last quip wasn't pedantic; it was merely condescending. Just thought I'd mention the difference.
I also need to mention that Prevlayer does provide isolation, even without one-phase-commit.
Rollback is handled by Prevlayer, in a slow but effective way (by resetting and replaying up to the failed operation). There are two causes of rollback: first, a failed atomic operation; and second, an undo of one or more operations as part of an unforseen larger-scale event. Of course, it's also sometimes possible to include "inverse commands" in the set of prevalent commands; such a trick would allow much faster rollbacks for any command which actually had a defined inverse.
I'm pro-OP, like you, but I have to point out that this isn't a good stance. Virtual memory doesn't help object prevalence; memory pagers aren't smart enough to handle the demands, and your OP system will fall behind a proper RDBMS.
Now, an OP system doesn't have to keep all its objects in its working set (i.e. in memory) at all times; intelligent design of this will result in the ability to use OP with a much larger problem than you have memory for, without a significant speed loss. But don't expect to be faster than a quick'n'dirty pseudo-RDMBS anymore.
A farm of prevlayer boxes is precisely one of the applications that 2.0 is intended for.
Prevayler is faster when it can fit the object store in memory
The benchmark claimed to be against MySQL with all its data in memory. That's a fair race.
and it tries to fit the entire object store in memory which is not the answer to 90%+ of real world tasks.
That statistic was made up from thin air and is _utterly_ false. Most tasks don't require very much data online, and I can't even imagine why you'd claim that they do. For those that do require large volumes of data, keeping it all in RAM is actually possible for a large subset. In fact, for the very largest tasks (petabyte systems), all the hard drives are directly facing equal amounts of memory -- booting the system consists of copying all the hard drives into their memory mirrors.
There is a "midrange" (well, it's high-end, but compared to petabyte systems it looks like a midrange:-) where buying and addressing enough RAM is prohibitive, but hard drives are manageable. In those cases, and in those cases alone, your argument holds.
There are, of course, other reasons to prefer a relational database manager over an object prevalent solution. Many of them, such as "my customers need truly ad-hoc queries, and they know SQL," are powerful and apply to many people. But your argument applies to only a few.
Good analysis, although I was surprised at first by it (having used MessageEase only on a Palm, I didn't realise the extent to which it would have to rely upon double-taps in a hardkey implementation).
My experience would tend to cause me to agree with your analysis in general and your statement about having to keep your eyes on the writing pad (although if there were tactile cues, such as hard buttons, that wouldn't be the case). However, my experience with QuickWriting has been very limited; I found that its initial learning curve was just too steep. Perhaps I need to revisit its website (do they have a good Palm version now?).
Checking -- no, their Palm version is still not the best for learning. It would help if they made an onscreen version, for people who just want to try it out without having to print out an overlay (keep in mind that most Palms won't work with their inserts, since they're for obsolete models).
The crosstalk is likely to be quite low since capacitive effects drop off with the square or cube of distance (I forget which).
I always thought it was the cube -- but the recent article on inductive coupling claimed that it's the inverse _sixth_ power. Wow.
I find it utterly facinating that we've seen two companies release exploits for E and M fields so close together:-). And they're entirely appropriate, given the drawbacks of each:
E fields are very easy to generate and tap, but very hard to control in the presence of foreign objects (i.e. almost anything can interfere with them. So Sun uses them in an environment containing no foreign objects -- problem solved!
M fields are easy to generate and control, but hard to tap due to their alignment -- so we use them where we can afford the bulk of a generator.
E and M fields are wonderfully complimentary. I would say that they serve orthogonal purposes, but if I did that I would be making a physics pun, and I would never do that.
WordWise looks nice indeed. I also like MessageEase (I've only used it on my Palm, but it looks like it'd be really nice on a cell phone as well), which is based on sliding. In short, your 9 keys are assigned to the nine most common letters, and slides from one key to another are assigned to less common letters.
Nice and quick, and non-predictive, so words don't change while you're typing them. Oh, and a HUGE number of possible characters, so you can program using it:-), or create macros.
They could probably do something similar with arrays of laser diodes beaming out the edges of the chips
Definitely. That would be electromagnetic coupling. Sun's using capacitive coupling, using only the E field. Last week we saw an article on a company using inductive coupling (magnetism) for short-distance data links (in their first product, a wireless earset).
EM is long-range (drops according to the inverse square) but very hard to convert to and from electricity.
M is short-range (inverse sixth power), relatively easy to convert, not easy to interfere with, but bulky and directional.
E is short-range (inverse sixth), slightly harder to convert, not bulky, but easily interfered with.
Sun's choice here is perfect: this application doesn't need (or want) the range of EM, and can't afford the mass and volume of an inductor. OTOH, the ease of interference is easily dealt with because once we know the geometry and composition of the board, we know the shapes the e-fields will have.
I really like the fact that we've had two nicely orthogonal stories just so close together.
This appears to me to be only the case for existing Novell customers -- SCO is permitted to make its own sales, for which it collects 100%. It did, after all, buy almost all rights to the code.
I'm not certain about that, but that's the impression I got from reading the excerpts from the contract.
Why are you speculating that anything would have to mass the same as the earth? The Earth orbits the sun, but doesn't mass the same as the sun!
The physics are simple: you just have a cord that stretches out beyond geostationary orbit. At geostationary, the cord's mass is in a precise orbit (zero pull towards or away from Earth); beyond that, the cord's inertia pulls it away from Earth. So you don't even need a lead weight at the end -- all you need is enough cord. As a bonus, anything that gets pulled past the geosync point will be accellerated away from Earth; so you can use it as a cosmic slingshot.
Hoist a chickenfarm to the end of the tether, and you can throw eggs at Mars!
Don't count on hybrids staying more expensive than pure gasburners -- at least Toyota's hybrid powertrain is massively more simple than any straight gas powertrain. Beautiful engineering.
That's true, but functions and classes don't express all, or even most, of the patterns that are present in our applications.
See "Aspect Oriented Programming" (google for it) for a set of extensions to some common languages. By seeing the problems they solve, you should get a better idea of what things functions and classes can, and cannot, solve.
Read this thread. Read ANY thread in this entire discussion. There are hundreds, probably thousands of people who are "collateral damage" -- not spammers, not related to spammers, not in any way supporting spammers, but blacklisted anyhow, because the bandwidth provider for their ISP also supplies bandwidth to another ISP which doesn't kick spammers off as quickly as they should.
We do NOT have to destroy the village in order to save it. Other blacklists get it right; SPEWS just took too long.
Personally, I wouldn't use a blacklist in order to block anything; I would use it to suspect things. Remember the greylist technique Slashdot posted about a while ago? I would use that, but ONLY for blacklisted origins. Other antispam techniques, such as Bayesian filters (including webfetching), could be applied only to email from 'suspicious' addresses.
The collateral damage argument is enough reason to never irredemably block a blacklisted address (certainly not one from SPEWS); another argument is that in a while, the origin of the spam will become entirely irrelevant. If you think for ONE moment that SoBig will be stopped by the FBI... You're wrong. Spam *will* become massively peer-to-peer.
Yes. Any number of other blacklists do the job quite well, without anywhere NEAR as many false positives.
There are also a number of other technologies in development which look very promising, although none of them are here yet for the admin. (Although I'm pleasantly surprised to see that DSPAM seems to work for some.)
At what point shouldn't SPEWS just say screw it, block the whole class C (instead of waiting for the next one to popup)?
I guess your answer is the same as SPEWS': "Don't ask, don't think, just nuke 'em all." The correct answer would be to think about it a while -- zero offences (i.e. a SINGLE spammer) shouldn't nuke the ISP; a documented shifting of spammers should (since the customers are having their costs reduced by spammers); and the space in between should be a documented grey area. The advantage of a centralised list like SPEWS is that this sort of judgement _is_ possible; spammers can dodge, but ISPs are a little less mobile.
Sorry, SPEWS is harmful to innocents, and therefore is harmful to blacklists.
Slashdot Mirror
I wasn't talking about any type of integrity constraint, but specifically the type of "integrity constraints one can apply in a relational system",
Have you considered the type of constraints you CANNOT apply in a relational system?
Specifically, I mean that in a relational system one can apply integrity constraints in a declarative, relational manner. Ergo, if any other database system became able to apply such integrity constraints, it would become relational.
This is either a useless tautology or a terrible non-sequitur, depending on whether you want it to be useless but true or useful but false. Yes, if you do things relationally I suppose you're relational; but that's not the only way to do things.
-Billy
This is either slightly confused or slightly confusing, but essentially true. Let me reword it a bit and see if we agree.
:-)
Hence if SCO knowingly distributed their Unix IP under the GPL they gave up their right to charge for it. the fact that they've been distributing the kernel since after they filed the lawsuit means that they are knowingly distributing their IP under the GPL,
No, their claim is that they're distributing their IP under their own license, and since their IP is entangled with the Linux kernel they're also distributing the Linux kernel under the GPL with some added restrictions.
THAT is where they get in trouble. Nobody cares how they license their own IP, or whether it's mixed in with Linux; the problem here comes when they slap their restrictions on other people's code in violation of the other people's licenses.
the fact that they've been distributing the kernel since after they filed the lawsuit means that they are knowingly distributing their IP under the GPL, and hence cannot charge a fee for it.
But they're not distributing it under the GPL -- it's under the GPL plus their own license. Again, the error wasn't distributing their *own* code; they have every right to do that, even under an impossible license. The error is distributing other people's code in violation of copyright.
Of course, they can fix this in a heartbeat -- just take their FTP server down.
Doing so violates the GPL and allows *every* contributor to the kernel who owns a copyright in the kernel to sue them for violation of the license.
And now, we're back in agreement.
Of course, the judgement would be for pennies; most of the people involved lost nothing due to SCO's infringement. The loss is due to other things, such as their libels.
-Billy
The oracle's actor died. I don't know what they did, but it's plausible that they got someone with a similar voice...
-Billy
Entirely agreed, but what does this have to do with the DNCList?
If this law passes, and then if one of the telemarketers calls me, THEN (to quote you) they've been shown to have committed a crime for which the law says that they may be punished. Therefore, by your post's reasoning, I may then morally "oppress" that telemarketer.
In other words, your post doesn't include any reason why the DNCL would be bad.
-Billy
I think free speech rights are too damned important to allow any cracks in the ediface,
I have a hard time figuring out your logic, but this really hits me hard. The DNC law is _not_ about free speech. Saying it is doesn't make it so. Making a phone call into someone else's private residence isn't free speech. It's something that every person has a right to forbid! There are already laws that allow this for individuals (stalking, restraining orders, etc); this law simply extends it to an entire class of calls which are especially annoying.
particularly when they allow the government and churchs to drive wedges into those cracks.
I don't think you meant what I'm reading, but I'm at a loss to guess what you actually meant. It looks like you're first saying that this DNCL puts cracks in the edifice of free speech, then you say that it allows churches and the gov't to drive wedges into the cracks. Huh?
If, for the sake of argument, the DNCL is breaking free speech, then surely its exemption of churches and politicians is its one *good* thing (or at least the one crack in its overall badness). If, on the other hand, the exemption of churches and politicians is a bad thing, surely the DNCL isn't breaking free speech. I don't see how you can have it both ways.
I also have to point out that the first amendment explicitly mentions only two types of expression: religious and political. In other words, it was explicitly intended to protect speech in order to allow those freedoms. Now, I'm not saying that this is at the expense of other types of speech, but I do have to point out that other types don't have the same explicit purposeful protection.
-Billy
I have worked with SAIC as well, and my experience is the opposite for two out of three divisions. Admittedly not a random sample, but still, not bad. (The one where my experience wasn't that far from yours was also my first experience with them -- and it was still better than most of the companies I've worked with.)
It's very definite that you got a bad apple.
-Billy
No, it shouldn't be extreme design, because the customer isn't going to use your design; they're going to use your program.
but when the design is done, please, stay away.
The design's not done until the customer's satisfied; and the customer's not satisfied until the software's solving all the problems. So by your criteria, you need to be pairing.
Programming is art but should not be creative art ( most of time, there are exceptions ), you just make ideas to work and it requires both skill and consentration that is difficult is you have to stop and argue.
Programming can be drudgery. Would you want to use a system built by a drudge?
Do you also advocate avoiding peer review? Or do you simply want to postpone finding the problem until after the module's been built to depend on it? With pair programming you peer review comes in real-time (from your pair) as well as after the fact (from the next person who works with you on the code, which by convention cannot be the same person who paired with you to generate the code).
Admittedly, some arguments are wastes of time; but then some webbrowsing is as well. Solo coders can't get in wasteful arguments, but pair programmers can't get into wasteful webbrowsing. You win some, you lose some. More important is what you gain.
-Billy
the integrity constraints one can apply in a relational system, which have never really been possible with any other approach.
Obviously untrue -- constraints are possible in ANY system. What's interesting is that the contraints in relational systems are designed to allow them to consistently model objects; and object systems _always_ model objects consistently. Thus, contraints in the relational sense are unneeded. (Other types are needed, of course.)
-Billy
The 3000x benchmark only covered reads (although it was versus in-memory databases). That's still a useful benchmark; it's just not correct to quote it without its context.
The more general benchmarks show a much smaller advantage, of course. But it's still impressive and useful, within its domain -- and since it requires MUCH less code, its domain can extend to include things that we'd never use a RDBMS for.
Oh, and prevlayer does provide durability -- each command is journalled before the command executes.
-Billy
Great post, I agree (and I like and use object prevalence). I just have one question:
What does your statement, "Allows you to manipulate the data inside the database before you get it," mean? How can you manipulate data you haven't gotten yet?
-Billy
the fact that they're selling it as a replacement for an RDMBS is just silly.
It is and it isn't. It's not a replacement for a RDBMS; but it fits in many areas where a RDBMS has traditionally been used, but isn't actually a good idea.
It also fits in many areas where NO persistance is currently used: for example, word processing.
-Billy
Thank you for playing(*).
(*) I told you I was going to be pedantic.
Well, your message was pedantic (thank you, I appreciate your efforts to instruct in fine detail, and although they missed the point I believe the distinctions you draw are useful), but that last quip wasn't pedantic; it was merely condescending. Just thought I'd mention the difference.
I also need to mention that Prevlayer does provide isolation, even without one-phase-commit.
Rollback is handled by Prevlayer, in a slow but effective way (by resetting and replaying up to the failed operation). There are two causes of rollback: first, a failed atomic operation; and second, an undo of one or more operations as part of an unforseen larger-scale event. Of course, it's also sometimes possible to include "inverse commands" in the set of prevalent commands; such a trick would allow much faster rollbacks for any command which actually had a defined inverse.
-Billy
One acronym: VM (memory not machine).
I'm pro-OP, like you, but I have to point out that this isn't a good stance. Virtual memory doesn't help object prevalence; memory pagers aren't smart enough to handle the demands, and your OP system will fall behind a proper RDBMS.
Now, an OP system doesn't have to keep all its objects in its working set (i.e. in memory) at all times; intelligent design of this will result in the ability to use OP with a much larger problem than you have memory for, without a significant speed loss. But don't expect to be faster than a quick'n'dirty pseudo-RDMBS anymore.
A farm of prevlayer boxes is precisely one of the applications that 2.0 is intended for.
-Billy
Prevayler is faster when it can fit the object store in memory
:-) where buying and addressing enough RAM is prohibitive, but hard drives are manageable. In those cases, and in those cases alone, your argument holds.
The benchmark claimed to be against MySQL with all its data in memory. That's a fair race.
and it tries to fit the entire object store in memory which is not the answer to 90%+ of real world tasks.
That statistic was made up from thin air and is _utterly_ false. Most tasks don't require very much data online, and I can't even imagine why you'd claim that they do. For those that do require large volumes of data, keeping it all in RAM is actually possible for a large subset. In fact, for the very largest tasks (petabyte systems), all the hard drives are directly facing equal amounts of memory -- booting the system consists of copying all the hard drives into their memory mirrors.
There is a "midrange" (well, it's high-end, but compared to petabyte systems it looks like a midrange
There are, of course, other reasons to prefer a relational database manager over an object prevalent solution. Many of them, such as "my customers need truly ad-hoc queries, and they know SQL," are powerful and apply to many people. But your argument applies to only a few.
-Billy
Good analysis, although I was surprised at first by it (having used MessageEase only on a Palm, I didn't realise the extent to which it would have to rely upon double-taps in a hardkey implementation).
My experience would tend to cause me to agree with your analysis in general and your statement about having to keep your eyes on the writing pad (although if there were tactile cues, such as hard buttons, that wouldn't be the case). However, my experience with QuickWriting has been very limited; I found that its initial learning curve was just too steep. Perhaps I need to revisit its website (do they have a good Palm version now?).
Checking -- no, their Palm version is still not the best for learning. It would help if they made an onscreen version, for people who just want to try it out without having to print out an overlay (keep in mind that most Palms won't work with their inserts, since they're for obsolete models).
ANYHOW...
Thanks for the pointers. I like WordWise.
-Billy
The crosstalk is likely to be quite low since capacitive effects drop off with the square or cube of distance (I forget which).
:-). And they're entirely appropriate, given the drawbacks of each:
I always thought it was the cube -- but the recent article on inductive coupling claimed that it's the inverse _sixth_ power. Wow.
I find it utterly facinating that we've seen two companies release exploits for E and M fields so close together
E fields are very easy to generate and tap, but very hard to control in the presence of foreign objects (i.e. almost anything can interfere with them. So Sun uses them in an environment containing no foreign objects -- problem solved!
M fields are easy to generate and control, but hard to tap due to their alignment -- so we use them where we can afford the bulk of a generator.
E and M fields are wonderfully complimentary. I would say that they serve orthogonal purposes, but if I did that I would be making a physics pun, and I would never do that.
-Billy
WordWise looks nice indeed. I also like MessageEase (I've only used it on my Palm, but it looks like it'd be really nice on a cell phone as well), which is based on sliding. In short, your 9 keys are assigned to the nine most common letters, and slides from one key to another are assigned to less common letters.
:-), or create macros.
Nice and quick, and non-predictive, so words don't change while you're typing them. Oh, and a HUGE number of possible characters, so you can program using it
-Billy
They could probably do something similar with arrays of laser diodes beaming out the edges of the chips
Definitely. That would be electromagnetic coupling. Sun's using capacitive coupling, using only the E field. Last week we saw an article on a company using inductive coupling (magnetism) for short-distance data links (in their first product, a wireless earset).
EM is long-range (drops according to the inverse square) but very hard to convert to and from electricity.
M is short-range (inverse sixth power), relatively easy to convert, not easy to interfere with, but bulky and directional.
E is short-range (inverse sixth), slightly harder to convert, not bulky, but easily interfered with.
Sun's choice here is perfect: this application doesn't need (or want) the range of EM, and can't afford the mass and volume of an inductor. OTOH, the ease of interference is easily dealt with because once we know the geometry and composition of the board, we know the shapes the e-fields will have.
I really like the fact that we've had two nicely orthogonal stories just so close together.
-Billy
This appears to me to be only the case for existing Novell customers -- SCO is permitted to make its own sales, for which it collects 100%. It did, after all, buy almost all rights to the code.
I'm not certain about that, but that's the impression I got from reading the excerpts from the contract.
-Billy
Why are you speculating that anything would have to mass the same as the earth? The Earth orbits the sun, but doesn't mass the same as the sun!
The physics are simple: you just have a cord that stretches out beyond geostationary orbit. At geostationary, the cord's mass is in a precise orbit (zero pull towards or away from Earth); beyond that, the cord's inertia pulls it away from Earth. So you don't even need a lead weight at the end -- all you need is enough cord. As a bonus, anything that gets pulled past the geosync point will be accellerated away from Earth; so you can use it as a cosmic slingshot.
Hoist a chickenfarm to the end of the tether, and you can throw eggs at Mars!
-Billy
Don't count on hybrids staying more expensive than pure gasburners -- at least Toyota's hybrid powertrain is massively more simple than any straight gas powertrain. Beautiful engineering.
-Billy
That's why we use functions and classes.
That's true, but functions and classes don't express all, or even most, of the patterns that are present in our applications.
See "Aspect Oriented Programming" (google for it) for a set of extensions to some common languages. By seeing the problems they solve, you should get a better idea of what things functions and classes can, and cannot, solve.
-Billy
Read this thread. Read ANY thread in this entire discussion. There are hundreds, probably thousands of people who are "collateral damage" -- not spammers, not related to spammers, not in any way supporting spammers, but blacklisted anyhow, because the bandwidth provider for their ISP also supplies bandwidth to another ISP which doesn't kick spammers off as quickly as they should.
We do NOT have to destroy the village in order to save it. Other blacklists get it right; SPEWS just took too long.
Personally, I wouldn't use a blacklist in order to block anything; I would use it to suspect things. Remember the greylist technique Slashdot posted about a while ago? I would use that, but ONLY for blacklisted origins. Other antispam techniques, such as Bayesian filters (including webfetching), could be applied only to email from 'suspicious' addresses.
The collateral damage argument is enough reason to never irredemably block a blacklisted address (certainly not one from SPEWS); another argument is that in a while, the origin of the spam will become entirely irrelevant. If you think for ONE moment that SoBig will be stopped by the FBI... You're wrong. Spam *will* become massively peer-to-peer.
-Billy
Yes. Any number of other blacklists do the job quite well, without anywhere NEAR as many false positives.
There are also a number of other technologies in development which look very promising, although none of them are here yet for the admin. (Although I'm pleasantly surprised to see that DSPAM seems to work for some.)
-Billy
At what point shouldn't SPEWS just say screw it, block the whole class C (instead of waiting for the next one to popup)?
I guess your answer is the same as SPEWS': "Don't ask, don't think, just nuke 'em all." The correct answer would be to think about it a while -- zero offences (i.e. a SINGLE spammer) shouldn't nuke the ISP; a documented shifting of spammers should (since the customers are having their costs reduced by spammers); and the space in between should be a documented grey area. The advantage of a centralised list like SPEWS is that this sort of judgement _is_ possible; spammers can dodge, but ISPs are a little less mobile.
Sorry, SPEWS is harmful to innocents, and therefore is harmful to blacklists.
-Billy