Very little legitimate mail gets thrown out this way. Some does, but in all but one case, the admins were incompetent or non-existant. The one case where I spoke with a competent admin running an ISP which was not getting delegation from their upstream (*cough* *cough* *qwest* *cough*) indicated that they were indeed looking to switch to another upstream as soon as they got their portable ARIN space (in the works).
I see that your reverse is adsl-208-188-249-147.dsl.stlsmo.swbell.net which works forward and gets the correct address, so it should work fine to deliver to my mail servers.
Interesting perspective, annoying those who benefit. I'll certainly have to think about that. Probably it's very rare that those who benefit are not condoning it. Of course one risk is that if this practice were widespread, one way to hurt someone's business is to spam in their name.
I would put at least as much blame for this on BellSouth, if not more. Sure, Netcom was clueless, but it shouldn't have been their action to do any more than inform you that it was a DUL issue. Someone at BellSouth should be fired (because in this job market, they can be very easily replaced).
The items on smtpd_client_restrictions need to be separated on different lines or by commas. My cut and paste didn't work to get it formatted right and I forgot to change it to comma separated.
This is one of those fundamental problems. Unfortunately, for large scale servers, this is a genuine performance win to separate things like this. Still, if there was a way to list them then this could help.
I suggest listing the outbound mail servers in the MX entries at higher numbers anyway. They won't be used as long as the lower numbered servers are working. And if the server isn't even set up to work as a fall back when all the inbound servers go down at the same time, it can just give out connection refused during those troubling times, or black hole the SYN packets. But at least this way there is something there in the MX entries to validate the outbound servers.
Two things will reduce the hassle of spam, more legislation,
or supplanting SMTP with a non-broken mail protocol.
I don't think I can trust lawmakers to get it right. Slashdot has so many stories of past cases where lawmakers do goofy things that trample on rights not even related to what they were trying (or said they were trying) to do. I fear the risk of squelching the right to anonymous speech, especially anonymous mail, as a result of new laws. Even the anti-SPAM efforts outside of government has some risk of that. While I'm sure we might be able to come up with some well focused law to reduce spam, it won't be all that effective unless it is totally universal, and highly enforced. Those are things that generally don't get done by governments unless it can result in good press for politicians, and that's not likely to ever be in this case. Can you really trust the government THAT MUCH?
A replacement for SMTP, even if the protocol were final today, would probably not be deployed for 10 or even 20 years. SMTP would have to get cut off to force people to upgrade servers to something compliant with "SMTP2". The migration path would end up resulting in lots of "lost legitimate mail", at least for those cutting access from the original SMTP protocol. But if no one does that, then why would others have any incentive to upgrade?
Are you the admin of a server than has been using MAPS? If so, your server logs may have a list of many known open relays (but also many that have been subsequently closed). It's a start. You can build your own DNS zone like MAPS did to block at least these.
Now if people were to get together and merge their lists and share them, it could be the start of a brand new database.
I'd like to do a lot of the things you do. But I also have to balance what I do with how much time I have to deal with it. And it is not much. I'm trying to shift the cost back to those responsible (including those that make it harder for me to identify who is responsible... open relays fall into this category). Of course I want to prevent the lost of legitimate mail. But the loss of some of it is part of the cost. It's all a balancing act, and what I do today may not be what I do tomorrow. And maybe this whole/. thread will bring some new ideas to mind.
Getting more people involved in doing something besides wearing out the "d" key on their keyboards is certainly a great idea. I just don't agree with you regarding the blackholing... as long as the benefits outweigh the costs, which so far is the case for me.
A huge amount of mail is fraudulent and spam at the same time. Often times it is hard to track down who sent it. In one case I've gotten spam where the sender used a huge string of dots as the in-addr.arpa name (so he must have used a dedicated address with in-addr.arpa delegation) which caused the open relays to overflow the Recieved: header and not reveal the previous hop. In those cases the only recourse I have is to block the open relay.
Open relays are primarily the result of "inadequate administration" (my diplomatic term for what is usually incompetency somewhere). I don't want mail from there, plain and simple. They are not part of "my network" anymore. If they repent, I'll unblock them. If they do it again then the next time it's 30 days after they repent, and so on.
But what I choose to do is based on keeping my own costs (time) low. That's what it's all about. If it weren't, then I'd just sit there and read all the spam.
If the ISP is spam friendly... and there are some out there that fall into that category... then move on to a new ISP. When calling up ISPs, ask them what they actually do to prevent spam coming from their entire network. If their answer is not satisfactory, say so, and move on. Unless you live in the back country, you now have a choice, at least in US and EU.
MAPS has worked for me. I've had zero cases of legit (wanted) mail blocked by MAPS (doesn't mean it can't happen somewhere, but it sure doesn't seem to be all that big of a problem). I also use blocking by in-addr.arpa verification. No in-addr.arpa results then no acceptance of mail. This has been nearly as effective as MAPs (admins that don't get in-addr.arpa right tend to also be admins that don't get the servers closed to relaying). I've had 3 cases of this blocking legit mail. In 1 case the ISP fixed the problem. In another case they are now working on it after I phoned them yesterday. The 3rd case is so far unreachable, which indicates to me how much they really care.
The number of users might well be entirely unknown and out of the control of the ISP. A business customer may wish to not divulge this to the ISP for various reasons. Or they may even have their mail server configured without specific users. The user count pricing might work for most, but there are places where it fails. It is fundamentally a bad idea to price it that way. But that is just MHO.
If an ISP has a business as a customer, and that business hosts their own mail server, which because it's probably something insecure and inadequately administered (*cough* *cough* *exchange* *cough*), the ISP front ends all of the mail going in, then the ISP will be where the MAPS rejection will have to take place, but that server will have no idea if the next hop has 10, or 10 million, users. And this is very possible because user names can be ubiquitous to mail servers; they can be configured to accept everything that comes in and store it under the name actually addressed, or various other options. MAPS' pricing structure based on user count probably works for most, but there are cases where it falls on its face. Vixie should be smarter than that, but I suspect it is other individuals involved in their inflexible way of doing business.
Tell me what ISP you are using. I want it to be the first entry in a new service called isps-that-hire-clueless-techs-we-do-not-want-mail- from.org. Maybe we can start getting rid of bad ISPs this way.
In query mode, the cost is US$1,500 per year for sites with up to 1,000 users; each additional 500 users will be priced at US$750 per year.
That works out to not less than US$1.50 per user per year.
Part of the problem is that it is based on number of users. ISPs which are doing mail forwarding to end customer systems (generally businesses on DSL or T1 links, and often with some tight firewalls and tunnels) have no user base in the forwarding mail server. They simply cannot work from this kind of pricing structure since their service is volume and domain based, not user based.
I also have my mail server configured to reject mail from other mail servers that do not have their IP addresses correctly configured and/or delegated in the in-addr.arpa reversed DNS zone. Amazingly, this has cut out almost as much spam as MAPS has. For Postfix users, this can be done with:
While this does end up rejecting a few "legitimate" servers, the number is very small. I suspect that for the most part this works because open relays tend to be the result of "inadequate administration" which can also be the cause of the lack of reverse DNS. If they can't get one of them right, they probably can't get the other right.
What makes a good programmer a Prima Donna is he knows he's good.
What makes a bad programmer a Prima Donna is he thinks he's good.
The problem for management is figuring out which is which, keeping and nurturing the first case, and getting rid of the second case (or not allowing it to be there to begin with).
You're shopping at the wrong store. By going to the store that requires a card, you're encouraging that stupid behavior. I go to the stores that DO NOT use a card system. And I periodically call up the managers of the stores that do have them and ask them "Have you dumped that stupid card system yet?". You're letting THEM win.
1. Price - Food is a large part of most budgets, even for the folks Webvan targeted. Discounting is very much part of the grocery business, and Webvan didn't play that game. High margin items, such as soda, were cheaper at stores than on Webvan. The major chains have made shoppers very price sensitive, and Webvan was viewed at the upper end of the price range (whether they were or not is irrelevant), which meant people would use them in a pinch, but still went to the store for their major purchases.
I would be willing to pay a little more for home delivery, as long as it is reliably done when promised. Given the poor quality so many businesses under pressure from venture capitalists have gone to, I would worry that they would be able to keep it up. But making the margin so high that for my order to be way more than the cost of driving to the regular grocery store would have soon become a serious negative. If their costs for delivery and e-commerce were too much, they would have a problem. But they would have to be quality, too.
2. Order Size - Grocery shopping is really impulse buying - stores want to get you in with a few specials, to get you to walk through their store. They know you'll see other items you need, adding to the total sale per customer. Even if you go in with a list, you probably would find a few things you needed that you forgot. Webvan, because of its web-based model, wasn't really good at capturing the impulse buy that drives the total sale. Much of the buying is touch and feel - people like to see the meat, fruit, and vegetables and pick what they like. Yes, Webvan would refund the money, but that doesn't do you much good when your trying to make a salad and the vegetables aren't up to your standards (although I must say everything I got from Webvan was fine - but they still need to overcome the feeling that I must see it before I buy it).
Did they have a means for you to add on to your order if it was still N hours before delivery?
3. Advantage over stores - While it was great that Webvan delivered, they completely missed the "I need it now" market. That may have been smart, because cost of delivering a carton of eggs and some milk would be kill any profit on the order. (Webvan did add a delivery charge for small orders near the end) However, since I still had to run to the store to get one or two items, it was just as easy to make a list of other things I needed as well. This meant there was no compelling reason to use Webvan, since it really didn't cut down significantly on trips to the store.
That's likely a problem for them. Even if they could make a profit or break even or absorb the loss to keep you as a customer for later profits, on the small order with your list added on, the time to deliver from the one big warehouse would still be a negative. What would be needed is for it to be scaled up to enough customers to have distribution centers located closer to customers to make it a rapid delivery service. My grocery store is close because within 2-4 miles of there is enough market, even with 2 or 3 other stores around, to make their profit. The grocery business does require large consumer markets.
4. Convenience - Scheduling delivery was hard - next day service was rarely available, forcing people to plan 3-4 days in advance. It's just as easy to sneak in a trip to the store. In short, Webvan offered no clear advantages to going to the store that made buyers switch to them. Retail stores could even adopt parts of Webvan's model, making their position even weaker. In Atlanta, several stores even offered fax/online/phone ordering - they would take and pack the order for your pickup - one even offered drive through pickup.
That could certainly hurt them. Next day should have been a standard, with special premium emergency delivery for a fee.
Finally, Webvan failed to learn from history. Home delivery of groceries is nothing new \226 there are services that will stock your pantry on a regular schedule. Sometimes there is a reason why a business model hasn\222t been a roaring success \226 their aren\222t enough customers. Scaling up a business model that hasn\222t been successful in the past and wrapping the web around it doesn\222t change the fundamentals.
The web really could be an improvement to the model. Instead of calling on the phone and dealing with a person or a stupid answering machine, the web, if done right, could be better than that. You could see the products in pictures, which is better than not seeing it at all, though not as good as picking it up and making sure it's really what you want. But this particular kind of B2C model can't really replace regular grocery stores any time soon. Pizza and sub deliveries succeed because people are willing to pay the extra amount (and the place in Dallas I get pizza from is especially good) for quick delivery. If home grocery delivery might succeed, it might be the result of growing up from these businesses. But it may never be cheap, so we should not expect it to take over.
I'm a consultant - I convert gibberish into cash-flow.
Same here. Isn't it ironic that people that buy gibberish have so much of the cash to flow out?
Even at 5 cents a second, that would be how many computation units to use $415,000 worth of bandwidth? This is RC4, not SETI. SETI is more of a bandwidth hog (I know, I run 2 SETI processes at home connected via the same 28.8k I browse slashdot with). RC4 hardly uses any since all it needs to return is the work unit start, number of keys, the result, and any ID information. Then it gets a new work unit of about the same complexity and goes to work.
I could see how they can say the CPU time might cost that. But I sense they are twisting the facts to posture for some kind of bigger settlement or plea agreement. It could also just be gross incompetence on the part of the lawyer(s) there (and we know that never happens, right).
Bob: "Hello, this is Bob over in the State Attorney's office. Is this the state internet network accountant?"
Tom: "Yes it is. How can I help you?"
Bob: "I'm doing investigations on a case here, and I need to know how much the internet costs. Do you have this information?"
Tom: "Do you need the cost of a specific circuit?"
Bob: "I don't know what you mean by circuit. I'm only interested in the cost of the internet."
Tom: "Well, there are a lot of cost factors involved. For example there are costs for leases and depreciations for the routers and the servers. Then there are the circuit costs for the state network. And the costs for connecting into the actual internet itself, like our OC-192 core connections."
Bob: "So are these connections what makes the internet work?"
Tom: "Yes, they are. Is that what you are interested in?"
Bob: "I think so. What are we paying for that?"
Tom: "Do you need the exact amount? I'd have to get all the paperwork together and figure it up and get back to you tomorrow."
Bob: "Just an estimate for now. A ballpark figure is good enough. We'll ask for copies of the paperwork when we're ready to go to court on this."
Tom: "OK, well last month we budgeted somewhere around 1.53 million dollars for the internet connections."
Bob: "Great! Thanks! That's exactly what I need to know."
Maybe if the URL is put inside an href tag like this it will be OK. Then you can right click on the link, use "Copy Link to Clipboard" or whatever, and paste it into wherever you're going to download from.
Imagine the millions of DM German lawyers could make by sending those threatening letter "services" as one did recently about an alleged trademark issue, but instead threatening about insufficient licenses for Microsoft products.
Teaching people to do things only with a particular product is, IMHO, bad teaching and a bad education. To the extent that what is taught cannot be applied to any other package for all student skill levels, this is reinforcing corporate monopolies. Publicly funded educational institutions should never do such things. And this would go for all uses of computers, their look and feel, and the productivity tools found on them. Private schools can do what they want but public schools have no business sanctioning particular products.
Maybe Slashdot could start caching the sites they are going to link to beforehand, and then change the links to the cache if there's a problem. It could also be useful in case some site changes their content because of Slashdot referencing them and trying to refute the previous content.
The ratio between languages of those language's propensity to have flaws in programs is not going to be a constant. The ratio will rise with bad programmers and approach 1 with good programmers. Giving the language the chore of accomplishing program correctness indicates a lack of good programmers (as defined above).
Of course I want absolute correctness in air traffic control systems and medical instrumentation systems. So the work in making sure programs are correct is certainly important, and I wouldn't want work to make a better language in this regard to stop. But what about also working to achieve better programmers?
The quality level of programmers coming out of colleges is going down. I'm sure that is significantly due to the larger numbers entering the field. But this also means a college degree is essentially worthless in determining the quality of the programmer. Given that experience is also a factor, that pretty much means something else needs to be done to determine who is, and who is not, the quality programmer.
I propose this solution. In addition to having a language that ensures provable correctness, let's also have a language that has none of those features at all. Force everyone to program in that language first for a few years and use it to weed out the bad programmers. Once we have selected the best and brightest programmers based on not only their education, but also the results of real world programming effort produced from experience, then we have them work in the provably correct languages. Now we'll have the best programmers combined with the best language. This should ensure the best results.
Personally, I'd rather have a good programmer writing in a bad language than a bad programmer writing in a good language. I write in C (considered a bad language in this context) and before that in assembly (probably considered very bad). Of course I'm not perfect and frequently there are bugs in the code I write. But these bugs are typically the result of things like not keeping track of how I change things around (I discover I need 2 variables instead of 1 for something, and forgot to change some of the references to the new one), or misunderstanding the interfaces (there are such things as bugs in documentation and man pages, as well as just unclear and ambiguous writing). But I have gotten better on those things over the years. Experience helps you realize you need to develop correct models for what you are doing ahead of time, be more careful about changes, and be sure the understanding of the interfaces is precise and accurate with no shadow of a doubt.
How can a "correct" language ensure that a programmer does not use the wrong variable? What if I transpose the rows and columns of the output matrix because I exchanged the variables that index where each result is stored in a square matrix? Writing wrong programs correctly is certainly very possible. In real world systems, what's going to happen isn't so much a programmer getting out of the bounds of an array (something a good programmer won't do even in assembly, and something any programmer won't do in a correct language) as it is the programmer simply not understanding what is really going on in the system they are coding for. What if a programmer mistakenly assumes the data is coming in in metric units when really it is coming in in old English units, and he simply doesn't code in the conversion somewhere. We could lose a space probe... or we could lose an airplane full of people. Think it isn't happening? Systems are often designed to compensate for errors in data measurement all the time, and once deployed may well be functional even without the english->metric conversion in place. But the functional tolerances will now be shifted and performance specifications will be other than intended or documented.
A bad language can still have good code written if the programmer is good. But a bad programmer is a disaster waiting to happen in any language. And if you think the language is going to protect against that, consider that since a correct language does indeed do that protection to an extent, that it now opens the door for even lamer programmers to start doing coding. Eventually, you hit the bottom again and you have someone who is such an idiot, that no language in the world can prevent them from screwing up.
Slashdot Mirror
Very little legitimate mail gets thrown out this way. Some does, but in all but one case, the admins were incompetent or non-existant. The one case where I spoke with a competent admin running an ISP which was not getting delegation from their upstream (*cough* *cough* *qwest* *cough*) indicated that they were indeed looking to switch to another upstream as soon as they got their portable ARIN space (in the works).
I see that your reverse is adsl-208-188-249-147.dsl.stlsmo.swbell.net which works forward and gets the correct address, so it should work fine to deliver to my mail servers.
Interesting perspective, annoying those who benefit. I'll certainly have to think about that. Probably it's very rare that those who benefit are not condoning it. Of course one risk is that if this practice were widespread, one way to hurt someone's business is to spam in their name.
I would put at least as much blame for this on BellSouth, if not more. Sure, Netcom was clueless, but it shouldn't have been their action to do any more than inform you that it was a DUL issue. Someone at BellSouth should be fired (because in this job market, they can be very easily replaced).
The items on smtpd_client_restrictions need to be separated on different lines or by commas. My cut and paste didn't work to get it formatted right and I forgot to change it to comma separated.
This is one of those fundamental problems. Unfortunately, for large scale servers, this is a genuine performance win to separate things like this. Still, if there was a way to list them then this could help.
I suggest listing the outbound mail servers in the MX entries at higher numbers anyway. They won't be used as long as the lower numbered servers are working. And if the server isn't even set up to work as a fall back when all the inbound servers go down at the same time, it can just give out connection refused during those troubling times, or black hole the SYN packets. But at least this way there is something there in the MX entries to validate the outbound servers.
I don't think I can trust lawmakers to get it right. Slashdot has so many stories of past cases where lawmakers do goofy things that trample on rights not even related to what they were trying (or said they were trying) to do. I fear the risk of squelching the right to anonymous speech, especially anonymous mail, as a result of new laws. Even the anti-SPAM efforts outside of government has some risk of that. While I'm sure we might be able to come up with some well focused law to reduce spam, it won't be all that effective unless it is totally universal, and highly enforced. Those are things that generally don't get done by governments unless it can result in good press for politicians, and that's not likely to ever be in this case. Can you really trust the government THAT MUCH?
A replacement for SMTP, even if the protocol were final today, would probably not be deployed for 10 or even 20 years. SMTP would have to get cut off to force people to upgrade servers to something compliant with "SMTP2". The migration path would end up resulting in lots of "lost legitimate mail", at least for those cutting access from the original SMTP protocol. But if no one does that, then why would others have any incentive to upgrade?
Are you the admin of a server than has been using MAPS? If so, your server logs may have a list of many known open relays (but also many that have been subsequently closed). It's a start. You can build your own DNS zone like MAPS did to block at least these.
Now if people were to get together and merge their lists and share them, it could be the start of a brand new database.
I'd like to do a lot of the things you do. But I also have to balance what I do with how much time I have to deal with it. And it is not much. I'm trying to shift the cost back to those responsible (including those that make it harder for me to identify who is responsible ... open relays fall into this category). Of course I want to prevent the lost of legitimate mail. But the loss of some of it is part of the cost. It's all a balancing act, and what I do today may not be what I do tomorrow. And maybe this whole /. thread will bring some new ideas to mind.
Getting more people involved in doing something besides wearing out the "d" key on their keyboards is certainly a great idea. I just don't agree with you regarding the blackholing ... as long as the benefits outweigh the costs, which so far is the case for me.
A huge amount of mail is fraudulent and spam at the same time. Often times it is hard to track down who sent it. In one case I've gotten spam where the sender used a huge string of dots as the in-addr.arpa name (so he must have used a dedicated address with in-addr.arpa delegation) which caused the open relays to overflow the Recieved: header and not reveal the previous hop. In those cases the only recourse I have is to block the open relay.
Open relays are primarily the result of "inadequate administration" (my diplomatic term for what is usually incompetency somewhere). I don't want mail from there, plain and simple. They are not part of "my network" anymore. If they repent, I'll unblock them. If they do it again then the next time it's 30 days after they repent, and so on.
But what I choose to do is based on keeping my own costs (time) low. That's what it's all about. If it weren't, then I'd just sit there and read all the spam.
If the ISP is spam friendly ... and there are some out there that fall into that category ... then move on to a new ISP. When calling up ISPs, ask them what they actually do to prevent spam coming from their entire network. If their answer is not satisfactory, say so, and move on. Unless you live in the back country, you now have a choice, at least in US and EU.
MAPS has worked for me. I've had zero cases of legit (wanted) mail blocked by MAPS (doesn't mean it can't happen somewhere, but it sure doesn't seem to be all that big of a problem). I also use blocking by in-addr.arpa verification. No in-addr.arpa results then no acceptance of mail. This has been nearly as effective as MAPs (admins that don't get in-addr.arpa right tend to also be admins that don't get the servers closed to relaying). I've had 3 cases of this blocking legit mail. In 1 case the ISP fixed the problem. In another case they are now working on it after I phoned them yesterday. The 3rd case is so far unreachable, which indicates to me how much they really care.
The number of users might well be entirely unknown and out of the control of the ISP. A business customer may wish to not divulge this to the ISP for various reasons. Or they may even have their mail server configured without specific users. The user count pricing might work for most, but there are places where it fails. It is fundamentally a bad idea to price it that way. But that is just MHO.
If an ISP has a business as a customer, and that business hosts their own mail server, which because it's probably something insecure and inadequately administered (*cough* *cough* *exchange* *cough*), the ISP front ends all of the mail going in, then the ISP will be where the MAPS rejection will have to take place, but that server will have no idea if the next hop has 10, or 10 million, users. And this is very possible because user names can be ubiquitous to mail servers; they can be configured to accept everything that comes in and store it under the name actually addressed, or various other options. MAPS' pricing structure based on user count probably works for most, but there are cases where it falls on its face. Vixie should be smarter than that, but I suspect it is other individuals involved in their inflexible way of doing business.
Tell me what ISP you are using. I want it to be the first entry in a new service called isps-that-hire-clueless-techs-we-do-not-want-mail- from.org. Maybe we can start getting rid of bad ISPs this way.
:-)
According to http://mail-abuse.org/rbl+/:
That works out to not less than US$1.50 per user per year.
Part of the problem is that it is based on number of users. ISPs which are doing mail forwarding to end customer systems (generally businesses on DSL or T1 links, and often with some tight firewalls and tunnels) have no user base in the forwarding mail server. They simply cannot work from this kind of pricing structure since their service is volume and domain based, not user based.
Here are some up and coming alternatives:
I also have my mail server configured to reject mail from other mail servers that do not have their IP addresses correctly configured and/or delegated in the in-addr.arpa reversed DNS zone. Amazingly, this has cut out almost as much spam as MAPS has. For Postfix users, this can be done with:
While this does end up rejecting a few "legitimate" servers, the number is very small. I suspect that for the most part this works because open relays tend to be the result of "inadequate administration" which can also be the cause of the lack of reverse DNS. If they can't get one of them right, they probably can't get the other right.What makes a good programmer a Prima Donna is he knows he's good.
What makes a bad programmer a Prima Donna is he thinks he's good.
The problem for management is figuring out which is which, keeping and nurturing the first case, and getting rid of the second case (or not allowing it to be there to begin with).
You're shopping at the wrong store. By going to the store that requires a card, you're encouraging that stupid behavior. I go to the stores that DO NOT use a card system. And I periodically call up the managers of the stores that do have them and ask them "Have you dumped that stupid card system yet?". You're letting THEM win.
I would be willing to pay a little more for home delivery, as long as it is reliably done when promised. Given the poor quality so many businesses under pressure from venture capitalists have gone to, I would worry that they would be able to keep it up. But making the margin so high that for my order to be way more than the cost of driving to the regular grocery store would have soon become a serious negative. If their costs for delivery and e-commerce were too much, they would have a problem. But they would have to be quality, too.
Did they have a means for you to add on to your order if it was still N hours before delivery?
That's likely a problem for them. Even if they could make a profit or break even or absorb the loss to keep you as a customer for later profits, on the small order with your list added on, the time to deliver from the one big warehouse would still be a negative. What would be needed is for it to be scaled up to enough customers to have distribution centers located closer to customers to make it a rapid delivery service. My grocery store is close because within 2-4 miles of there is enough market, even with 2 or 3 other stores around, to make their profit. The grocery business does require large consumer markets.
That could certainly hurt them. Next day should have been a standard, with special premium emergency delivery for a fee.
The web really could be an improvement to the model. Instead of calling on the phone and dealing with a person or a stupid answering machine, the web, if done right, could be better than that. You could see the products in pictures, which is better than not seeing it at all, though not as good as picking it up and making sure it's really what you want. But this particular kind of B2C model can't really replace regular grocery stores any time soon. Pizza and sub deliveries succeed because people are willing to pay the extra amount (and the place in Dallas I get pizza from is especially good) for quick delivery. If home grocery delivery might succeed, it might be the result of growing up from these businesses. But it may never be cheap, so we should not expect it to take over.
Same here. Isn't it ironic that people that buy gibberish have so much of the cash to flow out?
Even at 5 cents a second, that would be how many computation units to use $415,000 worth of bandwidth? This is RC4, not SETI. SETI is more of a bandwidth hog (I know, I run 2 SETI processes at home connected via the same 28.8k I browse slashdot with). RC4 hardly uses any since all it needs to return is the work unit start, number of keys, the result, and any ID information. Then it gets a new work unit of about the same complexity and goes to work.
I could see how they can say the CPU time might cost that. But I sense they are twisting the facts to posture for some kind of bigger settlement or plea agreement. It could also just be gross incompetence on the part of the lawyer(s) there (and we know that never happens, right).
Bob: "Hello, this is Bob over in the State Attorney's office. Is this the state internet network accountant?"
Tom: "Yes it is. How can I help you?"
Bob: "I'm doing investigations on a case here, and I need to know how much the internet costs. Do you have this information?"
Tom: "Do you need the cost of a specific circuit?"
Bob: "I don't know what you mean by circuit. I'm only interested in the cost of the internet."
Tom: "Well, there are a lot of cost factors involved. For example there are costs for leases and depreciations for the routers and the servers. Then there are the circuit costs for the state network. And the costs for connecting into the actual internet itself, like our OC-192 core connections."
Bob: "So are these connections what makes the internet work?"
Tom: "Yes, they are. Is that what you are interested in?"
Bob: "I think so. What are we paying for that?"
Tom: "Do you need the exact amount? I'd have to get all the paperwork together and figure it up and get back to you tomorrow."
Bob: "Just an estimate for now. A ballpark figure is good enough. We'll ask for copies of the paperwork when we're ready to go to court on this."
Tom: "OK, well last month we budgeted somewhere around 1.53 million dollars for the internet connections."
Bob: "Great! Thanks! That's exactly what I need to know."
Maybe if the URL is put inside an href tag like this it will be OK. Then you can right click on the link, use "Copy Link to Clipboard" or whatever, and paste it into wherever you're going to download from.
Why is everyone putting an extra space in their URLs?
Imagine the millions of DM German lawyers could make by sending those threatening letter "services" as one did recently about an alleged trademark issue, but instead threatening about insufficient licenses for Microsoft products.
Teaching people to do things only with a particular product is, IMHO, bad teaching and a bad education. To the extent that what is taught cannot be applied to any other package for all student skill levels, this is reinforcing corporate monopolies. Publicly funded educational institutions should never do such things. And this would go for all uses of computers, their look and feel, and the productivity tools found on them. Private schools can do what they want but public schools have no business sanctioning particular products.
Maybe Slashdot could start caching the sites they are going to link to beforehand, and then change the links to the cache if there's a problem. It could also be useful in case some site changes their content because of Slashdot referencing them and trying to refute the previous content.
The ratio between languages of those language's propensity to have flaws in programs is not going to be a constant. The ratio will rise with bad programmers and approach 1 with good programmers. Giving the language the chore of accomplishing program correctness indicates a lack of good programmers (as defined above).
Of course I want absolute correctness in air traffic control systems and medical instrumentation systems. So the work in making sure programs are correct is certainly important, and I wouldn't want work to make a better language in this regard to stop. But what about also working to achieve better programmers?
The quality level of programmers coming out of colleges is going down. I'm sure that is significantly due to the larger numbers entering the field. But this also means a college degree is essentially worthless in determining the quality of the programmer. Given that experience is also a factor, that pretty much means something else needs to be done to determine who is, and who is not, the quality programmer.
I propose this solution. In addition to having a language that ensures provable correctness, let's also have a language that has none of those features at all. Force everyone to program in that language first for a few years and use it to weed out the bad programmers. Once we have selected the best and brightest programmers based on not only their education, but also the results of real world programming effort produced from experience, then we have them work in the provably correct languages. Now we'll have the best programmers combined with the best language. This should ensure the best results.
Personally, I'd rather have a good programmer writing in a bad language than a bad programmer writing in a good language. I write in C (considered a bad language in this context) and before that in assembly (probably considered very bad). Of course I'm not perfect and frequently there are bugs in the code I write. But these bugs are typically the result of things like not keeping track of how I change things around (I discover I need 2 variables instead of 1 for something, and forgot to change some of the references to the new one), or misunderstanding the interfaces (there are such things as bugs in documentation and man pages, as well as just unclear and ambiguous writing). But I have gotten better on those things over the years. Experience helps you realize you need to develop correct models for what you are doing ahead of time, be more careful about changes, and be sure the understanding of the interfaces is precise and accurate with no shadow of a doubt.
How can a "correct" language ensure that a programmer does not use the wrong variable? What if I transpose the rows and columns of the output matrix because I exchanged the variables that index where each result is stored in a square matrix? Writing wrong programs correctly is certainly very possible. In real world systems, what's going to happen isn't so much a programmer getting out of the bounds of an array (something a good programmer won't do even in assembly, and something any programmer won't do in a correct language) as it is the programmer simply not understanding what is really going on in the system they are coding for. What if a programmer mistakenly assumes the data is coming in in metric units when really it is coming in in old English units, and he simply doesn't code in the conversion somewhere. We could lose a space probe ... or we could lose an airplane full of people. Think it isn't happening? Systems are often designed to compensate for errors in data measurement all the time, and once deployed may well be functional even without the english->metric conversion in place. But the functional tolerances will now be shifted and performance specifications will be other than intended or documented.
A bad language can still have good code written if the programmer is good. But a bad programmer is a disaster waiting to happen in any language. And if you think the language is going to protect against that, consider that since a correct language does indeed do that protection to an extent, that it now opens the door for even lamer programmers to start doing coding. Eventually, you hit the bottom again and you have someone who is such an idiot, that no language in the world can prevent them from screwing up.