Re:Optionally publish valid mail servers for domai
on
Spam Slows AT&T Email
·
· Score: 2
Just use authentication for them. Surely, it wouldn't be any harder than keeping user accounts on the intranet servers up to date. It could even use the same authentication database.
What accounts? What authentication database? Presently, the existence of a mailing address does not imply the existence of a user account. Consider forwarding-only addresses. Should all the volunteers behind bugs@opensourceproject.example.org require accounts? Maybe the sysadmin is a volunteer, too.
What about those of us who use webmail addresses as spam traps? Now we have to use crappy web interfaces to send (or those webmail companies have to set up SMTP AUTH, with which they very well may not want to bother).
The downside of it is that if you have a yahoo.com address, but want to run your own smtp server to deliver your mails, then you'd fall foul of such a system. I don't think that's a biggy though - if you could run your own smtp server, you'd probably not use a yahoo.com address you'd have your own domain:).
Actually, this is a pretty big downside for many users. Every once in a while, someone proposes a similar scheme that makes it hard or impossible to "forge" From addresses. This is not exactly that, but it's close enough. The problem is that this is a perfectly legitimate and necessary use of email, and is, in fact, discussed in RFC 822.
The basic problem is that many of us wear quite a few different hats, each of which has one or more email addresses. Suppose I want to send an email using my personal address while I'm at work, or my work address while I'm at home. Suppose I need to reply to some email sent to an official address using that official address as the header From, and that I also want bounces to go to that address so that others at that address can see if my reply was not sufficient (requiring a change in the envelope From). Maybe I do run my own smtp server and domain, but I want to use my spam-trapping yahoo address to reply to yahoo mail (for privacy reasons), and I want to use mutt instead of some stupid web interface. Maybe I'm a sysadmin who wants to set up a number of forwarding addresses (perhaps official addresses for some project on some domain). Now my one-way service has to be a two-way service; instead of just editing the aliases file, I have to set up an account for each of the people who needs to send mail. These are just some of the things that I happen to do on a daily basis and that adoption of your system might make impossible or more of a pain.
Sure, a lot of times this can be solved by some sort of remote access or SMTP auth, but it would certainly be less convenient (especially because some sites are difficult to access remotely). The bigger problems are social: many of the users I know who do these sorts of things aren't the most technically-savvy; many domains are unlikely to introduce the features necessary for full remote access (so then it becomes less of an inconvenience and more of a loss of service).
The good thing about your proposal is that it's opt-in for the sender's domain (whereas most others are opt-in for the recipient's domain), and it therefore gives a domain more control over its email addresses (as opposed to less with other schemes). It allows example.com to say "we want mail from addresses in our domain sent out via only our servers." Presently, anti-relaying provisions in servers make it possible to say "we want only mail from addresses in our domain sent out via our servers." This just completes things.
I guess it depends on your perspective. As a sysadmin, I'd be happy to have the power to turn this on for my domain (though I probably wouldn't, and other domains might not use it -- look at how terrible people are with MX records). As a user, I'd be unhappy if one of my sysadmins turned it on, but happy if some of the domains spammers use and I don't use turned it on. I guess it might be sort of a "not in my backyard" issue, which might limit its adoption. Another problem might be sysadmins that block domains which don't have these records, thus taking the power away from the sender's domain again.
While I'm rambling While I'm ramblingly replying:
When an email comes in, you check if there's a verification server for the source domain of the email, and if so try connect to it, and then submit the email address for verification. [...] I know SMTP vrfy exists, but sites often turn it off
They turn it off because it can be abused by spammers looking for valid addresses or is in some other way a privacy concern. What you propose is functionally equivalent to VRFY (except that it can run on a different server), so I doubt it would be turned on either. However, it might not be a bad thing for servers to *try* to VRFY an address, and only block if VRFY returns "no such user" (not "permission denied"). If a separate protocol and server is desirable, there is always good old finger (though it's maybe a little too free-form), but VRFY makes more sense, as the primary mail servers should know to whom they can deliver mail.
The heart of your scheme is to make it really expensive to send thousands of mails per day. What about those of us who run sites that send tens or hundreds of thousands of legitimate emails per day on behalf of tens or hundreds of thousands of users?
Our four old single-CPU mail servers handle half a million legititmate messages per day with very little load (there are four for crazy levels of redundancy). Most of what they do is to just shuffle data around or do DNS lookups. Now you're asking them to do computationally-intesive tasks that take 5 seconds per message, so to handle the load averaged over a day, I'd now need 29 mail servers running at full CPU utilization all day [(500000 mails/day) * (5 CPU*secs/mail) / (86400 secs/day) =~ 29 CPU]. However, the load is not even over the course of the day; at peak times (mid-afternoon) the rate is easily more than five times the average. To handle peak loads of exactly five times the average, I'd need 145 servers working full-blast.
Even so, I still wouldn't have the comfortable margin I have now. For that, I'd need even more servers. Even if I could justify the outlay for the machines, I'd have to get a new machine room to house them and supply the power, UPS, and A/C. Then I'd have to set up all those machines, keep them patched, and so on. To say that would be highly unlikely for such a plan to be approved would be an understatement. Sure, spam sucks and costs legitimate people money, but is stopping it worth increasing by nearly two orders of magnitude the costs associated with running legitimate mail servers?
Granted, those esitmates are not accurate because not every mail would require CPU-intensive verification, but some of them would, possibly a good portion of them if your proposal were widely accepted. The worst part is I would entirely dependent on some remote sysadmin putting my servers on his list of "trusted" servers. Do you realize with how many other sites and unique email addresses we exchange mail? Don't sysadmins have enough to do without spending their time maintaining such a list? Even in the highly-unlikely best case, where the system operates perfectly, every mail we send out is magically a hit on the remote site's list, and entries are added to the list on our site automagically, you're still talking a *huge* and growing database, and that's going to cost something (computer time doing the lookups, sysadmin time maintaining the database). In the real world, however, it would porbably be worse.
Bottom line: this may work fine on your little pentium Linux box at home running a vanity domain, but it'll go over like a lead balloon with sysadmins in the big leagues and the people who control their purse-strings. You'll have to prove to them that the absolutely certain benefits outweigh the remotely possible costs, and that implementing such a system won't disrupt or slow mail delivery in any way. Good luck on that.
I'm not saying that I couldn't be convinced that such a scheme would be a good idea, but I remain extremely skeptical. The answer to this proposal seems to be that given to so many proposals: "DOES NOT SCALE". I really need to get a rubber stamp that says that. What makes this proposal actually irksome is that the lack of scalability is deliberate.
With a typed ASCII password you've got 2^128*n password combinations (where n is the number of symbols in your password), with an iconic password you've only got y^n password combinations (where y in the total number of icons which is limited to how many can be displayed on the screen at once).
I think you are confused. The number of combinations of N characters in a character set of size Y is y^n, not 2^y*n (if order is significant and repetition is allowed, both of which are usually the case for passwords). ASCII does not have 2^128 characters; it has 128 (0x00 through 0x7F), but that's not necessarily equivalent to what one can type on a keyboard. If one could type all of them and only all of them on the keyboard, that would allow 128^n passwords of length n.
In any case, even with a relatively modest 80x25 grid (much like a standard DOS or Linux console screen), one can fit 80 * 25 = 2000 symbols on the screen, giving 2000^n possible combinations, provided one can come up with 2000 easily distinguishable symbols (well, the Chinese have done it) and display them in a resolution at which they could be distinguished.
If one just wanted to display 128 characters, one could use an 8 x 16 grid. That is hardly a challenge. Then the user can select whatever ASCII characters he/she wants to select in whatever order he/she wants to select them, again yielding 128^n possible passwords of length n.
What do you pay your ISP for? To intercept your packets. Because otherwise, they're not getting anywhere.
Don't be silly. There is a clear distinction between reading the IP headers of a packet to make a routing decision and recording the application-layer data within the packet. I pay my ISP for the former.
The person at the other end of your phone call is also allowed to tap the phone line with their telephone and listen.
Of course they are. The communication is intended for them. It's not a tap -- it's called answering the phone. No judge would be foolish enough to believe that it was a tap. You seem to be attempting to discard all common sense and rely on semantic games to make your argument. It won't fly in court.
Wiretapping laws come into play only when the person listening is not the person whose wire it is
That is patently false. Read the laws.
Otherwise it would be illegal for the phone system to route your calls to the person you're calling.
No it wouldn't. Sheesh. Lawmakers and judges are not idiots. They are quite capable of seeing the distinction between IP headers and the data inside the packet, between the digits pressed before a phone call and the conversation during the call itself.
IP headers and phone numbers are data that is explicitly meant for the uses of the network equipment. They in no way constitute private communications. However, that fact does not make the rest of the packet or phone call any less private. To argue that it does is a fallacy of composition.
Unencrypted data is like postcards with respect to expectations of privacy: it doesn't have the digital equivalent of an envelope, and the address information is not separated from the content in any meaningful way.
There is no "envelope" around a phone call, either. In fact, since the time it takes to dial a number is variable and there is no terminator to the dialing sequence, it's even worse. At least IP headers are defined fairly strictly in RFC 791.
You can therefore not expect privacy of the data from anyone who is responsible for routing.
I most certainly can. Routing packets by reading the IP headers which I put on them for the routers' benefit is one thing. Setting up a box to read through the data in the packet is quite another.
The fact that routers only look at the IP headers by default and that you'd have to install special equipment and/or software to record the application-layer data is a pretty strong indication that the distinction between the IP header and the data is meaningful.
It's worth noting that laws apply to people (and corporations), not machines. It's not illegal for a router or the phone system to do anything. It's when the ISP installs some equipment to monitor private communications (for purposes other than those explicitly allowed) or when someone looks at/listens to those communications or discloses their contents to someone else that the law applies.
Finally, let me reiterate: whether the communications are encrypted or not is irrelevant for the purposes of the law. Read it.
No, it's not; it's like unencrypted data. It bears absolutely no resemblance to a 4 x 6 inch piece of cardboard.
IANAL, but it seems to me that it's an electronic communication, and that's what US Code Title 18 Part I, Chapter 119, Section 2511 is all about: "Interception and disclosure of wire, oral, or electronic communications prohibited"
Perhaps if you printed your HTTP requests on index cards and mailed them to the web server, the requests would be covered by postal code. But for most people, HTTP requests are electronic communications.
I could tell you that "the unencrypted data, she is like a fine wine," but that would not make it subject to state liquor taxes.
IANAL, but I'd say you have just about as much expectation of privacy as you do sending unencrypted voice over the public telephone network, which is to say a substantial expectation.
Data on a switched network between two large ISPs is no easier to intercept than voice going between two large phone companies. In fact, I daresay it would be easier for me to tap my neighbor's phone than his cable modem (I could do it with a pair of pliers and some wire); it would, however, be illegal and IMO wrong for me to do so.
Bottom line: even though it may be *possible* for nefarious people to tap your phone, put bugs in your living room, or even implant a chip in your brain, you can still have an expectation of privacy. Not wrapping your house in tinfoil does not mean you're giving up your right to privacy, because your home is not a public forum. The wires between you and a web server do not constitute a public forum by any stretch of the imagination (even if the server happens to be hosting a public forum). Not using HTTPS does not consitute an abdication of privacy.
If you run a packet sniffer and look at other people's data, good luck convincing a judge that you weren't doing something bad under Section 2511 because the data wasn't encrypted.
"Hey, his front door wasn't locked, so I didn't really steal his TV..."
"Hey, the guy didn't use The Club, so this really isn't Grand Theft Auto..."
"Hey, she was wearing that short skirt; she deserved it..."
OK, so apparently I need to take some or most of that back because the phone companies have been busy installing twisted-pair for some time (and adding more twists per foot).
On the other hand, I looked in the basement and the feed into my old building (where it connects on an old wiring block to rubber-insulated wires) is definitely not twisted (or not twisted much), which explains all those voices on the line. Maybe it connects to twisted-pair outside, though.
Maybe someone who actually works in the industry (and is not an armchair idiot like me) can set the record straight (or twisted) before I dig myself into too deep a hole.
Normal phone lines aren't usually twisted. The word "twisted" does not appear in the original article. Who knows from where timothy got the idea that the lines were "twisted"?
This is not some trifling detail -- there is a *big* difference between twisted and straight pairs at the distances phone lines typically cover. If this tech requires pulling new twisted-pair copper, then it's not very useful.
[I'm no planetary scientist, so you'll have to forgive any inaccuracies, and maybe someone who knows a little more will correct me.] One possible reason for the importance of the Moon (if one believes it originated in an impact) is that it may contain a great deal of light outer-crust rock that would normally be on Earth.
Earth has these little continents that leave the thin tectonic plates (made of denser rock and covered with vast oceans) free to move around. Imagine how different Earth would be if all the rock that currently orbits us were instead filling the ocean basins and keeping the plates from moving around.
A few back-of-the-envelope (containing some stupid coupon from AT&T Broadband) calculations gives about 2x10^19 m^3 for the volume of the Moon, 5 x 10^14 m^2 for the surface area of the Earth, so, spreading the moon out evenly (and neglecting curvature), a layer 4 x 10^4 m thick. Granted, it might not all be silicate, but it's a lot of rock, especially considering that the average depth of the oceans is around 4 x 10^3 m, and the plates under the oceans are around 5 x 10^3 m thick (results of random web searches).
Something to think about the next time you look up at the Moon.
But here the carnage on the screens has moved into the real world
[...]
The beginning of the article seems to be trying to imply some link between violent video games and real-world violence, but the statements of experts in the article don't seem to support that idea.
Detective Peter Vi, who specializes in investigating gangs, said most problems with youths in the area began in the schools. "It'll start with a personal problem, and then someone will break someone else's window and he'll call in a friend who's a gang member," Detective Vi said. "Then it'll become a beating, and it'll evolve to gang on gang."
[...]
"The gangs go look in these places because they know, hopefully, that their enemy is going to be there," Detective Vi said.
It looks like the violence has moved from the schools, not from the computer screens, to the parking lots outside the cafes (or, presumably, anywhere else the kids might gather).
It seems to me that the mayor and others involved are imposing these restrictions because they were just recently exposed to the fact that the kids were ditching school, not because of some presumed causal link between video games and violence:
"I've gone and looked at a few of these places, and I've seen very little wrong with them," Mr. Broadwater [the mayor] said. But just because their patrons are honing their computer skills "doesn't mean they shouldn't be in school," he said.
Now that I think about it, the whole darn article is just a bunch of bunk holding together a few useful statements by people who might actually know something. Other favorite parts are the repeated references to race with no apparent point ("umm, by the way, they're all Vietnamese -- draw what conclusions you will, *wink*, *wink*"), and this classic bit:
it was the murder of Mr. Ly that brought the confluence of gangs and computer games -- once the province of harmless nerds -- to a dangerous level
The "harmless nerds" bit is just funny, and the idea that gangs are somehow not dangerous until mixed with video games is laughable as well.
Sure, DynDNS is great for some A records and CNAMEs under another domain (in fact I use them), but I'm not talking about that -- no one in his/her right mind would use his/her ISP address as something to hand out to people. Get a domain or subdomain and use that; you can migrate it easily from ISP to ISP.
What I'm talking about is the PTR records and the hopefully-matching A record going the other way. DynDNS can't help you there, because I seriously doubt AT&T is going to delegate your little part of in-addr.arpa to DynDNS.
Some paranoid admins won't allow connections from IPs that don't resolve into names or that resolve into names that don't resolve back into the IP. Rightfully so, I might add, as it only takes a modicum of competence (usually scripting) to ensure that reverse records are correctly set up. I don't want to suddenly lose access to those sites (as some friends on a different subnet have) because AT&T can't get their act together.
Sadly, competence seems to be going out of style. My personal favorites that I've seen lately (they've been portscanning me -- I don't go looking for this stuff):
12.161.192.5 => ip4.wpic.com.192.161.12.IN-ADDR.ARPA
207.252.75.118 => kayne1 Some folks clearly need to learn about $ORIGIN. (75.252.207.in-addr.arpa has turned into a lame server in the past few days, but used to be full of gems; the first one you can verify yourself.)
Something that is not at all mentioned in the article (or the/. story) is the issue of DNS, but I can't see AT&T retaining rights to the DNS records but not the use of email (the article seems to treat email as the only use for the domain name).
I suppose this means that my spiffy old <username>.ne.mediaone.net (I have fought many times to keep it from changing to one of those ugly hXXXXXXXXX.ne.mediaone.net addresses) will get changed into some ugly attbi.com address.
Either that or they will forgo the PTR record altogether, or screw it up so the PTR and A records don't match. DNS incompetence seems to be a sad trend with AT&T lately.
So now I get a new spam trap @attbi.com. *shrug* No one who knows anything uses their ISP's email account for anything important, anyway.
What worries me is not what they do with their crappy mail servers, but that they might someday go the way of other ISPs and start blocking TCP to port 25.
System 1 (with the 2.2.17 kernel) has never stayed up for more than 55 days. It hard crashes without anything informative being written to the logs, and obviously required the reset button to be pressed.
Of course it's crashing all the time; it's 2.2.17! You mention the logs, but not the console (don't expect syslogd to work when the kernel is in trouble). Does the console say something like "VM: do_try_to_free_pages failed"? See Kernel Traffic #99. That bug sucked, and, paradoxically, is one reason why I still haven't gone to 2.4 (after seeing all the VM trouble 2.4 had).
Upgrade to at least 2.2.19 or maybe apply Andrea Arcangeli's VM-global patch.
I still feel that shoving all the undergraduates in a low bandwidth ghetto because of a few bad apples is unfair and rather obnoxious.
Yeah, it sucks that people's actions can have negative consequences on other people, but it is pretty much part of living in society. My cable modem works that way, too. I think it's pretty clear that the root cause of your problems is the file-sharing. On the other hand, part of the network admin's job is to act as network cop and keep people from abusing other people. But this also is a matter of staff time and other issues. Do you really want HASCS to hire a bunch of people whose job it would be to monitor the users' network traffic? So far, Harvard has a pretty hands-off approach to data. HASCS won't even scan email for viruses out of slippery-slope privacy concerns. I'd like to keep things that way. (OK, so I made a few leaps there, and one could probably make a non-invasive system, but it would require a lot of work and at least the current system is non-invasive. The more specific the filtering gets, the more likely it is to become invasive)
I know of at least one faculty member who is a Morpheus user, who gets a free and clear connection from his office.
It should be clear that what matters in this situation is aggregate traffic, not anecdotal evidence. That one professor is getting a free ride at the cost of everyone else, but as a whole, professors using Morpheus is not a problem.
They need to come up with a viable long term solution, and the one they have now is not it.
Well, it is for everyone except students who happen to want to share files and play games...
Regulating bandwidth by user seems to be the only fair system. Keep a running count of the amount of data going to and from a certain IP, and if it exceeds some set amount in a period of time, just cut off the connection. Yes this requires some new infrastructure, but it is a reasonable amount.
The nice thing about the per-user thing is that it avoids making potentially-invasive judgements about which kinds traffic are more important. But you're still ignoring the problems I pointed out in my previous post.
While I have no idea how much money and time this would cost, you're talking about a very big project that would take people away from their current responsibilities and would be justified only by your desire to play games and others' desire to share files. I'm not sure that this is entirely HASCS's decision, anyway. I'm sure that if the University higher-ups decided that dedicated bandwidth to each dorm room was a priority for which it was worth sacrificing other things, it would happen. I doubt that they will.
Yes this requires some new infrastructure, but it is a reasonable amount. Normal ISPs do this sort of metering all the time.
How do you know it's a reasonable amount? Normal ISPs also probably have higher per-user costs, more money invested in equipment, and a much larger staff than HASCS. They pass these costs along in their monthy bills... monthly bills which, incidentally, you can start paying (like I do) if you wish. I may be wrong, but last I heard, you can get DSL in the dorms through Verizon. The real point is that the ISP business is very different from the university networking business.
Problem is, no one at school wants to hear about the problem; they just accept the collateral damage.
I suppose you don't remember the day this fall when packet shaping was turned off and absolutely nothing worked. The "poor performance" mentioned in that announcement is quite an understatement -- traceroute probes came back in times on the order of seconds or not at all. I also remember the days just before the traffic shaping was put in place and I was getting over 5-second ping times. People like games, but when email and the web stop working, people quickly start thinking about realistic priorities.
You also might ask yourself: did your games work when no traffic shaping was in place and ping times were measured in seconds and packet loss was rampant? I doubt it. How, then, can you blame the shaping for your problems if your problems didn't go away when the shaping did?
Does anyone know why/if this must be the case? i don't really understand why the software (perhaps Packetshaper as mentioned above) ruins the ping times
First of all, because of retransmits, dropping packets can lead to high "ping" times, depending on the protocol/application and what it considers a "ping." Second, the software may be trying to "smooth" out the traffic to fit under some limit -- queueing packets from burst periods to be transmitted in lower-traffic periods.
shouldn't it just drop enough packets so a TCP connection stays at a slow transfer rate?
That's a nice idea in theory, but the problem in practice is this: tracking all those individual TCP flows would require immense amounts of computation by the router. AFAIK, we're talking orders of maginitude greater than what is currently available. From what I hear, the really expensive Cisco router at the border is already extremely busy doing just the simple packet shaping, which just limits the aggregate high-port traffic. Breaking that one giant flow into millions of little flows is non-trivial and probably impossible.
Now I'm no networking expert, but it seems to me that doing traffic limitation on a per-user or per-flow basis would probably require some sort of distributed model that did the limiting closer to the user. This might mean not only replacing all the switches with more expensive models, but also hiring new staff (non-trivial) to install and integrate the new hardware into the existing network and to maintain the configuration on all those switches or to write some fancy new automated system to do the maintenance. Of course, all that is just another idea, and there may be some other pratical considerations that make it even less feasible. It also sounds like a lot of work, and considering why you would be asking them to do it, I can imagine that it would end up a lower-priority item than other things that the FAS network people have to do.
Not knowing much about the software, would it be possible to shape TCP connections and not UDP? (this would require reading the header)
I don't know either, but the file-sharing folks have shown themselves to be pretty adaptable. If they would play nice and limit themselves to certain ports and protocols, then everything would be easy. And, of course, who knows whether this would just require too much CPU time, as well.
Anyway, some background/historical info:
The undergraduate dorms get their connections through the FAS (Faculty of Arts and Sciences) network, which in turn gets its connection through UIS (University Information Services), which provides networking for all of Harvard. Back in the good old days of 2000, before the file-sharing people went crazy, UIS had just upgraded its internet connection (to a 155MB/s OC-3, IIRC) -- oh what heady and naieve days those were. Now, however, the situation is this: file-sharing programs seem to act as a gas that consumes all available bandwidth. That first started happening, IIRC, the weekend when Napster was going to be shut down. Suddenly, the undergraduates doing file-sharing shut down the connection for the entire university (which is much larger than the undergrads).
This is a classic "tragedy of the commons" scenario. The file-sharing folks abused a shared resource and ruined it for everyone else. What the traffic shaping essentially does, since it limits the student network to some portion of the FAS-UIS feed, is allow the file-sharing programs to ruin only the undergraduate dorm commons. Now, it's easy to blame the shaping for the bad performance, but the real truth of the matter is that if the file-sharing programs weren't trying to consume essentially infinite traffic, your games wouldn't have a problem. The router doesn't slow things down just to mess with you. Gamers are getting "scrood" by the other undergraduates doing file sharing, not the traffic shaping. Incidentally, the shaping is similar to the sometimes-raised suggestion of giving the students their own internet connection and fighting it out amongst themselves, except that traffic shaping makes it easier for people to complain about "the Man" and that a separate feed would be stepping on UIS's toes a bit. Also, a student-only connection would have to be much bigger than an OC-3, because it has already been demonstrated that an OC-3 can't handle the file-sharing traffic.
What most people want is for the file-sharing people to be moved out of their commons and into someone else's. That's what you're suggesting when you want TCP but not UDP to be limited. As an off-campus user, the file-sharing people are already out of my commons, so I'm happy that I can access Harvard websites and mail and login servers again. Most of the users of Harvard's network aren't on-campus undergraduates, either. Perhaps you can understand, then, why I'm defending the shaping. I like the network to be actually usable instead of the packet-dropping mess that it is when shaping isn't there.
There's also the option of getting rid of the commons, which is the shaping-per-user suggestion, but that has some disadvantages, too. Even if the undergrad dorms get one third of that university-wide OC-3, that's only 7.5kb/s per undergrad, which is not too great. Up the per-user bandwidth to something reasonable and now a certain number of file-sharing people can take everything over again.
Then there's the get-a-bigger-commons option. There are several problems with this. First, it's not clear that there exists a pipe fat enough for the number of file-sharing users among the undergraduates plus the other uses from the university at large. Second, of course, is what someone else has already mentioned -- try to imagine the FAS network admins justifying to UIS the need for the university to get a bigger feed, and UIS in turn having to justify that budget item, just for undergraduate file-sharing.
Everything I have said is based on what limited stuff I have seen and heard, but it seems to me that it's all really complicated, and if there were an easy solution, I'm sure it would already have been adopted.
As always, Slashdot is a discussion forum, not a venue for publishing master's theses or extensively fact-checked New Yorker articles.
Ah, yes, the old "My argument may be flawed, but these people are being snooty and unfair for pointing out its flaws and presenting their cases too well." A discussion forum Slashdot may be, but this is a thread about logical fallacies, not about which color iMac looks best. DNS-AND-BIND and crow asked how one might best form an argument to refute the "it sucks because it's old" argument; well-formed arguments are entirely appropriate.
If we lived in a microeconomist's dream universe... [straw man]
Who is talking about these ideal humans? I'm talking about judges, who are the ones that actually make decisions regarding these things, and who are hopefully wise enough to know the difference between well-established precedents and mere age, and failing that, are usually good enough to listen to a well-formed argument by a lawyer rather than blindly making a decision based on age alone.
When I say "theory of evolution" in this thread, I mean the popular definition of 'winnowing out of the less fit over a long period of time due to lesser ability to handle environmental stresses'...
I think the definition is fine enough. In fact, it makes my point: that it is the stresses that do the winnowing, not the time. The point of my magical weird environments analogy was that a species that has been around longer has not necessarily overcome more obstacles, just as a law that has been on the books longer has not necessarily been tested more often.
But tell me, why are such a high percentage of old houses also good houses? There are several factors, including the fact that building practices today are crap, but mainly because the bad, old houses have fallen down
The flaw in that analogy is that laws are not made of wood, and are unaffected by water leakage and termites. Laws are not periodically inspected -- they stay on the books until someone goes through the effort to challenge them and get them taken off. We have lots of silly old laws about the length of kisses and such that are unlikely to be challenged because no sane DA would ever risk his or her career by trying to prosecute someone for violating them.
If a rule in a pretty widely tested area of law stays unchallenged for 100 years, you also have to consider that perhaps the best lawyers of the last 100 years, in their (evolutionary) quest for the best defense, just decided to let that one lie?
Let us say that legions of lawyers have considered the law and found it to be unassailable. Are those acts of consideration not tests in themselves? All those unchallenged uses of the law in court will form the very string of precedents that I'm talking about.
The distinction I am trying to make is between those old laws that are in "pretty widely-tested areas" of law and those old laws that are not.
The problem being that the theories of "evolution" and "marketplace of ideas" both imply that if something is old, and is still around and/or still in use, it has a high probability of being a better solution to the problem than the alternatives that have come and gone in between.
Actually, I would disagree with you there, more with your choice of the word "old" than with the general thrust of your argument.
It's not the age, per se, but the number of times something has been tested. Both evolution and the marketplace of ideas imply some sort of competition or stress that repeatedly tests the creature or idea in question. The more times or ways in which something has been tested, the greater certainty you can have that it is a creature or idea well-adapted to the problem at hand. Age provides more opportunities for such testing, but does not guarantee it. The "alternatives that have come and gone in between" are what provide it.
Obligatory analogy: Let's say there are two Garden-of-Eden type islands (which, for the sake of this argument, magically suppress change to species that colonize them and which containin identical climate and plant life), the first of which is isolated and populated exclusively by an animal that has lived there and existed unchanged for 600 million years, the second of which is not so isolated and which many species have fought over, one of which has come to dominance in the past 10 million years. Now a third Garden island appears (magically) within colonization distance of the other two. Do you mean to tell me that evolution implies that the animal from the first island, by sheer virtue of its long-established pedigree, will be more successful because it is better-adapted to its environment?
Back to the courts, I think it is reasonable to argue that a law from 1983 that has been repeatedly tested in the courts and has attached to it a long string of precedents should be given more weight than another law from 1903 that has never been tested in court. Such a situation is rare, of course, and usually old laws are also time-tested, and so it is natural for us to give them some respect in the absence of some other rational argument that might indicate the contrary.
Not a certainty, or even necessarily close to a 100% probability, but at least a higher probability.
So the longevity of a solution to a problem is never irrelevant.
While it is fair to say that, all other things being equal, older laws have a higher probability of having been tested more times and thus a higher probability of being backed up by precedent, why confuse the issue? All other things aren't always equal -- antitrust cases are rare, and old laws or rulings that apply to them very likely will not have as many opportunities to be tested as newer rulings that apply to more common cases. Age provides an opportunity for precedent, but does not in itself establish it.
Witness the 10 Commandments, the Bill of Rights, etc.
The Ten Commandments and the Bill or Rights are respected by many not because of their age but because of their history, because of the relevance and instrinsic value that many see in what they have to say, and because of many other reasons including the profound respect that many feel for God and for the Founding Fathers. Do you think we should rank above them Hammurabi's Code just because it's older?
argh... hit "submit" instead of "preview" (no caffeine yet today)... to continue:
What you seem to have missed about the GPL is that it is a license, not a law. That is, it is an agreement between the licensor and the licensee. It affects only what the licensee can do with the licensor's code in the future.
There is nothing about the GPL that prevents the company from turning around and licensing the code they wrote to someone else (or themselves) under a different, closed-source license.
What they can not do is take someone else's new, GPL-ed contributions to their now GPL-ed code and re-license them to someone else. Why? Because those independent contributions are not their code. That's one of the beautiful things about the GPL. I am unlikely to spend my own time debugging and fixing a program for a company if that company is going to turn around and try to sell my own code back to me. If they're not GPL'ed they can write their own damn code.
GPL-ing one's code, then, can (if one wishes to think of it this way) represent a sort of code fork, after which point the open- and closed- versions of the code assume lives of their own. However, in practice, since we're talking about supposedly-obsolete code, there would be little reason for any consumer to buy the closed-source version, unless the company later made modifications to it to make it more attractive than the GPL-ed version, like Tripwire has done.
To answer your question more specifically, Microsoft could GPL Win95 and continue to sell WinXP as a closed-source product. They could not take someone else's GPL-ed modified version of the GPL-ed Win95 and apply the changes therein to the closed WinXP (unless they made specific arrangements to re-license the code of the modifications from their author or authors), but if they didn't GPL Win95, there would be no such patch in the first place, so that's not really something to complain about. In fact, Microsoft could GPL WinXP and continue to sell and develop WinXP under a close-source license, though it is questionable whether anyone would buy it.
One reason for a company not to make their software public domain or BSD-licensed is that it might allow a competitor to start selling a modified version of the software and put them out of business (or, in Microsoft's case, force them to acquire the competitor). That's that advantage of the GPL again -- it prevents people from running off with your code and trying to sell it back to you.
Finally, let me direct you to this portion of the GPL FAQ, which also addresses these issues.
One point: If someone whos business depends on closed source software were to GPL their earlier and no-longer-supported program, they endanger their own re-use of that code in their new software.
That is an absurd statement, for several reasons.
Anything the company or anyone else did with the code prior to its release under the GPL is completely unaffected (in licensing terms) by its subsequent release under the GPL. The GPL is not retroactive.
The company still "owns" the code and can do whatever they want to with it (except revoke perpetual licenses that they have already granted).
The company can license the code to a third party under any license they want, if they so choose.
Slashdot Mirror
Just use authentication for them. Surely, it wouldn't be any harder than keeping user accounts on the intranet servers up to date. It could even use the same authentication database.
What accounts? What authentication database? Presently, the existence of a mailing address does not imply the existence of a user account. Consider forwarding-only addresses. Should all the volunteers behind bugs@opensourceproject.example.org require accounts? Maybe the sysadmin is a volunteer, too.
What about those of us who use webmail addresses as spam traps? Now we have to use crappy web interfaces to send (or those webmail companies have to set up SMTP AUTH, with which they very well may not want to bother).
...and so on, and so on...
The downside of it is that if you have a yahoo.com address, but want to run your own smtp server to deliver your mails, then you'd fall foul of such a system. I don't think that's a biggy though - if you could run your own smtp server, you'd probably not use a yahoo.com address you'd have your own domain :).
Actually, this is a pretty big downside for many users. Every once in a while, someone proposes a similar scheme that makes it hard or impossible to "forge" From addresses. This is not exactly that, but it's close enough. The problem is that this is a perfectly legitimate and necessary use of email, and is, in fact, discussed in RFC 822.
The basic problem is that many of us wear quite a few different hats, each of which has one or more email addresses. Suppose I want to send an email using my personal address while I'm at work, or my work address while I'm at home. Suppose I need to reply to some email sent to an official address using that official address as the header From, and that I also want bounces to go to that address so that others at that address can see if my reply was not sufficient (requiring a change in the envelope From). Maybe I do run my own smtp server and domain, but I want to use my spam-trapping yahoo address to reply to yahoo mail (for privacy reasons), and I want to use mutt instead of some stupid web interface. Maybe I'm a sysadmin who wants to set up a number of forwarding addresses (perhaps official addresses for some project on some domain). Now my one-way service has to be a two-way service; instead of just editing the aliases file, I have to set up an account for each of the people who needs to send mail. These are just some of the things that I happen to do on a daily basis and that adoption of your system might make impossible or more of a pain.
Sure, a lot of times this can be solved by some sort of remote access or SMTP auth, but it would certainly be less convenient (especially because some sites are difficult to access remotely). The bigger problems are social: many of the users I know who do these sorts of things aren't the most technically-savvy; many domains are unlikely to introduce the features necessary for full remote access (so then it becomes less of an inconvenience and more of a loss of service).
The good thing about your proposal is that it's opt-in for the sender's domain (whereas most others are opt-in for the recipient's domain), and it therefore gives a domain more control over its email addresses (as opposed to less with other schemes). It allows example.com to say "we want mail from addresses in our domain sent out via only our servers." Presently, anti-relaying provisions in servers make it possible to say "we want only mail from addresses in our domain sent out via our servers." This just completes things.
I guess it depends on your perspective. As a sysadmin, I'd be happy to have the power to turn this on for my domain (though I probably wouldn't, and other domains might not use it -- look at how terrible people are with MX records). As a user, I'd be unhappy if one of my sysadmins turned it on, but happy if some of the domains spammers use and I don't use turned it on. I guess it might be sort of a "not in my backyard" issue, which might limit its adoption. Another problem might be sysadmins that block domains which don't have these records, thus taking the power away from the sender's domain again.
While I'm rambling
While I'm ramblingly replying:
When an email comes in, you check if there's a verification server for the source domain of the email, and if so try connect to it, and then submit the email address for verification. [...] I know SMTP vrfy exists, but sites often turn it off
They turn it off because it can be abused by spammers looking for valid addresses or is in some other way a privacy concern. What you propose is functionally equivalent to VRFY (except that it can run on a different server), so I doubt it would be turned on either. However, it might not be a bad thing for servers to *try* to VRFY an address, and only block if VRFY returns "no such user" (not "permission denied"). If a separate protocol and server is desirable, there is always good old finger (though it's maybe a little too free-form), but VRFY makes more sense, as the primary mail servers should know to whom they can deliver mail.
The heart of your scheme is to make it really expensive to send thousands of mails per day. What about those of us who run sites that send tens or hundreds of thousands of legitimate emails per day on behalf of tens or hundreds of thousands of users?
Our four old single-CPU mail servers handle half a million legititmate messages per day with very little load (there are four for crazy levels of redundancy). Most of what they do is to just shuffle data around or do DNS lookups. Now you're asking them to do computationally-intesive tasks that take 5 seconds per message, so to handle the load averaged over a day, I'd now need 29 mail servers running at full CPU utilization all day [(500000 mails/day) * (5 CPU*secs/mail) / (86400 secs/day) =~ 29 CPU]. However, the load is not even over the course of the day; at peak times (mid-afternoon) the rate is easily more than five times the average. To handle peak loads of exactly five times the average, I'd need 145 servers working full-blast.
Even so, I still wouldn't have the comfortable margin I have now. For that, I'd need even more servers. Even if I could justify the outlay for the machines, I'd have to get a new machine room to house them and supply the power, UPS, and A/C. Then I'd have to set up all those machines, keep them patched, and so on. To say that would be highly unlikely for such a plan to be approved would be an understatement. Sure, spam sucks and costs legitimate people money, but is stopping it worth increasing by nearly two orders of magnitude the costs associated with running legitimate mail servers?
Granted, those esitmates are not accurate because not every mail would require CPU-intensive verification, but some of them would, possibly a good portion of them if your proposal were widely accepted. The worst part is I would entirely dependent on some remote sysadmin putting my servers on his list of "trusted" servers. Do you realize with how many other sites and unique email addresses we exchange mail? Don't sysadmins have enough to do without spending their time maintaining such a list? Even in the highly-unlikely best case, where the system operates perfectly, every mail we send out is magically a hit on the remote site's list, and entries are added to the list on our site automagically, you're still talking a *huge* and growing database, and that's going to cost something (computer time doing the lookups, sysadmin time maintaining the database). In the real world, however, it would porbably be worse.
Bottom line: this may work fine on your little pentium Linux box at home running a vanity domain, but it'll go over like a lead balloon with sysadmins in the big leagues and the people who control their purse-strings. You'll have to prove to them that the absolutely certain benefits outweigh the remotely possible costs, and that implementing such a system won't disrupt or slow mail delivery in any way. Good luck on that.
I'm not saying that I couldn't be convinced that such a scheme would be a good idea, but I remain extremely skeptical. The answer to this proposal seems to be that given to so many proposals: "DOES NOT SCALE". I really need to get a rubber stamp that says that. What makes this proposal actually irksome is that the lack of scalability is deliberate.
With a typed ASCII password you've got 2^128*n password combinations (where n is the number of symbols in your password), with an iconic password you've only got y^n password combinations (where y in the total number of icons which is limited to how many can be displayed on the screen at once).
I think you are confused. The number of combinations of N characters in a character set of size Y is y^n, not 2^y*n (if order is significant and repetition is allowed, both of which are usually the case for passwords). ASCII does not have 2^128 characters; it has 128 (0x00 through 0x7F), but that's not necessarily equivalent to what one can type on a keyboard. If one could type all of them and only all of them on the keyboard, that would allow 128^n passwords of length n.
In any case, even with a relatively modest 80x25 grid (much like a standard DOS or Linux console screen), one can fit 80 * 25 = 2000 symbols on the screen, giving 2000^n possible combinations, provided one can come up with 2000 easily distinguishable symbols (well, the Chinese have done it) and display them in a resolution at which they could be distinguished.
If one just wanted to display 128 characters, one could use an 8 x 16 grid. That is hardly a challenge. Then the user can select whatever ASCII characters he/she wants to select in whatever order he/she wants to select them, again yielding 128^n possible passwords of length n.
What do you pay your ISP for? To intercept your packets. Because otherwise, they're not getting anywhere.
Don't be silly. There is a clear distinction between reading the IP headers of a packet to make a routing decision and recording the application-layer data within the packet. I pay my ISP for the former.
The person at the other end of your phone call is also allowed to tap the phone line with their telephone and listen.
Of course they are. The communication is intended for them. It's not a tap -- it's called answering the phone. No judge would be foolish enough to believe that it was a tap. You seem to be attempting to discard all common sense and rely on semantic games to make your argument. It won't fly in court.
Wiretapping laws come into play only when the person listening is not the person whose wire it is
That is patently false. Read the laws.
Otherwise it would be illegal for the phone system to route your calls to the person you're calling.
No it wouldn't. Sheesh. Lawmakers and judges are not idiots. They are quite capable of seeing the distinction between IP headers and the data inside the packet, between the digits pressed before a phone call and the conversation during the call itself.
IP headers and phone numbers are data that is explicitly meant for the uses of the network equipment. They in no way constitute private communications. However, that fact does not make the rest of the packet or phone call any less private. To argue that it does is a fallacy of composition.
Unencrypted data is like postcards with respect to expectations of privacy: it doesn't have the digital equivalent of an envelope, and the address information is not separated from the content in any meaningful way.
There is no "envelope" around a phone call, either. In fact, since the time it takes to dial a number is variable and there is no terminator to the dialing sequence, it's even worse. At least IP headers are defined fairly strictly in RFC 791.
You can therefore not expect privacy of the data from anyone who is responsible for routing.
I most certainly can. Routing packets by reading the IP headers which I put on them for the routers' benefit is one thing. Setting up a box to read through the data in the packet is quite another.
The fact that routers only look at the IP headers by default and that you'd have to install special equipment and/or software to record the application-layer data is a pretty strong indication that the distinction between the IP header and the data is meaningful.
It's worth noting that laws apply to people (and corporations), not machines. It's not illegal for a router or the phone system to do anything. It's when the ISP installs some equipment to monitor private communications (for purposes other than those explicitly allowed) or when someone looks at/listens to those communications or discloses their contents to someone else that the law applies.
Finally, let me reiterate: whether the communications are encrypted or not is irrelevant for the purposes of the law. Read it.
Unencrypted data is like postcards
No, it's not; it's like unencrypted data. It bears absolutely no resemblance to a 4 x 6 inch piece of cardboard.
IANAL, but it seems to me that it's an electronic communication, and that's what US Code Title 18 Part I, Chapter 119, Section 2511 is all about: "Interception and disclosure of wire, oral, or electronic communications prohibited"
Perhaps if you printed your HTTP requests on index cards and mailed them to the web server, the requests would be covered by postal code. But for most people, HTTP requests are electronic communications.
I could tell you that "the unencrypted data, she is like a fine wine," but that would not make it subject to state liquor taxes.
IANAL, but I'd say you have just about as much expectation of privacy as you do sending unencrypted voice over the public telephone network, which is to say a substantial expectation.
Data on a switched network between two large ISPs is no easier to intercept than voice going between two large phone companies. In fact, I daresay it would be easier for me to tap my neighbor's phone than his cable modem (I could do it with a pair of pliers and some wire); it would, however, be illegal and IMO wrong for me to do so.
Bottom line: even though it may be *possible* for nefarious people to tap your phone, put bugs in your living room, or even implant a chip in your brain, you can still have an expectation of privacy. Not wrapping your house in tinfoil does not mean you're giving up your right to privacy, because your home is not a public forum. The wires between you and a web server do not constitute a public forum by any stretch of the imagination (even if the server happens to be hosting a public forum). Not using HTTPS does not consitute an abdication of privacy.
If you run a packet sniffer and look at other people's data, good luck convincing a judge that you weren't doing something bad under Section 2511 because the data wasn't encrypted.
"Hey, his front door wasn't locked, so I didn't really steal his TV..."
"Hey, the guy didn't use The Club, so this really isn't Grand Theft Auto..."
"Hey, she was wearing that short skirt; she deserved it..."
OK, so apparently I need to take some or most of that back because the phone companies have been busy installing twisted-pair for some time (and adding more twists per foot).
On the other hand, I looked in the basement and the feed into my old building (where it connects on an old wiring block to rubber-insulated wires) is definitely not twisted (or not twisted much), which explains all those voices on the line. Maybe it connects to twisted-pair outside, though.
Maybe someone who actually works in the industry (and is not an armchair idiot like me) can set the record straight (or twisted) before I dig myself into too deep a hole.
MOD PARENT UP!
Normal phone lines aren't usually twisted. The word "twisted" does not appear in the original article. Who knows from where timothy got the idea that the lines were "twisted"?
This is not some trifling detail -- there is a *big* difference between twisted and straight pairs at the distances phone lines typically cover. If this tech requires pulling new twisted-pair copper, then it's not very useful.
All of these draconian rules will simply drive more and more people away from flying.
That's OK; Congress will just keep bailing out the airlines.
[I'm no planetary scientist, so you'll have to forgive any inaccuracies, and maybe someone who knows a little more will correct me.] One possible reason for the importance of the Moon (if one believes it originated in an impact) is that it may contain a great deal of light outer-crust rock that would normally be on Earth.
Earth has these little continents that leave the thin tectonic plates (made of denser rock and covered with vast oceans) free to move around. Imagine how different Earth would be if all the rock that currently orbits us were instead filling the ocean basins and keeping the plates from moving around.
A few back-of-the-envelope (containing some stupid coupon from AT&T Broadband) calculations gives about 2x10^19 m^3 for the volume of the Moon, 5 x 10^14 m^2 for the surface area of the Earth, so, spreading the moon out evenly (and neglecting curvature), a layer 4 x 10^4 m thick. Granted, it might not all be silicate, but it's a lot of rock, especially considering that the average depth of the oceans is around 4 x 10^3 m, and the plates under the oceans are around 5 x 10^3 m thick (results of random web searches).
Something to think about the next time you look up at the Moon.
Well, the Forbes article says $8.75 an hour.
:)
Maybe the Harvard students in the Living Wage campaign ought to march down the street and stage a sit-in at the MIT Media Lab.
The beginning of the article seems to be trying to imply some link between violent video games and real-world violence, but the statements of experts in the article don't seem to support that idea.
It looks like the violence has moved from the schools, not from the computer screens, to the parking lots outside the cafes (or, presumably, anywhere else the kids might gather).
It seems to me that the mayor and others involved are imposing these restrictions because they were just recently exposed to the fact that the kids were ditching school, not because of some presumed causal link between video games and violence:
Now that I think about it, the whole darn article is just a bunch of bunk holding together a few useful statements by people who might actually know something. Other favorite parts are the repeated references to race with no apparent point ("umm, by the way, they're all Vietnamese -- draw what conclusions you will, *wink*, *wink*"), and this classic bit:
The "harmless nerds" bit is just funny, and the idea that gangs are somehow not dangerous until mixed with video games is laughable as well.
Sure, DynDNS is great for some A records and CNAMEs under another domain (in fact I use them), but I'm not talking about that -- no one in his/her right mind would use his/her ISP address as something to hand out to people. Get a domain or subdomain and use that; you can migrate it easily from ISP to ISP.
What I'm talking about is the PTR records and the hopefully-matching A record going the other way. DynDNS can't help you there, because I seriously doubt AT&T is going to delegate your little part of in-addr.arpa to DynDNS.
Some paranoid admins won't allow connections from IPs that don't resolve into names or that resolve into names that don't resolve back into the IP. Rightfully so, I might add, as it only takes a modicum of competence (usually scripting) to ensure that reverse records are correctly set up. I don't want to suddenly lose access to those sites (as some friends on a different subnet have) because AT&T can't get their act together.
Sadly, competence seems to be going out of style. My personal favorites that I've seen lately (they've been portscanning me -- I don't go looking for this stuff):
12.161.192.5 => ip4.wpic.com.192.161.12.IN-ADDR.ARPA
207.252.75.118 => kayne1
Some folks clearly need to learn about $ORIGIN. (75.252.207.in-addr.arpa has turned into a lame server in the past few days, but used to be full of gems; the first one you can verify yourself.)
did Judge Claudia Wilken have to watch both movies to determine that there was little chance of confusion?
Something that is not at all mentioned in the article (or the /. story) is the issue of DNS, but I can't see AT&T retaining rights to the DNS records but not the use of email (the article seems to treat email as the only use for the domain name).
I suppose this means that my spiffy old <username>.ne.mediaone.net (I have fought many times to keep it from changing to one of those ugly hXXXXXXXXX.ne.mediaone.net addresses) will get changed into some ugly attbi.com address.
Either that or they will forgo the PTR record altogether, or screw it up so the PTR and A records don't match. DNS incompetence seems to be a sad trend with AT&T lately.
Same deal with me and my @mediaone.net address.
So now I get a new spam trap @attbi.com. *shrug*
No one who knows anything uses their ISP's email account for anything important, anyway.
What worries me is not what they do with their crappy mail servers, but that they might someday go the way of other ISPs and start blocking TCP to port 25.
System 1 (with the 2.2.17 kernel) has never stayed up for more than 55 days. It hard crashes without anything informative being written to the logs, and obviously required the reset button to be pressed.
Of course it's crashing all the time; it's 2.2.17! You mention the logs, but not the console (don't expect syslogd to work when the kernel is in trouble). Does the console say something like "VM: do_try_to_free_pages failed"? See Kernel Traffic #99. That bug sucked, and, paradoxically, is one reason why I still haven't gone to 2.4 (after seeing all the VM trouble 2.4 had).
Upgrade to at least 2.2.19 or maybe apply Andrea Arcangeli's VM-global patch.
Yeah, it sucks that people's actions can have negative consequences on other people, but it is pretty much part of living in society. My cable modem works that way, too. I think it's pretty clear that the root cause of your problems is the file-sharing. On the other hand, part of the network admin's job is to act as network cop and keep people from abusing other people. But this also is a matter of staff time and other issues. Do you really want HASCS to hire a bunch of people whose job it would be to monitor the users' network traffic? So far, Harvard has a pretty hands-off approach to data. HASCS won't even scan email for viruses out of slippery-slope privacy concerns. I'd like to keep things that way. (OK, so I made a few leaps there, and one could probably make a non-invasive system, but it would require a lot of work and at least the current system is non-invasive. The more specific the filtering gets, the more likely it is to become invasive)
It should be clear that what matters in this situation is aggregate traffic, not anecdotal evidence. That one professor is getting a free ride at the cost of everyone else, but as a whole, professors using Morpheus is not a problem.
Well, it is for everyone except students who happen to want to share files and play games...
The nice thing about the per-user thing is that it avoids making potentially-invasive judgements about which kinds traffic are more important. But you're still ignoring the problems I pointed out in my previous post.
While I have no idea how much money and time this would cost, you're talking about a very big project that would take people away from their current responsibilities and would be justified only by your desire to play games and others' desire to share files. I'm not sure that this is entirely HASCS's decision, anyway. I'm sure that if the University higher-ups decided that dedicated bandwidth to each dorm room was a priority for which it was worth sacrificing other things, it would happen. I doubt that they will.
How do you know it's a reasonable amount? Normal ISPs also probably have higher per-user costs, more money invested in equipment, and a much larger staff than HASCS. They pass these costs along in their monthy bills... monthly bills which, incidentally, you can start paying (like I do) if you wish. I may be wrong, but last I heard, you can get DSL in the dorms through Verizon. The real point is that the ISP business is very different from the university networking business.
I suppose you don't remember the day this fall when packet shaping was turned off and absolutely nothing worked. The "poor performance" mentioned in that announcement is quite an understatement -- traceroute probes came back in times on the order of seconds or not at all. I also remember the days just before the traffic shaping was put in place and I was getting over 5-second ping times. People like games, but when email and the web stop working, people quickly start thinking about realistic priorities.
You also might ask yourself: did your games work when no traffic shaping was in place and ping times were measured in seconds and packet loss was rampant? I doubt it. How, then, can you blame the shaping for your problems if your problems didn't go away when the shaping did?
First of all, because of retransmits, dropping packets can lead to high "ping" times, depending on the protocol/application and what it considers a "ping." Second, the software may be trying to "smooth" out the traffic to fit under some limit -- queueing packets from burst periods to be transmitted in lower-traffic periods.
That's a nice idea in theory, but the problem in practice is this: tracking all those individual TCP flows would require immense amounts of computation by the router. AFAIK, we're talking orders of maginitude greater than what is currently available. From what I hear, the really expensive Cisco router at the border is already extremely busy doing just the simple packet shaping, which just limits the aggregate high-port traffic. Breaking that one giant flow into millions of little flows is non-trivial and probably impossible.
Now I'm no networking expert, but it seems to me that doing traffic limitation on a per-user or per-flow basis would probably require some sort of distributed model that did the limiting closer to the user. This might mean not only replacing all the switches with more expensive models, but also hiring new staff (non-trivial) to install and integrate the new hardware into the existing network and to maintain the configuration on all those switches or to write some fancy new automated system to do the maintenance. Of course, all that is just another idea, and there may be some other pratical considerations that make it even less feasible. It also sounds like a lot of work, and considering why you would be asking them to do it, I can imagine that it would end up a lower-priority item than other things that the FAS network people have to do.
I don't know either, but the file-sharing folks have shown themselves to be pretty adaptable. If they would play nice and limit themselves to certain ports and protocols, then everything would be easy. And, of course, who knows whether this would just require too much CPU time, as well.
Anyway, some background/historical info:
The undergraduate dorms get their connections through the FAS (Faculty of Arts and Sciences) network, which in turn gets its connection through UIS (University Information Services), which provides networking for all of Harvard. Back in the good old days of 2000, before the file-sharing people went crazy, UIS had just upgraded its internet connection (to a 155MB/s OC-3, IIRC) -- oh what heady and naieve days those were. Now, however, the situation is this: file-sharing programs seem to act as a gas that consumes all available bandwidth. That first started happening, IIRC, the weekend when Napster was going to be shut down. Suddenly, the undergraduates doing file-sharing shut down the connection for the entire university (which is much larger than the undergrads).
This is a classic "tragedy of the commons" scenario. The file-sharing folks abused a shared resource and ruined it for everyone else. What the traffic shaping essentially does, since it limits the student network to some portion of the FAS-UIS feed, is allow the file-sharing programs to ruin only the undergraduate dorm commons. Now, it's easy to blame the shaping for the bad performance, but the real truth of the matter is that if the file-sharing programs weren't trying to consume essentially infinite traffic, your games wouldn't have a problem. The router doesn't slow things down just to mess with you. Gamers are getting "scrood" by the other undergraduates doing file sharing, not the traffic shaping. Incidentally, the shaping is similar to the sometimes-raised suggestion of giving the students their own internet connection and fighting it out amongst themselves, except that traffic shaping makes it easier for people to complain about "the Man" and that a separate feed would be stepping on UIS's toes a bit. Also, a student-only connection would have to be much bigger than an OC-3, because it has already been demonstrated that an OC-3 can't handle the file-sharing traffic.
What most people want is for the file-sharing people to be moved out of their commons and into someone else's. That's what you're suggesting when you want TCP but not UDP to be limited. As an off-campus user, the file-sharing people are already out of my commons, so I'm happy that I can access Harvard websites and mail and login servers again. Most of the users of Harvard's network aren't on-campus undergraduates, either. Perhaps you can understand, then, why I'm defending the shaping. I like the network to be actually usable instead of the packet-dropping mess that it is when shaping isn't there.
There's also the option of getting rid of the commons, which is the shaping-per-user suggestion, but that has some disadvantages, too. Even if the undergrad dorms get one third of that university-wide OC-3, that's only 7.5kb/s per undergrad, which is not too great. Up the per-user bandwidth to something reasonable and now a certain number of file-sharing people can take everything over again.
Then there's the get-a-bigger-commons option. There are several problems with this. First, it's not clear that there exists a pipe fat enough for the number of file-sharing users among the undergraduates plus the other uses from the university at large. Second, of course, is what someone else has already mentioned -- try to imagine the FAS network admins justifying to UIS the need for the university to get a bigger feed, and UIS in turn having to justify that budget item, just for undergraduate file-sharing.
Everything I have said is based on what limited stuff I have seen and heard, but it seems to me that it's all really complicated, and if there were an easy solution, I'm sure it would already have been adopted.
Ah, yes, the old "My argument may be flawed, but these people are being snooty and unfair for pointing out its flaws and presenting their cases too well." A discussion forum Slashdot may be, but this is a thread about logical fallacies, not about which color iMac looks best. DNS-AND-BIND and crow asked how one might best form an argument to refute the "it sucks because it's old" argument; well-formed arguments are entirely appropriate.
Who is talking about these ideal humans? I'm talking about judges, who are the ones that actually make decisions regarding these things, and who are hopefully wise enough to know the difference between well-established precedents and mere age, and failing that, are usually good enough to listen to a well-formed argument by a lawyer rather than blindly making a decision based on age alone.
I think the definition is fine enough. In fact, it makes my point: that it is the stresses that do the winnowing, not the time. The point of my magical weird environments analogy was that a species that has been around longer has not necessarily overcome more obstacles, just as a law that has been on the books longer has not necessarily been tested more often.
The flaw in that analogy is that laws are not made of wood, and are unaffected by water leakage and termites. Laws are not periodically inspected -- they stay on the books until someone goes through the effort to challenge them and get them taken off. We have lots of silly old laws about the length of kisses and such that are unlikely to be challenged because no sane DA would ever risk his or her career by trying to prosecute someone for violating them.
Let us say that legions of lawyers have considered the law and found it to be unassailable. Are those acts of consideration not tests in themselves? All those unchallenged uses of the law in court will form the very string of precedents that I'm talking about.
The distinction I am trying to make is between those old laws that are in "pretty widely-tested areas" of law and those old laws that are not.
Actually, I would disagree with you there, more with your choice of the word "old" than with the general thrust of your argument.
It's not the age, per se, but the number of times something has been tested. Both evolution and the marketplace of ideas imply some sort of competition or stress that repeatedly tests the creature or idea in question. The more times or ways in which something has been tested, the greater certainty you can have that it is a creature or idea well-adapted to the problem at hand. Age provides more opportunities for such testing, but does not guarantee it. The "alternatives that have come and gone in between" are what provide it.
Obligatory analogy: Let's say there are two Garden-of-Eden type islands (which, for the sake of this argument, magically suppress change to species that colonize them and which containin identical climate and plant life), the first of which is isolated and populated exclusively by an animal that has lived there and existed unchanged for 600 million years, the second of which is not so isolated and which many species have fought over, one of which has come to dominance in the past 10 million years. Now a third Garden island appears (magically) within colonization distance of the other two. Do you mean to tell me that evolution implies that the animal from the first island, by sheer virtue of its long-established pedigree, will be more successful because it is better-adapted to its environment?
Back to the courts, I think it is reasonable to argue that a law from 1983 that has been repeatedly tested in the courts and has attached to it a long string of precedents should be given more weight than another law from 1903 that has never been tested in court. Such a situation is rare, of course, and usually old laws are also time-tested, and so it is natural for us to give them some respect in the absence of some other rational argument that might indicate the contrary.
While it is fair to say that, all other things being equal, older laws have a higher probability of having been tested more times and thus a higher probability of being backed up by precedent, why confuse the issue? All other things aren't always equal -- antitrust cases are rare, and old laws or rulings that apply to them very likely will not have as many opportunities to be tested as newer rulings that apply to more common cases. Age provides an opportunity for precedent, but does not in itself establish it.
The Ten Commandments and the Bill or Rights are respected by many not because of their age but because of their history, because of the relevance and instrinsic value that many see in what they have to say, and because of many other reasons including the profound respect that many feel for God and for the Founding Fathers. Do you think we should rank above them Hammurabi's Code just because it's older?
Using space technology...
"Space technology"? What is this, the 1950's?
"Hey, Space Jimmy, time for your Space Math lesson."
"Spaceriffic!"
"What's space two plus space two?"
"Space four!"
argh... hit "submit" instead of "preview" (no caffeine yet today)... to continue:
What you seem to have missed about the GPL is that it is a license, not a law. That is, it is an agreement between the licensor and the licensee. It affects only what the licensee can do with the licensor's code in the future.
There is nothing about the GPL that prevents the company from turning around and licensing the code they wrote to someone else (or themselves) under a different, closed-source license.
What they can not do is take someone else's new, GPL-ed contributions to their now GPL-ed code and re-license them to someone else. Why? Because those independent contributions are not their code. That's one of the beautiful things about the GPL. I am unlikely to spend my own time debugging and fixing a program for a company if that company is going to turn around and try to sell my own code back to me. If they're not GPL'ed they can write their own damn code.
GPL-ing one's code, then, can (if one wishes to think of it this way) represent a sort of code fork, after which point the open- and closed- versions of the code assume lives of their own. However, in practice, since we're talking about supposedly-obsolete code, there would be little reason for any consumer to buy the closed-source version, unless the company later made modifications to it to make it more attractive than the GPL-ed version, like Tripwire has done.
To answer your question more specifically, Microsoft could GPL Win95 and continue to sell WinXP as a closed-source product. They could not take someone else's GPL-ed modified version of the GPL-ed Win95 and apply the changes therein to the closed WinXP (unless they made specific arrangements to re-license the code of the modifications from their author or authors), but if they didn't GPL Win95, there would be no such patch in the first place, so that's not really something to complain about. In fact, Microsoft could GPL WinXP and continue to sell and develop WinXP under a close-source license, though it is questionable whether anyone would buy it.
One reason for a company not to make their software public domain or BSD-licensed is that it might allow a competitor to start selling a modified version of the software and put them out of business (or, in Microsoft's case, force them to acquire the competitor). That's that advantage of the GPL again -- it prevents people from running off with your code and trying to sell it back to you.
Finally, let me direct you to this portion of the GPL FAQ, which also addresses these issues.
Don't believe the FUD.
That is an absurd statement, for several reasons.