As an "abandoner," I don't care if you fork a dead project (or a live one) as long as you make a reasonable effort to let me know and use a sufficiently distinct name to avoid confusion.
N.B., you don't HAVE to contact me, but it's a nice courtesy because I might be able to hook you up with others doing similar work, or I might have something in the pipeline very similar to what you want to do but which I don't yet consider publishable.
It sounds like you did everything you could, so fork the project and give it a new name and don't worry about it. For a year or so, you'll want to mention the fork from the old project, but just in case it revives or there are other forks in progress - it makes it much easier to coordinate efforts in the future.
BTW, reasons I've dropped off the net include travel, busy with work, busy with life, busy with skills development, etc. I've occasionally dropped it because I realized that there was a much cleaner way of solving the problem, but sometimes the approach is so different that I create a new project instead of having an abrupt transition in the old one. Hell, I've even abandoned a project because it depended on another group for some critical libraries, but their attitude made it too time consuming to use their library but impossible to work around them. (Yeah, I'm talking to you Debian apt developers. Apt is great, but it's not a full CMS system.)
A special clause on page 394 of the enacting legislation says that anyone convicted of publishing Microsoft's dirty laundy is enjoined from using any other operating system for life. It's Microsoft only, baby!
Repeat offenders are enjoined from using any operating system other than Windows ME.
And for the hard-core cases... they bring out BOB.
What, do you honestly think that there are no Unix systems anywhere within the Microsoft organization?
Of course they'll have some Unix boxes around, just as I'm sure Sun has some Microsoft boxes around. Even if they don't actually run applications on them (doubtful), they'll want them for competitive analysis for their marketing people. It's hard to compete if you don't know what the competition is doing.
"Eating your own dog food" is a well-known expression, esp. common in Microsoft, that refers to products mature enough that you use them yourself.
One of the primary uses for the phrase is when you can use your compiler to compile your own compiler. That's a major milestone that indicates the product is actually useful for a non-trivial task.
Another example is using your own accounting software to maintain your own books. Or your own mail software to manage your own mail system.
Grandpa probably paid no income taxes until he was well established, and even your father paid far less taxes than you will. It's not just a matter of earning more, there's a far higher tax burden today than in the past, even before you toss in FICA taking money out of the first dollar you earn.
Grandpa probably started out in a room at the Y with a hot plate, maybe, and a common bathroom down the hall. Your father probably started out in a small efficiency. But today it's hard to find cheap but safe housing - almost everyone would rather pay hundreds per month for every luxury today, than save and invest the money so that they might be able to afford their own property with the same amenities in a decade or two.
Grandpa probably walked to work, or rode a tram. People lived in cities close to work, not in suburbs. Your father could have ridden the bus, or gotten a used car with minimal features. But today you need a car (unless you're in some core cities), and that car has a laundry list of federally mandated safety features and a second laundry list driven by market forces.
Ditto laundry, clothing, travel and recreation, etc.
Don't get me wrong - life today is far more comfortable and safer than in your father's or grandfather's day. But it is also much harder to get established, and even people who are willing to make short-term compromises for long-term benefit find it difficult because of the lack of availability.
As you said, only if they don't redistribute the changes. That covers in-house use and pure client/server "black box" implementations (where the GPL code sites on a server, never exposed to the client), but not distribution to clients of compiled or other derived products.
Since these companies are claiming that the code released by the primary infringer contains their propietary code, I don't see how any of them can make meaningful claims that they aren't distributing their changes - if they weren't distributing the changes, how did the primary infringer get the code to provide to this guy? Maybe there's a reasonable explanation out of this paradox, but it seems that the burden of proof is on them to defend their use of his code at this point.
(N.B., this doesn't mean that he has any right to their code either - but these intimidation tactics have got to stop. Everyone is entitled to their IP rights, not just companies with an arrogant attitude.)
I'm pissed. Who's your chickenshit lawyer so we can all avoid him ourselves?
EACH AND EVERY ONE OF THESE COMPANIES threatening you if you publish their propietary code has, indirectly, admitted to ripping you off. THEY are the ones who should be sweating, they have no right to the code that they wrote proprietary extensions to and it's black letter law that you have the right to order them to immediately cease and desist any and all future infringement of YOUR code.
This may put the companies out of business, or expose them to massive suits for non-performance. IT'S NOT YOUR RESPONSIBILITY. They are violating your IP rights, you have the unconditional right to order them to stop regardless of the consequences to them.
It won't take them long to realize that they have two options. One, they can lay off everyone (you've killed their product!) and sue the original infringer for damages while their clients sue them. They can't threaten you for exercising your own rights, especially after they tried to do it to you!
Or two, they can pay you a reasonable fee for the right to use the code in a proprietary product. Say, something between $20k-$50 plus the right to distribute the code in the infringing product today under any and all licenses you choose. If they want to pull code out, they can... at their expense. Just because something is released under the GPL doesn't mean you can't also license it for proprietary use.
Meanwhile expect to see the original infringer get hit with massive suits for fraud. They may think they pulled a fast one on you, but as long as you stand up for your rights you may yet have the last laugh as that company is forced into bankruptcy for stealing your code and presenting it as its own.
You can use PKIX (X.509 certificates) with much of this infrastructure - Apache + mod_ssl, innd, ldap, postgresql and mysql, etc. The main hassle is that the different applications don't (yet) have the same view of how certs should work... and many don't yet require checking full certificate chains because the non-crypto core developers don't want to drive away users without a full PKIX intrastructure.
The biggest flaw in the "fewer workers, same output, higher productivity" is that it's eating the seed corn.
To be sure, there are many jobs there this doesn't matter. Perhaps most jobs.
But development is different. We need downtime to make the next big leap. When we're in the active development phase, we can productively spend 40 hours/week doing real work. Hell, those of us who got into this field because we like it, not because it seemed like the easiest way to make some big bucks, will probably want to work far more than 40 hours/week because of the sheer joy of producing something.
But when that's over, the fields need to lay fallow for a while. If you try to keep the same pace up, just like a crop field you'll see your the true productivity fall off.
At this point some fool suggests bringing in new people - equivalent to changing the fields - but that doesn't work either since it limits your product development to what can be comprehended and enhanced in the period between hiring and burnout. Assuming you can even reliably identify suitable candidates.
It's no secret that many of us have been attracted to OSS, in part, because of the fact that this change in environment allows us to remain productive far longer than we would be if we just kept doing the same thing. Ironically, this outlet isn't available to us when we succeed in finally finding a job that lets us use Linux in the workplace.
IIRC, the "remove me" line is not required by any federal law. (Some states may require it.)
However, the spammers are cutting their own throat with it. Citing S.1816 (or whatever) as proof that the message "cannot be considered spam" is a lie. There is no, and has never been, any law of the United States passed by the Senate alone.
That's somewhat abstract - although it's still a criminal act in some states to claim something is the law when you know it is not. But the promise to remove the person's email address from future mailings is a very specific claim. This means that the spam is asking for something of indeterminant but real value (a valid email address which can be sold to other spammers) in exchange for a specific promise you have no intention of keeping. That's fraud, and I wouldn't mind seeing every spammer who makes that claim get hit with a warning letter followed by a stiff penalty.
As others have pointed out, this content would be illegal no matter how they distribute it. You can't take a magic pill to grow larger breasts, a bigger dick and get a new credit card despite your horrible credit history.
But even setting that aside, I dare you to show me ANY precedence for your right to come into my house, raid my refrigerator, cook a meal on my stove, eat it on my plates, then leave the mess in the middle of my living room to poison my dog.
Yet that's exactly what spammers are doing (in a rhetorical sense) when they use my domain name to send out their crap, or abuse an open mail relay, or use poorly designed forms on some web site to send their messages to others. They're deliberately and willfully using my resources and good reputation to their own benefit, without my consent and without any renumeration to me.
Like you, I have very mixed feelings about government regulation of spam where the company has the balls to stand behind its own message. Let me blackball them myself. But I have no more qualms about the government cracking down on spammers who "borrow" my good name or resources than I do about the government cracking down on criminals who "borrow" my car, or "borrow" my credit card, etc.
I have a mail folder boringly labeled "send to ftc," and every 6 hours a cron job forwards the contents of the folder to the FTC.
This usually means that once a day I eyeball the contents of my "spam" folder to make sure there are no false positives, then move everything over to the other folder. Plus about a half-dozen messages that make it into my main mailbox.
But something I have not yet gotten a good answer for is what format to use when sending the spam to the FTC. I want to preserve the original headers (to help determine when open relays are being abused, headers forged, etc.), but that's surprisingly hard to do right. And do I strip out the spamassassin headers, or leave them in?
My current approach is to mime-encode the entire message (content-type: message/rfc822) and send it in a new envelope. I hope they know how to decode it, but Mozilla (annoyingly) doesn't. That makes it hard to verify your scripts before making them live.
Laws like that are almost inevitably racism or similar bigotry masked by a seemingly innocent law.
To give a contemporary example with extremely offensive (and inaccurate) stereotypes, consider a hypothetical 1950s law prohibiting the eating of fried chicken and watermelon on the front porch.
Do you think the authors were really dealing with a problem of greasy chicken bones and slippery watermelon rinds on the nearby sidewalks?
Or do you think the law might be a not-so-subtle way of keeping certain people out of sight?
I have no idea which group beat their rugs on the front lawn, and which group found it a convenient way to "put them in their place," but I would lay long odds against the law actually dealing with an excess of public carpet floggings.
One of the most damning comments in the article seems to have been overlooked.
"Two days later, 275 messages were opened (out of a half million, remember) and 65 surveys completed...." (paraphrased). Gee, how the hell did she know how many messages had been read?
Maybe she's just counting the number of hits on a specific image on her server... but it seems much more likely that she's using a mailbug. If only 275 people, out of 500,000, even opened the message then these are the morons you want to include in all future mailings.
Canada may claim it is territorial waters, but the US has a stronger case in the claim that it's still an international strait and free passage cannot be denied or taxed.
Ironically, Canada itself contains one of the best precedents of this - the St. Lawrence Seaway is an international strait from the Atlantic Ocean to the Great Lakes, even though substantial stretches of it are Canadian territory on both banks. (Other stretches have Canada on one side, the US on the other.)
There's also the pesky fact that the Canadian waters do not cover the entire distance - the western terminus will be in either US or Russian waters, and the US could use Canada's own claims to claim all sea ice and surrounding waters to the North Pole itself.
Actually, the more you study this stuff the more you worry that some of the them could pose a real threat. Diseases are obvious, as are volcanoes when you realize we haven't had a decent eruption since the early 19th Century... but that even a Tambola-level eruption is nothing compared to a supervolcano like Yellowstone.
The problem with these analyses is that it often overlooks how little commercial support really gets you. Esp. if you're looking at very long duration projects with limited resources to pay somebody to support your platform long after everyone else has moved on.
Let's set the way back machine back about the same number of years, let's say to 1994. You develop an application and buy hardware....
Your Linux solution is running a pre-1.0 kernel on a box that runs under 100Mhz. If you need to recompile it to work on new hardware and OS when your old system bites it, you can.
Your Windows solution is running on Windows 3.1. Good luck getting support for it. If you are willing to pay for a whole new development cycle, you reinvented it for Windows 95. Good luck getting support for it. Ditto your upgrade to NT4, which also required all new hardware.
The cold hard truth is that when you're looking at a long window, you MUST have FULL source or you're hosed. At some point you're going to need to run on hardware that's no longer being made, or your hardware will require some driver that you can't get without upgrading your OS, etc.
Yeah, yeah, yeah, but in reality whoever you vote has to work with Congress as a whole. When the balance is close, you may be better off voting for the less desirable local candidate so you have a more desirable national party.
This is especially true this year. Control of the Senate may hinge on a single election, and you have to trade off the consequences of voting for the "good" candidate, but putting the "bad" party in control of the Senate, vs. the "bad" candidate and putting the "good" party in control.
This seems backwards, with a list of hashes hardcoded into the kernel.
I gave this some thought a while back, and more from the perspective of the user-space loader, and decided that it made much more sense to compile a public key into the kernel and cryptographically sign all trusted binaries.
The result is similar - you still have to verify the checksum before you load the file, but instead of having a hardcoded list of hashes that could be a maintenance nightmare you just check the checksum attached to the file itself.
It would also be easy for the kernel to determine that an executable was signed. Or you could be a bit more intelligent and stuff the signatures within the ELF file as an extension - this would allow you to protect the executable code, yet allow the initialized data (which could contain messages, etc.) to be modified.
The kernel would then only need to have a few public keys (or certs) - the project itself, an integrator, perhaps a local developer or two. Private keys, needless to say, should never be stored on the system.
All that remains is monitoring the list of authorized keys. That would be easy to do; I don't remember if BSD has a/proc FS but that's one obvious place to publish it.
Of course, since this is all blindingly obvious (it has to be, if I came up with it on my own with a few minutes thought) I'm sure that the USPTO has given a patent for it to somebody. Probably Microsoft.:-)
That claim misses the point. The countless complaints about PayPal aren't due to claims that it was insolvant, but because it was transferring funds without the owner's consent and then dragging its feet in resolving the complaint.
Here's a hint: with very little information anyone can create false documents to access my checking account. It is trivial for anyone who had legitimate access to one of my checks. They'll probably even manage to get them cashed. But the back cannot refuse to acknowledge my complaint of criminal fraud, and I'll probably get my money back immediately if the signatures don't match at all, etc.
IIRC, the fighters were built from recovered death glider parts (the first one almost exclusively, the second with much more Tor'ii parts), and the cruiser was mostly built from the baby Go'ulds in Oregon. Or wherever "Nightwalkers" was set.
As for the "rare mineral," haven't you noticed that about every third episode involved trade negotiations, especially for Naquadaa? Some of these planets may have been "mined out" for the amounts required by the Go'uld, yet still worth operating for the quantity earth needs at this time.
Yeah, and what's with that bald chick in the Star Trek movie? I mean, that ruined it for me.
I'm so glad I haven't wasted any of my time with the subsequent movies or series. I mean, if it's that bad on the first movie you shudder to think of how bad it must have been by, oh, the 4th or 5th year of the first spinoff series.
Of course this is evil. It is a company doing something that it damn well knows will be offensive to the other party, but trying to sneak it through by willfully keeping that other party in the dark (by having their agent click through the EULAs) or intimidation once discovered.
Think about it this way: if they truly had nothing to hide, they wouldn't hide. The company wouldn't hesitate to admit the fact that it's collecting data, and what data it is collecting, up front. Just like a Nielson ratings household. The mere fact that they go to such lengths to hide the presence of this software screams to a "guilty mind."
As for your analogy to the sniper, that's obscene. I'm horny, where's your sister (or underage daughter), I want to fuck her. She may call it rape, but hey it's not like I shot 14 people, killing 10, so she can't complain. I mean, it's not like I KILLED her and 9 of her friends, now is it?....
Shocked? Good, now maybe you'll understand that ethical behavior is absolute, not relative. In fact, in this specific case the data collection may be more evil than the cold-blooded murder of 10 people since the information collected could potentially be used to identify suitable victims of a serial rapist/murder. It would not be the first time that databases have been used in this way, and in fact any ethical database designer knows this and will go to some effort to prevent "find me a victim" type queries.
I was halfway through my SCSA cert exams before starting my current job (where our servers use Solaris 8), so I think I have some knowledge of how Solaris stacks up against Linux and OpenBSD....
On the one hand, it does integrate some nice technology that the free systems lack. Most of the core technology is very stable.
But on the other hand, it's about a decade behind the time on some very fundamental items. Packet sniffers, and the need to use ssh/scp instead of telnet/ftp, don't appear to exist in the Solaris world. They aren't installed by default, they aren't covered by the exams. It doesn't come with a compiler. Etc and so on.
Sure, it's possible to install the GNU packages to add the missing functionality, but this misses the point. I would much rather use something like OpenBSD (where I have a solid system that I have to add applications to) than Solaris (where I might have an integrated environment, but then have to spend hours securing to modern practices). If I overlook something, the damage on OpenBSD will be far less than on Solaris.
I don't know anyone who runs Solaris on a x86 because they like Solaris on an x86, but it's a very good platform for keeping current on your Sun sysadmin and netadmin skills or prepping for the cert exams.
And that, in turn, affects our employer's decision on which hardware to buy when they need honking big servers.
Microsoft, for all of its other faults, does understand that the developers and admins are key people to get in the loop. These programs can be a real pain if you're a small consulting firm, but if they think you're large enough to be throwing business their way you can get access to a lot of software so your familiarity with it may be a line item when the CIO decides which package to purchase.
So why is Sun pissing on the SCSAs and SCNAs? They don't need to worry about the people who are already using Solaris-on-Sparcs at work, they need to worry about the people who are using HP/UX or AIX or Linux or *BSD and might not remain current on what Solaris offers unless they have that low-cost box to play with.
Slashdot Mirror
As an "abandoner," I don't care if you fork a dead project (or a live one) as long as you make a reasonable effort to let me know and use a sufficiently distinct name to avoid confusion.
N.B., you don't HAVE to contact me, but it's a nice courtesy because I might be able to hook you up with others doing similar work, or I might have something in the pipeline very similar to what you want to do but which I don't yet consider publishable.
It sounds like you did everything you could, so fork the project and give it a new name and don't worry about it. For a year or so, you'll want to mention the fork from the old project, but just in case it revives or there are other forks in progress - it makes it much easier to coordinate efforts in the future.
BTW, reasons I've dropped off the net include travel, busy with work, busy with life, busy with skills development, etc. I've occasionally dropped it because I realized that there was a much cleaner way of solving the problem, but sometimes the approach is so different that I create a new project instead of having an abrupt transition in the old one. Hell, I've even abandoned a project because it depended on another group for some critical libraries, but their attitude made it too time consuming to use their library but impossible to work around them. (Yeah, I'm talking to you Debian apt developers. Apt is great, but it's not a full CMS system.)
Nope, not the death penalty.
A special clause on page 394 of the enacting legislation says that anyone convicted of publishing Microsoft's dirty laundy is enjoined from using any other operating system for life. It's Microsoft only, baby!
Repeat offenders are enjoined from using any operating system other than Windows ME.
And for the hard-core cases... they bring out BOB.
What, do you honestly think that there are no Unix systems anywhere within the Microsoft organization?
Of course they'll have some Unix boxes around, just as I'm sure Sun has some Microsoft boxes around. Even if they don't actually run applications on them (doubtful), they'll want them for competitive analysis for their marketing people. It's hard to compete if you don't know what the competition is doing.
"Eating your own dog food" is a well-known expression, esp. common in Microsoft, that refers to products mature enough that you use them yourself.
One of the primary uses for the phrase is when you can use your compiler to compile your own compiler. That's a major milestone that indicates the product is actually useful for a non-trivial task.
Another example is using your own accounting software to maintain your own books. Or your own mail software to manage your own mail system.
It's more fun to ask WHY this has happened.
Grandpa probably paid no income taxes until he was well established, and even your father paid far less taxes than you will. It's not just a matter of earning more, there's a far higher tax burden today than in the past, even before you toss in FICA taking money out of the first dollar you earn.
Grandpa probably started out in a room at the Y with a hot plate, maybe, and a common bathroom down the hall. Your father probably started out in a small efficiency. But today it's hard to find cheap but safe housing - almost everyone would rather pay hundreds per month for every luxury today, than save and invest the money so that they might be able to afford their own property with the same amenities in a decade or two.
Grandpa probably walked to work, or rode a tram. People lived in cities close to work, not in suburbs. Your father could have ridden the bus, or gotten a used car with minimal features. But today you need a car (unless you're in some core cities), and that car has a laundry list of federally mandated safety features and a second laundry list driven by market forces.
Ditto laundry, clothing, travel and recreation, etc.
Don't get me wrong - life today is far more comfortable and safer than in your father's or grandfather's day. But it is also much harder to get established, and even people who are willing to make short-term compromises for long-term benefit find it difficult because of the lack of availability.
As you said, only if they don't redistribute the changes. That covers in-house use and pure client/server "black box" implementations (where the GPL code sites on a server, never exposed to the client), but not distribution to clients of compiled or other derived products.
Since these companies are claiming that the code released by the primary infringer contains their propietary code, I don't see how any of them can make meaningful claims that they aren't distributing their changes - if they weren't distributing the changes, how did the primary infringer get the code to provide to this guy? Maybe there's a reasonable explanation out of this paradox, but it seems that the burden of proof is on them to defend their use of his code at this point.
(N.B., this doesn't mean that he has any right to their code either - but these intimidation tactics have got to stop. Everyone is entitled to their IP rights, not just companies with an arrogant attitude.)
I'm pissed. Who's your chickenshit lawyer so we can all avoid him ourselves?
EACH AND EVERY ONE OF THESE COMPANIES threatening you if you publish their propietary code has, indirectly, admitted to ripping you off. THEY are the ones who should be sweating, they have no right to the code that they wrote proprietary extensions to and it's black letter law that you have the right to order them to immediately cease and desist any and all future infringement of YOUR code.
This may put the companies out of business, or expose them to massive suits for non-performance. IT'S NOT YOUR RESPONSIBILITY. They are violating your IP rights, you have the unconditional right to order them to stop regardless of the consequences to them.
It won't take them long to realize that they have two options. One, they can lay off everyone (you've killed their product!) and sue the original infringer for damages while their clients sue them. They can't threaten you for exercising your own rights, especially after they tried to do it to you!
Or two, they can pay you a reasonable fee for the right to use the code in a proprietary product. Say, something between $20k-$50 plus the right to distribute the code in the infringing product today under any and all licenses you choose. If they want to pull code out, they can... at their expense. Just because something is released under the GPL doesn't mean you can't also license it for proprietary use.
Meanwhile expect to see the original infringer get hit with massive suits for fraud. They may think they pulled a fast one on you, but as long as you stand up for your rights you may yet have the last laugh as that company is forced into bankruptcy for stealing your code and presenting it as its own.
(IANAL disclaimer, etc.)
You can use PKIX (X.509 certificates) with much of this infrastructure - Apache + mod_ssl, innd, ldap, postgresql and mysql, etc. The main hassle is that the different applications don't (yet) have the same view of how certs should work... and many don't yet require checking full certificate chains because the non-crypto core developers don't want to drive away users without a full PKIX intrastructure.
Now if only ssh would use conventional certs....
The biggest flaw in the "fewer workers, same output, higher productivity" is that it's eating the seed corn.
To be sure, there are many jobs there this doesn't matter. Perhaps most jobs.
But development is different. We need downtime to make the next big leap. When we're in the active development phase, we can productively spend 40 hours/week doing real work. Hell, those of us who got into this field because we like it, not because it seemed like the easiest way to make some big bucks, will probably want to work far more than 40 hours/week because of the sheer joy of producing something.
But when that's over, the fields need to lay fallow for a while. If you try to keep the same pace up, just like a crop field you'll see your the true productivity fall off.
At this point some fool suggests bringing in new people - equivalent to changing the fields - but that doesn't work either since it limits your product development to what can be comprehended and enhanced in the period between hiring and burnout. Assuming you can even reliably identify suitable candidates.
It's no secret that many of us have been attracted to OSS, in part, because of the fact that this change in environment allows us to remain productive far longer than we would be if we just kept doing the same thing. Ironically, this outlet isn't available to us when we succeed in finally finding a job that lets us use Linux in the workplace.
IIRC, the "remove me" line is not required by any federal law. (Some states may require it.)
However, the spammers are cutting their own throat with it. Citing S.1816 (or whatever) as proof that the message "cannot be considered spam" is a lie. There is no, and has never been, any law of the United States passed by the Senate alone.
That's somewhat abstract - although it's still a criminal act in some states to claim something is the law when you know it is not. But the promise to remove the person's email address from future mailings is a very specific claim. This means that the spam is asking for something of indeterminant but real value (a valid email address which can be sold to other spammers) in exchange for a specific promise you have no intention of keeping. That's fraud, and I wouldn't mind seeing every spammer who makes that claim get hit with a warning letter followed by a stiff penalty.
As others have pointed out, this content would be illegal no matter how they distribute it. You can't take a magic pill to grow larger breasts, a bigger dick and get a new credit card despite your horrible credit history.
But even setting that aside, I dare you to show me ANY precedence for your right to come into my house, raid my refrigerator, cook a meal on my stove, eat it on my plates, then leave the mess in the middle of my living room to poison my dog.
Yet that's exactly what spammers are doing (in a rhetorical sense) when they use my domain name to send out their crap, or abuse an open mail relay, or use poorly designed forms on some web site to send their messages to others. They're deliberately and willfully using my resources and good reputation to their own benefit, without my consent and without any renumeration to me.
Like you, I have very mixed feelings about government regulation of spam where the company has the balls to stand behind its own message. Let me blackball them myself. But I have no more qualms about the government cracking down on spammers who "borrow" my good name or resources than I do about the government cracking down on criminals who "borrow" my car, or "borrow" my credit card, etc.
I have a mail folder boringly labeled "send to ftc," and every 6 hours a cron job forwards the contents of the folder to the FTC.
This usually means that once a day I eyeball the contents of my "spam" folder to make sure there are no false positives, then move everything over to the other folder. Plus about a half-dozen messages that make it into my main mailbox.
But something I have not yet gotten a good answer for is what format to use when sending the spam to the FTC. I want to preserve the original headers (to help determine when open relays are being abused, headers forged, etc.), but that's surprisingly hard to do right. And do I strip out the spamassassin headers, or leave them in?
My current approach is to mime-encode the entire message (content-type: message/rfc822) and send it in a new envelope. I hope they know how to decode it, but Mozilla (annoyingly) doesn't. That makes it hard to verify your scripts before making them live.
Laws like that are almost inevitably racism or similar bigotry masked by a seemingly innocent law.
To give a contemporary example with extremely offensive (and inaccurate) stereotypes, consider a hypothetical 1950s law prohibiting the eating of fried chicken and watermelon on the front porch.
Do you think the authors were really dealing with a problem of greasy chicken bones and slippery watermelon rinds on the nearby sidewalks?
Or do you think the law might be a not-so-subtle way of keeping certain people out of sight?
I have no idea which group beat their rugs on the front lawn, and which group found it a convenient way to "put them in their place," but I would lay long odds against the law actually dealing with an excess of public carpet floggings.
One of the most damning comments in the article seems to have been overlooked.
"Two days later, 275 messages were opened (out of a half million, remember) and 65 surveys completed...." (paraphrased). Gee, how the hell did she know how many messages had been read?
Maybe she's just counting the number of hits on a specific image on her server... but it seems much more likely that she's using a mailbug. If only 275 people, out of 500,000, even opened the message then these are the morons you want to include in all future mailings.
Canada may claim it is territorial waters, but the US has a stronger case in the claim that it's still an international strait and free passage cannot be denied or taxed.
Ironically, Canada itself contains one of the best precedents of this - the St. Lawrence Seaway is an international strait from the Atlantic Ocean to the Great Lakes, even though substantial stretches of it are Canadian territory on both banks. (Other stretches have Canada on one side, the US on the other.)
There's also the pesky fact that the Canadian waters do not cover the entire distance - the western terminus will be in either US or Russian waters, and the US could use Canada's own claims to claim all sea ice and surrounding waters to the North Pole itself.
Actually, the more you study this stuff the more you worry that some of the them could pose a real threat. Diseases are obvious, as are volcanoes when you realize we haven't had a decent eruption since the early 19th Century... but that even a Tambola-level eruption is nothing compared to a supervolcano like Yellowstone.
The problem with these analyses is that it often overlooks how little commercial support really gets you. Esp. if you're looking at very long duration projects with limited resources to pay somebody to support your platform long after everyone else has moved on.
Let's set the way back machine back about the same number of years, let's say to 1994. You develop an application and buy hardware....
Your Linux solution is running a pre-1.0 kernel on a box that runs under 100Mhz. If you need to recompile it to work on new hardware and OS when your old system bites it, you can.
Your Windows solution is running on Windows 3.1. Good luck getting support for it. If you are willing to pay for a whole new development cycle, you reinvented it for Windows 95. Good luck getting support for it. Ditto your upgrade to NT4, which also required all new hardware.
The cold hard truth is that when you're looking at a long window, you MUST have FULL source or you're hosed. At some point you're going to need to run on hardware that's no longer being made, or your hardware will require some driver that you can't get without upgrading your OS, etc.
Yeah, yeah, yeah, but in reality whoever you vote has to work with Congress as a whole. When the balance is close, you may be better off voting for the less desirable local candidate so you have a more desirable national party.
This is especially true this year. Control of the Senate may hinge on a single election, and you have to trade off the consequences of voting for the "good" candidate, but putting the "bad" party in control of the Senate, vs. the "bad" candidate and putting the "good" party in control.
This seems backwards, with a list of hashes hardcoded into the kernel.
/proc FS but that's one obvious place to publish it.
:-)
I gave this some thought a while back, and more from the perspective of the user-space loader, and decided that it made much more sense to compile a public key into the kernel and cryptographically sign all trusted binaries.
The result is similar - you still have to verify the checksum before you load the file, but instead of having a hardcoded list of hashes that could be a maintenance nightmare you just check the checksum attached to the file itself.
It would also be easy for the kernel to determine that an executable was signed. Or you could be a bit more intelligent and stuff the signatures within the ELF file as an extension - this would allow you to protect the executable code, yet allow the initialized data (which could contain messages, etc.) to be modified.
The kernel would then only need to have a few public keys (or certs) - the project itself, an integrator, perhaps a local developer or two. Private keys, needless to say, should never be stored on the system.
All that remains is monitoring the list of authorized keys. That would be easy to do; I don't remember if BSD has a
Of course, since this is all blindingly obvious (it has to be, if I came up with it on my own with a few minutes thought) I'm sure that the USPTO has given a patent for it to somebody. Probably Microsoft.
That claim misses the point. The countless complaints about PayPal aren't due to claims that it was insolvant, but because it was transferring funds without the owner's consent and then dragging its feet in resolving the complaint.
Here's a hint: with very little information anyone can create false documents to access my checking account. It is trivial for anyone who had legitimate access to one of my checks. They'll probably even manage to get them cashed. But the back cannot refuse to acknowledge my complaint of criminal fraud, and I'll probably get my money back immediately if the signatures don't match at all, etc.
IIRC, the fighters were built from recovered death glider parts (the first one almost exclusively, the second with much more Tor'ii parts), and the cruiser was mostly built from the baby Go'ulds in Oregon. Or wherever "Nightwalkers" was set.
As for the "rare mineral," haven't you noticed that about every third episode involved trade negotiations, especially for Naquadaa? Some of these planets may have been "mined out" for the amounts required by the Go'uld, yet still worth operating for the quantity earth needs at this time.
Yeah, and what's with that bald chick in the Star Trek movie? I mean, that ruined it for me.
I'm so glad I haven't wasted any of my time with the subsequent movies or series. I mean, if it's that bad on the first movie you shudder to think of how bad it must have been by, oh, the 4th or 5th year of the first spinoff series.
Of course this is evil. It is a company doing something that it damn well knows will be offensive to the other party, but trying to sneak it through by willfully keeping that other party in the dark (by having their agent click through the EULAs) or intimidation once discovered.
Think about it this way: if they truly had nothing to hide, they wouldn't hide. The company wouldn't hesitate to admit the fact that it's collecting data, and what data it is collecting, up front. Just like a Nielson ratings household. The mere fact that they go to such lengths to hide the presence of this software screams to a "guilty mind."
As for your analogy to the sniper, that's obscene. I'm horny, where's your sister (or underage daughter), I want to fuck her. She may call it rape, but hey it's not like I shot 14 people, killing 10, so she can't complain. I mean, it's not like I KILLED her and 9 of her friends, now is it?....
Shocked? Good, now maybe you'll understand that ethical behavior is absolute, not relative. In fact, in this specific case the data collection may be more evil than the cold-blooded murder of 10 people since the information collected could potentially be used to identify suitable victims of a serial rapist/murder. It would not be the first time that databases have been used in this way, and in fact any ethical database designer knows this and will go to some effort to prevent "find me a victim" type queries.
I was halfway through my SCSA cert exams before starting my current job (where our servers use Solaris 8), so I think I have some knowledge of how Solaris stacks up against Linux and OpenBSD....
On the one hand, it does integrate some nice technology that the free systems lack. Most of the core technology is very stable.
But on the other hand, it's about a decade behind the time on some very fundamental items. Packet sniffers, and the need to use ssh/scp instead of telnet/ftp, don't appear to exist in the Solaris world. They aren't installed by default, they aren't covered by the exams. It doesn't come with a compiler. Etc and so on.
Sure, it's possible to install the GNU packages to add the missing functionality, but this misses the point. I would much rather use something like OpenBSD (where I have a solid system that I have to add applications to) than Solaris (where I might have an integrated environment, but then have to spend hours securing to modern practices). If I overlook something, the damage on OpenBSD will be far less than on Solaris.
This is... bizarre.
I don't know anyone who runs Solaris on a x86 because they like Solaris on an x86, but it's a very good platform for keeping current on your Sun sysadmin and netadmin skills or prepping for the cert exams.
And that, in turn, affects our employer's decision on which hardware to buy when they need honking big servers.
Microsoft, for all of its other faults, does understand that the developers and admins are key people to get in the loop. These programs can be a real pain if you're a small consulting firm, but if they think you're large enough to be throwing business their way you can get access to a lot of software so your familiarity with it may be a line item when the CIO decides which package to purchase.
So why is Sun pissing on the SCSAs and SCNAs? They don't need to worry about the people who are already using Solaris-on-Sparcs at work, they need to worry about the people who are using HP/UX or AIX or Linux or *BSD and might not remain current on what Solaris offers unless they have that low-cost box to play with.