So, Is it lust when a 4-digit UID does it? If so, I'll make sure not to... Ewww. Listed after by a guy with the online nick of Violated;) In all seriousness, tho, sorry about the nick issues, Rob. It does suck when something as basically identifying as a nick get removed AFTER you've been using it.
Lots of places have these; I see someone say "There are only a few in production" fairly often, but this is incorrect; there are more and more every year. Dairy farms are using them in large numbers, but the city of portland has a fairly large one (see http://www.energy.state.or.us/biomass/fuelcell.htm )
that processes the residue from 82 million gallons of wastewater a day.
As an example of the economics, see: http://www.eco-farm.org/sa/sa_dairy_synopsis _diges ter.html#eco
Payback in 6 years. Not bad, considering lots of places give grants, as these help cut down on groundwater pollution. You can have payback in 3 years, and then start making money on the juice you sell.
Using a pair of Intel EEPro 100's w/ trunking (using both links at the same time on one IP, works w/ a cisco switch), I've gotten over 100 Mb/sec of actual throughput (I think I hit 137 Mbit/sec, peak) out of a box using NBD to create a mirror'd RAID volume over the trunked ports. Now, my actual 'real' data speeds to the file ssystem were about half that (Call it 50-65 Mbit, or 6 to 7.5 MByte/sec), due to mirroring == writing it twice. Still not bad. Yes, the target disks were themselves part of other RAID volumes, for speed:)
What is it: With this thing compiled into your kernel, Linux can use a remote server as one of its block devices. Every time the client computer wants to read/dev/nd0, it will send a request to the server via TCP, which will reply with the data requested. This can be used for stations with low disk space (or even diskless - if you boot from floppy) to borrow disk space from other computers. Unlike NFS, it is possible to put any file system on it. But (also unlike NFS), if someone has mounted NBD read/write, you must assure that no one else will have it mounted.
Limitations:It is impossible to use NBD as root file system, as an user-land program is required to start (but you could get away with initrd; I never tried that). (Patches to change this are welcome.) It also allows you to run read-only block-device in user-land (making server and client physically the same computer, communicating using loopback). Please notice that read-write nbd with client and server on the same machine is bad idea: expect deadlock within seconds (this may vary between kernel versions, maybe on one sunny day it will be even safe?). More generally, it is bad idea to create loop in 'rw mounts graph'. I.e., if machineA is using device from machineB readwrite, it is bad idea to use device on machineB from machineA.
Read-write nbd with client and server on some machine has rather fundamental problem: when system is short of memory, it tries to write back dirty page. So nbd client asks nbd server to write back data, but as nbd-server is userland process, it may require memory to fullfill the request. That way lies the deadlock.
Current state: It currently works. Network block device seems to be pretty stable. I originaly thought that it is impossible to swap over TCP. It turned out not to be true - swapping over TCP now works and seems to be deadlock-free.
If you want swapping to work, first make nbd working. (You'll have to mkswap on server; mkswap tries to fsync which will fail.) Now, you have version which mostly works. Ask me for kreclaimd if you see deadlocks.
Network block device has been included into standard (Linus') kernel tree in 2.1.101.
I've successfully ran raid5 and md over nbd. (Pretty recent version is required to do so, however.) "
Why not actually wait until they formally announce the product and see what they have to say?
I would hazard a guess that RedHat will take the time between certs and the major number incrementing into account. Historically, they've handled new major releases based on Binary Compatability and new feature-sets. Honestly, they would have no reason to annoy all of their certified folks, as RHCE's are the best proponents of their software and service!!! Rather than b**** and moan on slashdot, why not wait the whole week or two *until it is actually released* and see if they release an updated policy that states what they're going to do about it? I've been an RHCE since 1999, and they've been very fair with me. Yes, I'm biased as I *am* an RHCE, but since this affects *my* certification levels, and I'm perfectly willing to wait a whole week or two to get data BEFORE I complain, can't you all do the same? Sheesh, so many people complain before they have anything to complain about.
We have OLD Cobalt Raq3's (300 MHz AMD K6, 128 MB Ram, single IDE drive) running the latest Cobalt OS, and we JUST had one of these boxes get hammered this week; in a 12 hour period, it handled 625,000 hits (mostly CGI's, but it had a reasonable amount of static content), and at the same time handled 35,000 POP requests, sent 4,500 emails, and did some other random functions (and things like hostname lookups are enabled for weblogs, FTP uploads are happening for weather-wite webcams that were associated with the heavy traffic, etc, so there's obviously not a huge amount of "tune it till it's ONLY gonna do one thing" going on here). Now, the box was taking a whipping compared to it's normal load, but c'mon. I can't say the "Poor little 550 MHz UltraSPARC story" makes me tear up:-)
One thing I didn't see many if any people mention is reliability and redundancy. Where we live, the historical bandwidth providers are the telcos, who have flatly had a terrible record of keeping their connections working. The FIBER might be up, but the connections to the providers the telco'suse for IP may be down. One example is that a local telco uses nothing but UUNet/Alternet for their entire IP connectivity if you buy a internet pipe from them. They have 1 link to Indianapolis, and another to St. Louis. When they've had problems in the past it goes to pot quickly, especially since if there's a UU/Alternet issue, it doesn't matter which path is 'up', there's still an issue.
Other Internet providers deal with this by selling local customers a 'local' T1 or DS3 or fiber into their data center. From there, said data center will have 2, 3 or more IP carriers, all hopefully riding different fiber providers via totally different physical connection paths to the outside world, hopefully going through physically diverse pieces of network gear.
That's how we do it, for example:-) It does mean that customers pay for that duality of gear and network connectivity. However, the flip side is that theoretically, they shouldn't go down, unless the single piece of gear their single T1 plugs into goes down for maintenance or failure (and since you've cut the failure prone pieces of gear down to 1, and that 1 is a incredibly simple piece of gear compared to the other stuff and can be replaced in minutes if not seconds, your failure times go down). If you HAVE to be up, then get a second T1 at your location to another Provider who hopefully uses a different IP carrier, using a different fiber provider, using a different physical path, and who hopefully has his own 2 IP carriers, etc etc etc.
That's where the real cost of bandwidth can be inflated. Just having a 100 Mb/s line to the internet can be cheap. Having one that's always up, regardless of physical, fiber, or IP carrier failures may not be especially if you don't have the expertise to manage BGP and gear that supports it.
Dow's Responses
on
Dow vs. Parody
·
· Score: 5, Insightful
Far be it from me to think walking away from an ecological disaster is a good thing, but from what I can see, according to both the US and Indian courts, Dow has done everything they said they'd do relating to this, and everything the lawsuits against them said they had to do.
The paid ~$500 million to the Indian Government for ongoing cleanup, to create a medical program for anyone who lives in the affected area, and to cover things like ongoing monitoring of the chemical creep. They also paid out an additional ~$20 million to build and maintain a new hospital specifically in the area to handle any related medical claims. They also added an additional ~$55 million dollars to the hospital support funds when they bought out UCI.
They actually have paid out far more than the lawsuits against them in US courts originally stated (where the Indian government received a ruling for ~$350 million). I think all told that Dow has produced over $600 million for cleanup and ongoing support and healthcare.
All in all, most of the cleanup, treatment and monitoring of chemical contamination in the area is supposed to be handled by the Indian Government, not by Dow directly. If those hundreds of millions of dollars are being spent somewhere else, are people asking the government (or whoever they've appointed to handle the situation) where it's going?
This is especially apt as many of the court cases have focused on Dow's liability, and the majority still uphold the 'reasonable doubt' that Dow was criminally liable (which is why they still haven't tried very hard to get Warren Anderson shipped their for homicide charges), and even some went so far as to support the findings of 3rd party teams that the chemical release was a result of a deliberate act by a disgruntled worker.
Now, it's been 18 years, and I don't personally have any knowledge of anything to do with Bhopal beyond what I can read. However, based on that information, I think a lot of this is the result of PR by Greenpeace and others who conveniently ignore the things that Dow *has* done.
As an aside, I don't work for Dow, have any relatives who work for Dow, or own stock in Dow (unless one of those pathetic 401k funds that are basically WORTHLESS right now has shares, in which case I don't give a damn). I just see a lot of knee-jerk reactions and wonder if a lot of people who 'know about bhopal' have ever done more than read 1 website or less? Could Dow be a tool of Satan designed to make life on Earth a living hell, run completely by unfeeling demons who want to kill and maim innocent people? Sure. Is it probably that black-and-white? I really doubt it. It's only fair to research both sides.
But I'm also not necessarily representative of most COBALT users. People who CAN build from source are generally not the target audience of the machine. They BOUGHT a Cobalt server as an appliance, which is what SUN markets it as. SUN says not to ever touch the CLI, as "The GUI does everything you need".
People buy a Cobalt from a big name vendor so they get the stability and resource-friendliness of Linux with (theoretically) the SUPPORT (in terms of patches and making the software easy to use and documentation) of a big name vendor.
So that's the problem.
(I love trolls who are such wizards about all this, but still post anonymously)
If they are so *&*^ serious about security? The slapper worm has been out for quite a while now, and Sun's cobalts run a REALLY old version of OpenSSL. Sun's last patch was released almost a month ago, for a CGI vulnerability. They've been asked dozens of times about the OpenSSL patch, and won't even give customers the courtesy of a "We're going to have one by X" response. CobaltOS is just a flippin' rebuilt RedHat OS; it isn't hard to patch!
I've used several cards using drivers by lnz@dendelion.com; I think the first 'totally built from scratch to be a Linux server' machine I ever put together used a 53c875 Symbios chip, and he helped me get it running at top speed to show off Linux's speed for a database. This would have been better than 5 years ago, at least. We'd been using Linux a lot longer than that on 'stock' machines, but needed some more 'umph' than we could get, and he was a great resource for support and friendly help. He'll be missed.
I know the LWE 'party' is gonna be at Jillians. Is there a Dave and Busters in San Fran? Great food, drinks, and video games all together:-) Love the one in Austin.
I just used the first message for an example; he sent several, and I couldn't locate all of them in the court docs to add their exact size(that's a LOT of time). I played the "Assume they're sent in blocks of 100, and each block has a certain number of CC lines in the header, each containing 6chars+@+intel.com=16*100=1.6K of just CC crap. That's part of it. Also, assume some of them contained other formatting crap, possibly HTML, and that after his initial, somewhat small outburst, he had more ammo/content to put into his emails" game, and thought 10K was a pretty darn small size, all things considered. And it isn't just storage space it uses; it's bandwudth each time they're clicked on as data comes from the server to the desktop (whether it be Notes, IMAP, Exchange, etc) or when they're POP'd, plus the employee time (read, delete or read, respond, complain, delete or whatever) plus backup space on tapes, etc. So, it's a min of a few GB compabined of online or offline storage and bandwidth, plus all the wasted people time.
In this case, I have an existing business relationship w/ Intel, so I'm using their business-provided system for business purposes, and I assume any SANE human who would email to complain would not be emailing *29,000* mailboxes at Intel to bitch. AND if I were to complain once in such an insane manner, and they tell me to quit, and I continue to do it via email, then I would expect to be sued, yes.
He sent six emails; five of these were sent after being told explicitly by Intel to cease. He explained to the court he would continue to evade Intel's attempts to block him from sending email. So the courts ruled against him in no uncertain terms. He wasn't taken to court for the first one, but rather for the second one.
Th other factor you even mentioned above: "when they use a public facility as it is designed to be used". Intel's mail system was designed as a method for people to communicate w/ Intel employees for business purposes. This was not a business purpose. Again, the system is being abused after first notice of a cease and desist request.
I just went and checked the court docs: He sent 6 emails to *29,000* employees. None of them signed up for it; he had the lists himself. So, the basic bare ASCII text of the first email was approx 5K, add in headers and such and guess his avergae email size utilized was 10K.
6 * 29,000 * 10 / 1024 / 1024 = 1.65 GB of email.
Now, I ain't counting logs and all that other stuff. I'm sure this isn't a huge amount of email to Intel, but it's a helluva lot more than the story suggests. I think the big thing isn't even the size, but the scope. I mean, *29,000* people got spammed, basically. This wasn't just a few emails!
Re:If someone uses my computers, they pay
on
More on Intel v. Hamidi
·
· Score: 3, Insightful
There's the rub: Employees do not own their email addresses at almost any organization; it is a resource provided for them by the company for the employee to produce work for the company benefit, much like the desk, chair, and computer they sit at. I know Intel has an internal computer use policy employees have to agree to as part of their employment agreements, and it includes a statement of this fact. The agreements also include that all emails are to be considered company property, etc etc. Employee rights w/ regards to company-provided email are in fact very limited, especially (as in this case, for example) when the company has gone to special steps to make that very clear (computer use policies, etc).
I can't see why this is an issue, at all. The email was not directed at the employees of the company for a business purpose; The purpose of the email system is for business use. I think Intel has every right to block email and/or refuse any user the right to send mail to that system, as every bit that goes through does incur a monetary cost to them (bandwidth, disk storage, etc) no matter how small that cost may seem. If someone was to walk thru my yard, and pull up one blade of grass, no big deal, right? But legally, I have the right to have them stopped, and if they persist, take action against them. As soon as I lose the legal protection to have this stopped, I suddenly have the very real risk of having THOUSANDS of people run thru my yard, each taking one blade of grass. Now, I have to pay $1,000s to get the yard fixed. Same scenario, just with email. Sending email to the system once could be (to a certain degree) justified, even though he knew in advance (per testimony) the reception by Intel would not be in his favor, but repeating his actions once notified of their intent to prevent his access to sending emails through the COMPANY mail system was not. Note: there is no legal prohibition to him setting up domains, giving away email at his expense to any Intel employee, or sending email to their personal accounts on any non-Intel system, but Intel has every right to protect, in any small way, their internal COMPANY system. I back them 100% in this; those who don't agree, consider what would happen if you were on the other end of the stick.
That's the book he wrote about this. Worth a read, it even describes some of the projects by the US and Russia concerning this decades ago, in the appendix.
http://www.gppf.org/events/oswindle.htm
Shows the FTC doing the exact same thing and discussing it in the 1990's. Sheesh, stuff from 3-5 years ago isn't exactly new:-)
Slashdot Mirror
So, Is it lust when a 4-digit UID does it? If so, I'll make sure not to... Ewww. Listed after by a guy with the online nick of Violated ;) In all seriousness, tho, sorry about the nick issues, Rob. It does suck when something as basically identifying as a nick get removed AFTER you've been using it.
That was fast. I even tried to hit it before it went 'live', and it was already /.'d. *sigh*
http://www.energy.state.or.us/biomass/digester/dig estech.htm
m )
s _diges ter.html#eco
Lots of places have these; I see someone say "There are only a few in production" fairly often, but this is incorrect; there are more and more every year. Dairy farms are using them in large numbers, but the city of portland has a fairly large one (see http://www.energy.state.or.us/biomass/fuelcell.ht
that processes the residue from 82 million gallons of wastewater a day.
As an example of the economics, see:
http://www.eco-farm.org/sa/sa_dairy_synopsi
Payback in 6 years. Not bad, considering lots of places give grants, as these help cut down on groundwater pollution. You can have payback in 3 years, and then start making money on the juice you sell.
Using a pair of Intel EEPro 100's w/ trunking (using both links at the same time on one IP, works w/ a cisco switch), I've gotten over 100 Mb/sec of actual throughput (I think I hit 137 Mbit/sec, peak) out of a box using NBD to create a mirror'd RAID volume over the trunked ports. Now, my actual 'real' data speeds to the file ssystem were about half that (Call it 50-65 Mbit, or 6 to 7.5 MByte/sec), due to mirroring == writing it twice. Still not bad. Yes, the target disks were themselves part of other RAID volumes, for speed :)
http://www.vanheusden.com/Loose/nbdsrvr/
(I haven't used this, but it exists)
NBD *is* standard Linux kernel. It's built right in: /usr/src/linux-2.4/Documentation/nbd.txt
D _w ork_with_heartbeat
If you're curious about using the enhanced NBD w/ failover and HA, you can read about it at:
http://www.it.uc3m.es/~ptb/nbd/#How_to_make_ENB
http://nbd.sourceforge.net/
/dev/nd0, it will send a request to the server via TCP, which will reply with the data requested. This can be used for stations with low disk space (or even diskless - if you boot from floppy) to borrow disk space from other computers. Unlike NFS, it is possible to put any file system on it. But (also unlike NFS), if someone has mounted NBD read/write, you must assure that no one else will have it mounted.
"Network Block Device (TCP version)
What is it: With this thing compiled into your kernel, Linux can use a remote server as one of its block devices. Every time the client computer wants to read
Limitations:It is impossible to use NBD as root file system, as an user-land program is required to start (but you could get away with initrd; I never tried that). (Patches to change this are welcome.) It also allows you to run read-only block-device in user-land (making server and client physically the same computer, communicating using loopback). Please notice that read-write nbd with client and server on the same machine is bad idea: expect deadlock within seconds (this may vary between kernel versions, maybe on one sunny day it will be even safe?). More generally, it is bad idea to create loop in 'rw mounts graph'. I.e., if machineA is using device from machineB readwrite, it is bad idea to use device on machineB from machineA.
Read-write nbd with client and server on some machine has rather fundamental problem: when system is short of memory, it tries to write back dirty page. So nbd client asks nbd server to write back data, but as nbd-server is userland process, it may require memory to fullfill the request. That way lies the deadlock.
Current state: It currently works. Network block device seems to be pretty stable. I originaly thought that it is impossible to swap over TCP. It turned out not to be true - swapping over TCP now works and seems to be deadlock-free.
If you want swapping to work, first make nbd working. (You'll have to mkswap on server; mkswap tries to fsync which will fail.) Now, you have version which mostly works. Ask me for kreclaimd if you see deadlocks.
Network block device has been included into standard (Linus') kernel tree in 2.1.101.
I've successfully ran raid5 and md over nbd. (Pretty recent version is required to do so, however.) "
Why not actually wait until they formally announce the product and see what they have to say?
I would hazard a guess that RedHat will take the time between certs and the major number incrementing into account. Historically, they've handled new major releases based on Binary Compatability and new feature-sets. Honestly, they would have no reason to annoy all of their certified folks, as RHCE's are the best proponents of their software and service!!! Rather than b**** and moan on slashdot, why not wait the whole week or two *until it is actually released* and see if they release an updated policy that states what they're going to do about it? I've been an RHCE since 1999, and they've been very fair with me. Yes, I'm biased as I *am* an RHCE, but since this affects *my* certification levels, and I'm perfectly willing to wait a whole week or two to get data BEFORE I complain, can't you all do the same? Sheesh, so many people complain before they have anything to complain about.
We have OLD Cobalt Raq3's (300 MHz AMD K6, 128 MB Ram, single IDE drive) running the latest Cobalt OS, and we JUST had one of these boxes get hammered this week; in a 12 hour period, it handled 625,000 hits (mostly CGI's, but it had a reasonable amount of static content), and at the same time handled 35,000 POP requests, sent 4,500 emails, and did some other random functions (and things like hostname lookups are enabled for weblogs, FTP uploads are happening for weather-wite webcams that were associated with the heavy traffic, etc, so there's obviously not a huge amount of "tune it till it's ONLY gonna do one thing" going on here). Now, the box was taking a whipping compared to it's normal load, but c'mon. I can't say the "Poor little 550 MHz UltraSPARC story" makes me tear up :-)
One thing I didn't see many if any people mention is reliability and redundancy. Where we live, the historical bandwidth providers are the telcos, who have flatly had a terrible record of keeping their connections working. The FIBER might be up, but the connections to the providers the telco'suse for IP may be down. One example is that a local telco uses nothing but UUNet/Alternet for their entire IP connectivity if you buy a internet pipe from them. They have 1 link to Indianapolis, and another to St. Louis. When they've had problems in the past it goes to pot quickly, especially since if there's a UU/Alternet issue, it doesn't matter which path is 'up', there's still an issue.
:-) It does mean that customers pay for that duality of gear and network connectivity. However, the flip side is that theoretically, they shouldn't go down, unless the single piece of gear their single T1 plugs into goes down for maintenance or failure (and since you've cut the failure prone pieces of gear down to 1, and that 1 is a incredibly simple piece of gear compared to the other stuff and can be replaced in minutes if not seconds, your failure times go down). If you HAVE to be up, then get a second T1 at your location to another Provider who hopefully uses a different IP carrier, using a different fiber provider, using a different physical path, and who hopefully has his own 2 IP carriers, etc etc etc.
Other Internet providers deal with this by selling local customers a 'local' T1 or DS3 or fiber into their data center. From there, said data center will have 2, 3 or more IP carriers, all hopefully riding different fiber providers via totally different physical connection paths to the outside world, hopefully going through physically diverse pieces of network gear.
That's how we do it, for example
That's where the real cost of bandwidth can be inflated. Just having a 100 Mb/s line to the internet can be cheap. Having one that's always up, regardless of physical, fiber, or IP carrier failures may not be especially if you don't have the expertise to manage BGP and gear that supports it.
Far be it from me to think walking away from an ecological disaster is a good thing, but from what I can see, according to both the US and Indian courts, Dow has done everything they said they'd do relating to this, and everything the lawsuits against them said they had to do.
The paid ~$500 million to the Indian Government for ongoing cleanup, to create a medical program for anyone who lives in the affected area, and to cover things like ongoing monitoring of the chemical creep. They also paid out an additional ~$20 million to build and maintain a new hospital specifically in the area to handle any related medical claims. They also added an additional ~$55 million dollars to the hospital support funds when they bought out UCI.
They actually have paid out far more than the lawsuits against them in US courts originally stated (where the Indian government received a ruling for ~$350 million). I think all told that Dow has produced over $600 million for cleanup and ongoing support and healthcare.
All in all, most of the cleanup, treatment and monitoring of chemical contamination in the area is supposed to be handled by the Indian Government, not by Dow directly. If those hundreds of millions of dollars are being spent somewhere else, are people asking the government (or whoever they've appointed to handle the situation) where it's going?
This is especially apt as many of the court cases have focused on Dow's liability, and the majority still uphold the 'reasonable doubt' that Dow was criminally liable (which is why they still haven't tried very hard to get Warren Anderson shipped their for homicide charges), and even some went so far as to support the findings of 3rd party teams that the chemical release was a result of a deliberate act by a disgruntled worker.
Now, it's been 18 years, and I don't personally have any knowledge of anything to do with Bhopal beyond what I can read. However, based on that information, I think a lot of this is the result of PR by Greenpeace and others who conveniently ignore the things that Dow *has* done.
As an aside, I don't work for Dow, have any relatives who work for Dow, or own stock in Dow (unless one of those pathetic 401k funds that are basically WORTHLESS right now has shares, in which case I don't give a damn). I just see a lot of knee-jerk reactions and wonder if a lot of people who 'know about bhopal' have ever done more than read 1 website or less? Could Dow be a tool of Satan designed to make life on Earth a living hell, run completely by unfeeling demons who want to kill and maim innocent people? Sure. Is it probably that black-and-white? I really doubt it. It's only fair to research both sides.
Let me think... Um, NO.
But I'm also not necessarily representative of most COBALT users. People who CAN build from source are generally not the target audience of the machine. They BOUGHT a Cobalt server as an appliance, which is what SUN markets it as. SUN says not to ever touch the CLI, as "The GUI does everything you need".
People buy a Cobalt from a big name vendor so they get the stability and resource-friendliness of Linux with (theoretically) the SUPPORT (in terms of patches and making the software easy to use and documentation) of a big name vendor.
So that's the problem.
(I love trolls who are such wizards about all this, but still post anonymously)
If they are so *&*^ serious about security? The slapper worm has been out for quite a while now, and Sun's cobalts run a REALLY old version of OpenSSL. Sun's last patch was released almost a month ago, for a CGI vulnerability. They've been asked dozens of times about the OpenSSL patch, and won't even give customers the courtesy of a "We're going to have one by X" response. CobaltOS is just a flippin' rebuilt RedHat OS; it isn't hard to patch!
I've used several cards using drivers by lnz@dendelion.com; I think the first 'totally built from scratch to be a Linux server' machine I ever put together used a 53c875 Symbios chip, and he helped me get it running at top speed to show off Linux's speed for a database. This would have been better than 5 years ago, at least. We'd been using Linux a lot longer than that on 'stock' machines, but needed some more 'umph' than we could get, and he was a great resource for support and friendly help. He'll be missed.
I know the LWE 'party' is gonna be at Jillians. Is there a Dave and Busters in San Fran? Great food, drinks, and video games all together :-) Love the one in Austin.
I just used the first message for an example; he sent several, and I couldn't locate all of them in the court docs to add their exact size(that's a LOT of time). I played the "Assume they're sent in blocks of 100, and each block has a certain number of CC lines in the header, each containing 6chars+@+intel.com=16*100=1.6K of just CC crap. That's part of it. Also, assume some of them contained other formatting crap, possibly HTML, and that after his initial, somewhat small outburst, he had more ammo/content to put into his emails" game, and thought 10K was a pretty darn small size, all things considered. And it isn't just storage space it uses; it's bandwudth each time they're clicked on as data comes from the server to the desktop (whether it be Notes, IMAP, Exchange, etc) or when they're POP'd, plus the employee time (read, delete or read, respond, complain, delete or whatever) plus backup space on tapes, etc. So, it's a min of a few GB compabined of online or offline storage and bandwidth, plus all the wasted people time.
In this case, I have an existing business relationship w/ Intel, so I'm using their business-provided system for business purposes, and I assume any SANE human who would email to complain would not be emailing *29,000* mailboxes at Intel to bitch. AND if I were to complain once in such an insane manner, and they tell me to quit, and I continue to do it via email, then I would expect to be sued, yes.
He sent six emails; five of these were sent after being told explicitly by Intel to cease. He explained to the court he would continue to evade Intel's attempts to block him from sending email. So the courts ruled against him in no uncertain terms. He wasn't taken to court for the first one, but rather for the second one.
Th other factor you even mentioned above: "when they use a public facility as it is designed to be used". Intel's mail system was designed as a method for people to communicate w/ Intel employees for business purposes. This was not a business purpose. Again, the system is being abused after first notice of a cease and desist request.
I just went and checked the court docs: He sent 6 emails to *29,000* employees. None of them signed up for it; he had the lists himself. So, the basic bare ASCII text of the first email was approx 5K, add in headers and such and guess his avergae email size utilized was 10K.
6 * 29,000 * 10 / 1024 / 1024 = 1.65 GB of email.
Now, I ain't counting logs and all that other stuff. I'm sure this isn't a huge amount of email to Intel, but it's a helluva lot more than the story suggests. I think the big thing isn't even the size, but the scope. I mean, *29,000* people got spammed, basically. This wasn't just a few emails!
There's the rub: Employees do not own their email addresses at almost any organization; it is a resource provided for them by the company for the employee to produce work for the company benefit, much like the desk, chair, and computer they sit at. I know Intel has an internal computer use policy employees have to agree to as part of their employment agreements, and it includes a statement of this fact. The agreements also include that all emails are to be considered company property, etc etc. Employee rights w/ regards to company-provided email are in fact very limited, especially (as in this case, for example) when the company has gone to special steps to make that very clear (computer use policies, etc).
I can't see why this is an issue, at all. The email was not directed at the employees of the company for a business purpose; The purpose of the email system is for business use. I think Intel has every right to block email and/or refuse any user the right to send mail to that system, as every bit that goes through does incur a monetary cost to them (bandwidth, disk storage, etc) no matter how small that cost may seem. If someone was to walk thru my yard, and pull up one blade of grass, no big deal, right? But legally, I have the right to have them stopped, and if they persist, take action against them. As soon as I lose the legal protection to have this stopped, I suddenly have the very real risk of having THOUSANDS of people run thru my yard, each taking one blade of grass. Now, I have to pay $1,000s to get the yard fixed. Same scenario, just with email. Sending email to the system once could be (to a certain degree) justified, even though he knew in advance (per testimony) the reception by Intel would not be in his favor, but repeating his actions once notified of their intent to prevent his access to sending emails through the COMPANY mail system was not. Note: there is no legal prohibition to him setting up domains, giving away email at his expense to any Intel employee, or sending email to their personal accounts on any non-Intel system, but Intel has every right to protect, in any small way, their internal COMPANY system. I back them 100% in this; those who don't agree, consider what would happen if you were on the other end of the stick.
Congrats Rob & Kathleen!!!
That's the book he wrote about this. Worth a read, it even describes some of the projects by the US and Russia concerning this decades ago, in the appendix.
http://www.gppf.org/events/oswindle.htm Shows the FTC doing the exact same thing and discussing it in the 1990's. Sheesh, stuff from 3-5 years ago isn't exactly new :-)
Go kill this one, too. I have my copy :-)
ftp://ftp.cdrom.com/pub/idgames/idstuff/wolf/l
inux/wolfmptest-0.7.16-1.x86.run
GET IT HERE
The link might work if slashcode doesn't kill the html by breaking the line *sigh*