You are exactly right. For the search engine site, Google could avoid a lot of misunderstanding by auctions off "days" rather than "clicks". Advertisers could bid for a word or word combination, for a particular day or week. The advertiser could easily discover if his ad was running, and what the sales results were. Revenue for Google would be the same - the ads wouldn't be worth any more or less to be priced this way, but Google wouldn't be rewarding click fraud, and wouldn't have to worry about suppressing it. Trouble is, this auction won't tell Google how to divide up the money among the "ads by Google" sites. Still it solves part of the problem.
Most of the drives in our NAS boxes and drive arrays claim a MTBF of 500,000 hours. That's about 2% per year. With three drives the chance of at least one failing is a little less than 6%. (1-(1-.98)^3). Our experience is that such numbers are at least a reasonable approximation of reality.
Suppose you have three drives in a RAID 5. If it takes 24 hours to replace and reconstruct a failed drive, one is tempted to calculate that the chance of a second drive failing before full redundancy is established is about.02/365, or about one in a hundred thousand. The total probability of a double failure seems like it should be about 6 in a million per year.
Our double failure rate is about 5 orders of magnitude worse than that - the majority of single drive failures are followed by a second drive failure before redundancy is established. This prevents rebuilding the array with a new drive replacing the original failed drive, however you can probably recover most files if you stay in degraded mode and copy the files to a different location. It isn't that failures are correlated because drives are from the same batch, or the controller is at fault, or the environment is bad (common electrical spike or heat problem). The fault lies with the Linux md driver, which stops rebuilding parity after a drive failure at the first point it encounters a uncorrectable read error on the remaining "good" drives. Of course with two drives unavailable, there isn't an unambiguous reconstruction of the bad sector, so it might be best to go to the backups instead of continuing. At least that is the apparently the reason for the decision.
Let's repeat the reliability calculation with our new knowledge of the situation. In our experience perhaps half of drives have at least one unreadable sector in the first year. Again assume a 6 percent chance of a single failure. The chance of at least one of the remaining two drives having a bad sector is 75% (1-(1-.5)^2). So the RAID 5 failure rate is about 4.5%/year, which is.5% MORE than the 4% failure rate one would expect from a two drive RAID 0 with the same capacity. Alternatively, if you just had two drives with a partition on each and no RAID of any kind, the chance of a failure would still be 4%/year but only half the data loss per incident, which is considerably better than the RAID 5 can even hope for under the current reconstruction policy even with the most expensive hardware.
A few years ago we had to put an ssh server on the telnet port, because one of our users was at the Federal Reserve Board, whose security committee hadn't approved outbound access to ssh servers on the usual port! In a telephone conversation with me, their security person suggested I turn on the telnet server at my end, and said that he had read about security issues with ssh that discouraged them from allowing it!
Lots (not all) IT security is just dumb rules of thumb with no analysis or understanding. Lots of IT staff don't think the other employees have work to do, and don't mind interfering with their efforts. As the years go by, management will become more experienced at understanding who is a blowhard and who knows what they are talking about. But it will take time.
When LinuxCare started, I called them about getting support from them. There were several plans, including just paying $350 "per incident". I thought about that for a while and concluded, that $350 was OK if they gave me a workaround or patched the software, but I was leary that they would take my money and tell me what I wanted wasn't supported. Almost any Linux problem can be closed as "not supported", since there is no real spec. (That applies double to windows). I didn't have any way of knowing what their attitude would be, so I let the matter drop. I wonder - does anyone know if they offered a worthwhile service to those who subscribed?
Video and sound card vendors need documentation from MS to write drivers. MS would ordinarily want big bucks for that, and the vendor wants to have something he can offer MS instead of money. So he keeps his interface a secret and offers that information in exchange. So MS and the vendor both sign non-disclosure agreements and exchange documents. It makes the vendor feel good to know he is involved in an equal exchange with MS, and not just a supplicant/customer. This benefits MS if it slows open source driver writers but I don't know how much effect there is. It might be small since Linux/*BSD machines are mostly servers, and don't have fancy video cards or sound cards. On the other hand, it may have helped keep Linux off the desktop and out of the home.
At the moment only the network card vendors lose anything from keeping the interface secret, and they don't lose much since the Linux kernel usualy ends up with decent drivers anyway, and if it doesn't most users can't tell the difference anyway.
Wouldn't it have made more sense for/. to wait a couple of hours before posting this? At least then there would the remote possibility that responses would be made after RTFA!
> you could never detect EOF's on pipes to fortran 77.
Well, I do it all the time:
read(5,*,end=99) a
branches to statement 99 on EOF, from a file or a pipe. This is exactly the standard, and works on all Fortran 77 compilers I have encountered, including Unix f77 and f2c.
Am I the only one who likes 5400rmp drives because he thinks they will last 72/54 times as long as 7200 rpm drives? We use large drives for backup, and since the access is all sequential, the high rotation speed isn't that important to us.
We like the 300 gig Maxtor Maxline II drives because they draw half the current of the 7200 rpm drives, and at 5400 rpm they should last at least 7200/5400 times as long. Of course with only 12 drives we can't really confirm that, but we have had no failures.
I thought the basis of SCOs claim was that IBM had revealed trade secrets. In that case, SCO has a strong obligation to take care that the secrets are not revealed, as would IBM. But once the secrets become public knowledge, they are freely available to anyone - SCOs only recourse is against IBM for damages. The fact that SCO published the secrets themselves would be a difficult problem for them to overcome if they sought to prevent a third party from using the material. Perhaps they could appeal to copyright law to protect the former secrets, but they would have to reveal just what they thought had been copied, even under DMCA.
Try ww.nearlyfreespeech.net. They offer web hosting for $1/gigabyte downloaded. Then just
put the problem file there and link your downloaders to it.
The trouble with most billing methods is that
they are generally non-linear, with a huge
increase in the per byte cost once you exceed
some contracted amount. Burstable billing is
the worst - if someone comes along with a big
pipe and downloads for 6% of the month, you
can have a huge bill for a modest amount of
bytes.
Tom says that NTFS stores file system information in the registry. All of a sudden I am worried that if my primary drive fails, I won't be able to read the files on the secondary drive, even if I mount it in a working system, because the registry information wouldn't be right for the drive. That would be just like MS wouldn't it. Don't a lot of people use a second drive as a backup?
The IP argument for no Linux drivers seems a little odd. After all, they give away the binary drivers for windows, presumably in order to enhance the salability of the hardward. Of course, there are fewer Linux users, so you wouldn't expect every chip maker to produce a binary driver for Linux, but consider the position of some chipmaker whose market share is 5%. Adding Linux support would double his sales, (at least to start with.
Source code may be subject to other arguments, but it is truely odd that there are no binary drivers.
Why assume that sites with unprotected APs aren't unprotected precisely because they want to let visitors use them? We let our visitors use our 802.11b access points, and I have been at several sites that returned the favor. There isn't much risk if the AP is placed outside the firewall and port 25 is blocked.
I'd like to see a "community access" option in APs that would allow non-WEP access only to the Internet on the far side of the firewall, and would regulate total bandwidth consumed. That would let sites without an easy way to connect there APs outside the firewall to offer access to visitors. Visitors might like internal access to print, but we don't allow that. It is a good compromise.
I don't think much of argument by analogy, but our 802.11b infrastructure costs less than our drinking fountain, and we even let strangers use that.
This is pretty easy to do, but this person was lucky he used 100 gig drives. Lots of motherboard IDE controllers won't support more than 137 gigabytes/drive, and neither will older versions of Linux. RH starts supporting the larger drives in 7.3. I think any controller promising 133 mbits/second will also support the large drives. I posted some details at www.nber.org/sys-admin/maxtor-160.html because most of the discussion in mailing lists was questionable.
While it is likely that a spammer (not sure why you call them bulk mailers) will want to modify his software to drop slow connections, he often doesn't have control over the SMTP server he is using. It may belong to his ISP, or be an open relay. If the tarproxy is widespread, the open relay will be closed, and the ISP will drop the spammer as being to costly. If nothing else, this could close the last 10% of smtp servers that open relay.
Do ISPs have the tools they need to prevent outgoing SPAM from their own customers? I look at Sendmail and don't see anything that would allow you to throttle mail volume, check outbound messages for SPAM, restrict new customers etc. There isn't even anything built in that would warn you about a customer sending a million messages. It would seem that a few tools like that would be a big help to an ISP too small to develope its own.
It isn't that hard to determine if the header are forged or misconfigured, the problem is distinguishing the two cases. Lots of legitimate mail comes from misconfigured hosts. If there were a law forbidding forged headers, probably most of the legitimate ISPs would manage to fix their headers, and the rest of us could use mechanical filters to reject the rest.
It is important to distinguish between rejecting a message (in which case the sender gets a "550 spam" indication) and discarding a message (in which case neither the sender nor the receipient is notified). Only the SMTP server can reject a message, it is too late by the time it has gotten to the message user agent (client).
If the anti-spam software rejects a message it is usually trivial for the sender to modify the message or find another delivery method and little is lost. If a message is discarded, the damage might be much greater.
Bayesian spam filters usually run on the client, and have to discard messages but there is no particular reason they couldn't run on the server.
The client can't reasonably return a "DSN" via email since the envelope from (even if known to the client) is probably a forgery, so responding would just be creating more spam. The SMTP server can reject the message before it is accepted with an error code, it doesn't have to send an email with the error message.
Morse didn't invent the telegraph. He invented the Morse Code. Anyone who ever read a child's biography of Morse knows that. To claim anyone believed otherwise is the silliest form of revisionism ever. Of course if you go "Jaywalking" you can find people who believe anything, but to be a real "revisionist historian" you ought to revise a misunderstanding a bit more widespread than this.
Any use of this technology for security will be hampered by the fact that it apparently runs on the client - at least the web page lists requirements (Java, etc) for the client.
My own experience with 802.11b is that the inside range is so small - about 30 meters, that just knowing which access point was handling the traffic would be enough geographic information for most of the applications they list.
If you visit an alternative registrar and ask them to handle the transfer, they should be able to do so even if NSI is ignoring your mail. I know I transferred two domains to registrer.com by visiting www.register.com and filling out some forms. NSI will send you a confirmation request by email - follow the directions precisely or they will reject the transfer.
Slashdot Mirror
You are exactly right. For the search engine site, Google could avoid a lot of misunderstanding by auctions off "days" rather than "clicks". Advertisers could bid for a word or word combination, for a particular day or week. The advertiser could easily discover if his ad was running, and what the sales results were. Revenue for Google would be the same - the ads wouldn't be worth any more or less to be priced this way, but Google wouldn't be rewarding click fraud, and wouldn't have to worry about suppressing it. Trouble is, this auction won't tell Google how to divide up the money among the "ads by Google" sites. Still it solves part of the problem.
Actually the chance of losing two disks at once is pretty high. Here is the explanation from my posting at http://www.nber.org/sys-admin/linux-nas-raid.html
.02/365, or about one in a hundred thousand. The total probability of a double failure seems like it should be about 6 in a million per year.
.5% MORE than the 4% failure rate one would expect from a two drive RAID 0 with the same capacity. Alternatively, if you just had two drives with a partition on each and no RAID of any kind, the chance of a failure would still be 4%/year but only half the data loss per incident, which is considerably better than the RAID 5 can even hope for under the current reconstruction policy even with the most expensive hardware.
=====
Most of the drives in our NAS boxes and drive arrays claim a MTBF of 500,000 hours. That's about 2% per year. With three drives the chance of at least one failing is a little less than 6%. (1-(1-.98)^3). Our experience is that such numbers are at least a reasonable approximation of reality.
Suppose you have three drives in a RAID 5. If it takes 24 hours to replace and reconstruct a failed drive, one is tempted to calculate that the chance of a second drive failing before full redundancy is established is about
Our double failure rate is about 5 orders of magnitude worse than that - the majority of single drive failures are followed by a second drive failure before redundancy is established. This prevents rebuilding the array with a new drive replacing the original failed drive, however you can probably recover most files if you stay in degraded mode and copy the files to a different location. It isn't that failures are correlated because drives are from the same batch, or the controller is at fault, or the environment is bad (common electrical spike or heat problem). The fault lies with the Linux md driver, which stops rebuilding parity after a drive failure at the first point it encounters a uncorrectable read error on the remaining "good" drives. Of course with two drives unavailable, there isn't an unambiguous reconstruction of the bad sector, so it might be best to go to the backups instead of continuing. At least that is the apparently the reason for the decision.
Let's repeat the reliability calculation with our new knowledge of the situation. In our experience perhaps half of drives have at least one unreadable sector in the first year. Again assume a 6 percent chance of a single failure. The chance of at least one of the remaining two drives having a bad sector is 75% (1-(1-.5)^2). So the RAID 5 failure rate is about 4.5%/year, which is
A few years ago we had to put an ssh server on the telnet port, because one of our users was at the Federal Reserve Board, whose security committee hadn't approved outbound access to ssh servers on the usual port! In a telephone conversation with me, their security person suggested I turn on the telnet server at my end, and said that he had read about security issues with ssh that discouraged them from allowing it!
Lots (not all) IT security is just dumb rules of thumb with no analysis or understanding. Lots of IT staff don't think the other employees have work to do, and don't mind interfering with their efforts. As the years go by, management will become more experienced at understanding who is a blowhard and who knows what they are talking about. But it will take time.
When LinuxCare started, I called them about getting support from them. There were several plans, including just paying $350 "per incident". I thought about that for a while and concluded, that $350 was OK if they gave me a workaround or patched the software, but I was leary that they would take my money and tell me what I wanted wasn't supported. Almost any Linux problem can be closed as "not supported", since there is no real spec. (That applies double to windows). I didn't have any way of knowing what their attitude would be, so I let the matter drop. I wonder - does anyone know if they offered a worthwhile service to those who subscribed?
Daniel Feenberg
Video and sound card vendors need documentation from MS to write drivers. MS would ordinarily want big bucks for that, and the vendor wants to have something he can offer MS instead of money. So he keeps his interface a secret and offers that information in exchange. So MS and the vendor both sign non-disclosure agreements and exchange documents. It makes the vendor feel good to know he is involved in an equal exchange with MS, and not just a supplicant/customer. This benefits MS if it slows open source driver writers but I don't know how much effect there is. It might be small since Linux/*BSD machines are mostly servers, and don't have fancy video cards or sound cards. On the other hand, it may have helped keep Linux off the desktop and out of the home.
At the moment only the network card vendors lose anything from keeping the interface secret, and they don't lose much since the Linux kernel usualy ends up with decent drivers anyway, and if it doesn't most users can't tell the difference anyway.
Wouldn't it have made more sense for /. to wait a couple of hours before posting this? At least then there would the remote possibility that responses would be made after RTFA!
> you could never detect EOF's on pipes to fortran 77.
Well, I do it all the time:
read(5,*,end=99) a
branches to statement 99 on EOF, from a file or a pipe. This is exactly the standard, and works on
all Fortran 77 compilers I have encountered, including Unix f77 and f2c.
feenberg isat nber dotte org
Am I the only one who likes 5400rmp drives because he thinks they will last 72/54 times as long as 7200 rpm drives? We use large drives for backup, and since the access is all sequential, the high rotation speed isn't that important to us.
We like the 300 gig Maxtor Maxline II drives because they draw half the current of the 7200 rpm drives, and at 5400 rpm they should last at least 7200/5400 times as long. Of course with only 12 drives we can't really confirm that, but we have had no failures.
Death certificates are public documents - you can get them in machine readable form from the CDC. They should just scan the death certs for customers.
I thought the basis of SCOs claim was that IBM
had revealed trade secrets. In that case, SCO
has a strong obligation to take care that the secrets are not revealed, as would IBM. But once the secrets become public knowledge, they are freely available to anyone - SCOs only recourse is against IBM for damages. The fact that SCO published the secrets themselves would be a difficult problem for them to overcome if they sought to prevent a third party from using the material. Perhaps they could appeal to copyright law to protect the former secrets, but they would have to reveal just what they thought had been copied, even under DMCA.
The sum of the weights of a bike and the
chain necessary to keep it from being stolen
is a constant.
Try ww.nearlyfreespeech.net. They offer web hosting for $1/gigabyte downloaded. Then just put the problem file there and link your downloaders to it. The trouble with most billing methods is that they are generally non-linear, with a huge increase in the per byte cost once you exceed some contracted amount. Burstable billing is the worst - if someone comes along with a big pipe and downloads for 6% of the month, you can have a huge bill for a modest amount of bytes.
Tom says that NTFS stores file system information
in the registry. All of a sudden I am worried that
if my primary drive fails, I won't be able to read
the files on the secondary drive, even if I mount
it in a working system, because the registry information wouldn't be right for the drive. That would be just like MS wouldn't it. Don't a lot of people use a second drive as a backup?
The IP argument for no Linux drivers seems a little odd. After all, they give away the binary drivers for windows, presumably in order to enhance the salability of the hardward. Of course, there are fewer Linux users, so you wouldn't expect every chip maker to produce a binary driver for Linux, but consider the position of some chipmaker whose market share is 5%. Adding Linux support would double his sales, (at least to start with.
Source code may be subject to other arguments, but it is truely odd that there are no binary drivers.
Why assume that sites with unprotected APs aren't unprotected precisely because they want to let visitors use them? We let our visitors use our 802.11b access points, and I have been at several sites that returned the favor. There isn't much risk if the AP is placed outside the firewall and port 25 is blocked.
I'd like to see a "community access" option in APs that would allow non-WEP access only to the Internet on the far side of the firewall, and would regulate total bandwidth consumed. That would let sites without an easy way to connect there APs outside the firewall to offer access to visitors. Visitors might like internal access to print, but we don't allow that. It is a good compromise.
I don't think much of argument by analogy, but our 802.11b infrastructure costs less than our drinking fountain, and we even let strangers use that.
This is pretty easy to do, but this person was lucky he used 100 gig drives. Lots of motherboard IDE controllers won't support more than 137 gigabytes/drive, and neither will older versions of Linux. RH starts supporting the larger drives in 7.3. I think any controller promising 133 mbits/second will also support the large drives. I posted some details at www.nber.org/sys-admin/maxtor-160.html because most of the discussion in mailing lists was questionable.
While it is likely that a spammer (not sure why you call them bulk mailers) will want to modify his software to drop slow connections, he often doesn't have control over the SMTP server he is using. It may belong to his ISP, or be an open relay. If the tarproxy is widespread, the open relay will be closed, and the ISP will drop the spammer as being to costly. If nothing else, this could close the last 10% of smtp servers that open relay.
Do ISPs have the tools they need to prevent outgoing SPAM from their own customers? I look
at Sendmail and don't see anything that would allow you to throttle mail volume, check outbound messages for SPAM, restrict new customers etc. There isn't even anything built in that would warn you about a customer sending a million messages. It would seem that a few tools like that would be a big help to an ISP too small to develope its own.
It isn't that hard to determine if the header are forged or misconfigured, the problem is distinguishing the two cases. Lots of legitimate mail comes from misconfigured hosts. If there were a law forbidding forged headers, probably most of the legitimate ISPs would manage to fix their headers, and the rest of us could use mechanical filters to reject the rest.
It is important to distinguish between rejecting a message (in which case the sender gets a "550 spam" indication) and discarding a message (in which case neither the sender nor the receipient is notified). Only the SMTP server can reject a message, it is too late by the time it has gotten to the message user agent (client).
If the anti-spam software rejects a message it is usually trivial for the sender to modify the message or find another delivery method and little is lost. If a message is discarded, the damage might be much greater.
Bayesian spam filters usually run on the client, and have to discard messages but there is no particular reason they couldn't run on the server.
The client can't reasonably return a "DSN" via email since the envelope from (even if known to the client) is probably a forgery, so responding would just be creating more spam. The SMTP server
can reject the message before it is accepted with an error code, it doesn't have to send an email with the error message.
Morse didn't invent the telegraph. He invented the Morse Code. Anyone who ever read a child's biography of Morse knows that. To claim anyone believed otherwise is the silliest form of revisionism ever. Of course if you go "Jaywalking" you can find people who believe anything, but to be a real "revisionist historian" you ought to revise a misunderstanding a bit more widespread than this.
I like the message I got from VM 370 many years ago:
Illegal Error: Device returned illegal error code.
Translation is "You bought a third party compatible disk drive and it returned an error code to the OS that wasn't defined".
Any use of this technology for security will be hampered by the fact that it apparently runs on the client - at least the web page lists requirements (Java, etc) for the client.
My own experience with 802.11b is that the inside range is so small - about 30 meters, that just knowing which access point was handling the traffic would be enough geographic information for most of the applications they list.
If you visit an alternative registrar and ask them to handle the transfer, they should be able to do so even if NSI is ignoring your mail. I know I transferred two domains to registrer.com by visiting www.register.com and filling out some forms. NSI will send you a confirmation request by email - follow the directions precisely or they will reject the transfer.