stanley@phoenix.com (John Stanley) (05/18/91)
gregory@csri.toronto.edu (Kate Gregory) writes: > I've deleted attributions here on purpose. Someone somewhere writes: > > > I don't have access to ftp, and I can only get mail. I just tried to use > >bitftp, but the reply said something to the effect of my site being a > >'mail only site' and bitftp could no longer provide services to it. Could > >somebody please e-mail me the uuencoded PC binaries and documentation? > >Just send me a message saying you have it first... that way, I won't end > >up getting several megs worth of mail that is the same thing several > >times over. Amazing how quickly the requests for human generated multi-megabyte mail start to show up when the machine generated stuff is stopped. But this mail is ok because it is human generated, right? When this fellow gets multiple copies of the same thing, and he will, won't this take more resources to pass than one response from BITFTP? Like I said. The problem was not BITFTP. The problem is software that happily attempts to scribble across a disk on which there is no space. We would not accept this in any other application, especially an unattended one, but we will accept this from uucico. Well, BITFTP has shut itself off. Disks will now be filled with human generated mail. Fixing uucico would stop the problem at its root, but no, the next thing to be dropped will be mail itself. Then newsgroups will become too large, and those will be dropped. Unless you fix the uucico problem, you will never be rid of the problem of filled disks.
bob@MorningStar.Com (Bob Sutterfield) (05/18/91)
In article <kyV422w163w@phoenix.com> stanley@phoenix.com (John Stanley) writes:
Unless you fix the uucico problem, you will never be rid of the
problem of filled disks.
You may have encountered a problem with downstream sites filling your
spools with sources in transit, and you may consider that to be "the
uucico problem". Many others have encountered a problem with
downstream sites filling their long-distance phone lines with sources
in transit. This is what their beancounters consider to be "the
uucico problem" when they get the phone bill at the end of the month.
Both are impolite, and both threaten the neighborliness of our
networks.
The polite thing to do is to pay for the shipment of the data you
cause to be shipped.paul@frcs.UUCP (Paul Nash) (05/19/91)
Thus spake bob@MorningStar.Com (Bob Sutterfield): > > ... Many others have encountered a problem with > downstream sites filling their long-distance phone lines with sources > in transit. As one of those with a long-distance (trans-Atlantic) telephone, and attendant bill (that comes out of my private and personal pocket :-(), I can only agree. This problem has caused me to turn off mail forwarding to other sites, so that they can't get _any_ mail via my link, because of a few megabytes (and $1000's) of FTP stuff that was spewed over my phone. I, for one, welcome the demise of the BITFTP server, even though I used it a fair amount myself. It _did_ have its merits though -- I was busy setting up a filter that would look for `BITFTP' in any of the mail headers and trash the offending item. The problem (and solution) is one of politeness. If the individuals had approached me and offered to pay, I would have been only to happy to leave my link as a mail path. As it is, a few bad-mannered people have spoiled it for everyone. This makes _me_ feel guilty, but it's the only way to cope with a bad-mannered bank-manager. ---=---=---=---=---=---=---=---=---=---=---=---=---=---=---=---=---=--- Paul Nash Free Range Computer Systems cc paul@frcs.UUCP ...!uunet!m2xenix!frcs!paul
merce@iguana.uucp (Jim Mercer) (05/19/91)
In article <kyV422w163w@phoenix.com> stanley@phoenix.com (John Stanley) writes: > Like I said. The problem was not BITFTP. The problem is software >that happily attempts to scribble across a disk on which there is no >space. We would not accept this in any other application, especially an >unattended one, but we will accept this from uucico. > > Well, BITFTP has shut itself off. Disks will now be filled with human >generated mail. Fixing uucico would stop the problem at its root, but >no, the next thing to be dropped will be mail itself. Then newsgroups >will become too large, and those will be dropped. > > Unless you fix the uucico problem, you will never be rid of the >problem of filled disks. isn't this like saying "cars produce so much pollution, we neet to improve peoples lungs" ? -- [ Jim Mercer work: jim@lsuc.on.ca home: merce@iguana.uucp +1 519 570-3467 ] [ "Anarchists Unite!" - seen spray painted on a wall ]
stanley@phoenix.com (John Stanley) (05/19/91)
merce@iguana.uucp (Jim Mercer) writes: > In article <kyV422w163w@phoenix.com> stanley@phoenix.com (John Stanley) write > > Unless you fix the uucico problem, you will never be rid of the > >problem of filled disks. > > isn't this like saying "cars produce so much pollution, we neet to improve > peoples lungs" ? No. It is like saying that if you choose to suck on an exhaust pipe, don't bitch about the pollution you are breating.
stanley@phoenix.com (John Stanley) (05/19/91)
gws@xenitec.on.ca (Geoff Scully) writes: > Can and will are different things. Fixing uucico (umpteen different > versions from umpteen different vendors) Lsuc runs umpteen different versions? > Not that it is a bad idea, just that it does not solve > the immediate problem. Fixing YOUR copy of uucico WILL fix your problem. Adding a disk will NOT fix the problem, it just puts it off for a while. > Hahahaha. John, I don't know how much of a downstream you have, but for > sites like xenitec (with ~25 downstream) and lsuc (with ~75 downstream) > the idea of only running uucico under supervised conditions is absurd. If you choose to run software that has the proven ability to hose your disks, and you run it without supervision, they YOU have made the choice to accept the occasional hosing of your disks. YOU made that choice of your own free will. If YOU now decide that you don't like the decision you made, don't blame or punish the rest of us because YOU made the wrong decision. If you choose to point a gun to your head and pull the trigger, don't bitch about the person who loaded it. > > If you have a problem with the users of your system, take it up with > >them. Don't come out into the world and demand that everyone else give > >up what they have just because you can't afford to give it to your > >users. If you want THEM to pay their way, well, then, CHARGE THEM. With > >all the lawyers you must have floating around there, the legal issues > >certainly wouldn't be a problem. > > > > The point is not that we want to CHARGE them, but rather that we want > them to be respectful of the fact that we provide them with a service > WITHOUT CHARGING them. No one needs the headaches of administering the > accounting for this in addition to administering a mail hub. Fine. Don't charge them. That is YOUR choice. But if your users are a problem for you, YOU deal with THEM. Don't expect us to quietly suffer your failings. > >> email is for messaging, not file transfers. > > > > Email is for what the users email. When someone asks me, in mail, for > > There is a big difference between a list of cable freqs and ~60 MEG of > sources. The only difference is size. Don't claim that email isn't for file transfers and then say email is ok for file transfers. Be consistent. > Oh, and BTW, when you send a book to somebody, do you send it to > somebody 1/3 of the way and then ask them to pay the price in time and > stamps to have it continue its journey? Not likely. You send it directly > to the destination, paying the postage yourself. If you don't want to handle mail without charging for it, don't do it. If you want to drop replies from bitftp on the floor, do it. > >> > What will you do when someone posts a request for something and > >> >dozens of people mail it to him? > >> > >> again, email is for messaging, not file transfers. > > > > Respond to the question. People are already posting requests for > >files to be mailed to them as a direct result of you getting BITFTP shut > >off. What will you do when your spool fills up from people mailing files > >to each other? You are going to cut off mail. Then people will be asking > >for stuff to be posted. Blam! No more news. > > What a totally stupid and reactionist view this is. No, the stupid and reactionist view is to get BITFTP to stop providing a service just because you can't handle it. > You still operate > under the assumption that the user making such a request has any business > doing so. I made no such assumption. People ARE doing it. They will continue to do it. People will respond to those requests. It makes no difference whether they SHOULD be doing it, it will happen. What will YOU do when it causes YOU problems? We already know how you handle problems with your users asking for things from BITFTP -- you get BITFTP to stop accepting requests from anyone. > Jim did respond to the question. Sending large file transfers > over a store and forward email network is evil. Period. That is not an answer. The question is not if it is evil, it is how you will handle it when it DOES happen. Automobile accidents are evil things. Do you refuse to wear a seat belt or carry auto insurance because accidents are evil? > If I got such a > request (or found one from my downstream in the news), I would either > advise him that I had these files for him, or advise him as to where it > is available and tell him to establish a direct connect to the site that > has it. That's nice. That's what I would do, too. That is not what everyone would do. That is a fact. When I posted such a message telling someone where the software was, I got 100+k of mail from someone who decided that it was being nice to mail it to me without asking if I had already received it, much less if I wanted it. > > Your uucico hosed you while transferring BITFTP mail, so BITFTP is > >bad for everyone. That is a grand-daddy of over-generalizations. > > > > As Jim mentions below, BITFTP has hosed many more than just lsuc's spool, > and as a result, (admittedly only partially due to this), all of Ontario > is facing termination of our access to (free) Internet mail forwarding. Cry for Ontario. So now Ontario will have to pay for mail forwarding just like many other sites do. Why should I worry about what Ontario gets for free? You seem to be speaking for Ontario, and Ontario's opinion is that I should have to convince NASA to set up anonymous UUCP and that I should have to call them long distance to get the material I want from them. Well, tough titties for Ontario. When they change their opinion, maybe I will change mine. > It is not an over-generalization. All of our downstream will suffer when > this happens. When all UUCP sites are downstream from you, then it will not be an over-generalization. > Oh, and this access will still be cut off even though the > BITFTP server at princeton now does The Right Thing. It was abused and > now we will all pay for it reagardless. Don't forget, the reason the rest of us are paying is because Ontario couldn't handle it. > >pass the same thing twice or thrice is more than compensated for by all > >the things you won't have to carry AT ALL because they weren't posted. > > > > Bullshit. At some point in time, most everything that is available > *immediately* by FTP will be available *eventually* via the normal UseNet > distribution method. Bullshit. > The point is, if you want it *now*, you pay for it, > not me. When my mail from BITFTP starts to pass through your site, which is the only way you would be paying for my mail, then you have a complaint. Until then, don't complain about paying for carrying my mail when you don't. > If you are willing to wait, I am willing to dedicate resources on > my machine to bring it in (and in many cases archive it for anon-uucp) > via UseNet. God no. If everything available via anon-ftp were to show up in USENET, EVERYONE would be suffering. > For those things that don't make it to UseNet and are not > available any other way (anon-uucp, tapes, etc) all I can say is "Too > Bad." Ontario has what it wants, the rest of the world can take a hike. Great opinion. Makes Ontario look real friendly. > You are deprived of the *priviledge* of using that free software > because you can't get it. You do not have a *right* to have that > software, and you certainly don't have a right to have it at my expense. Since none of my mail of carried at your expense, you have no right to tell me I can't send it. > Oh, and for those people (like Peter) who complain about how much of a > hassle it is to set up direct connects to anon-uucp sites to do these > transfers, all I can say is, tuff luck. Yeah, you have already told us how little you care about anything outside your site. > Compare the cost of you doing this > to the cost of buying a router and leased line to an AlterNet (or equiv) > Point Of Presence and doing the FTP yourself. All I will say is that I > will not save you the time and money by spending my time and money. Unless you can provide proof that my mail is costing you anything, shut the hell up about how much money and time my mail is costing you. Or Peter da Silva's mail. Or anyone else's. If you have a problem with YOUR user's mail costing you time and money, then YOU deal with YOUR user's. > > When EVERY anonymous ftp site is also available via a mailserver, > >THEN you can argue that BITFTP is of NO service to UUCP. It will be a > >long time before that happens. Those who set up anon-ftp sites tend to > >think in terms of Internet and forget about anyone who can't ftp. > > > > There is a reason for this. Those who set up anon-ftp sites generally don't think about setting up anon-uucp connections, and that is probably because they are thinking of Internet and not UUCP or BITNET or anything else. It is also because some of them have rules about dialup lines. It is NOT because ftp is an internet only protocol, it is because they are on the internet and don't realize that there are other networks. > Get it straight once and for all. FTP IS AN > INTERNET SERVICE!!! IT WAS DESIGNED TO TRANSFER FILES BETWEEN DIRECTLY > CONNECTED HOSTS COMMUNICATING AT HIGH SPEED. IT WAS NOT DESIGNED TO BE > USED BY STORE AND FORWARD NETWORKS! PERIOD. Get this straight once and for all. FTP IS NOT BEING USED IN ANY STORE AND FORWARD NETWORKS. THAT IS THE PROBLEM THAT, UNTIL RECENTLY, BITFTP SOLVED. > At the point in time where even a sizable minority of anon-ftp sites > provide mail-servers, I will go out of my way to scan pass-through mail > traffic, perhaps even partially manually, You can't afford the time to watch your uucico to keep it from hosing your disks, but you can afford the time to read all the mail passing through to make sure it doesn't violate your sense of propriety. Go figure. > and ensure that any such > requests passing through me promptly hit the floor. That is your right. Do it now. That is the proper solution to the problem that you are having. The proper solution is not to screw up a service for everyone just because YOU can't handle it. > >> talk to the sites in Ontario, Canada, who are possibly going to lose all > >> internet connectivity partially due to increased mail volume (ie. BITFTP). > > > > And just how is BITFTP going to increase your mail volume when it no > >longer accepts mail requests? Or is this your threat for when human > >generated mail fills your spool? If I were one of these sites I would > >start looking for another feed right now, because you have already > >indicated that you aren't happy carrying their mail and are looking for > >the next available excuse to cut it totally. > > > > He never said he didn't want to carry their mail, he said he is unwilling > to have their 60Mb file transfers trashing his file systems and wasting 3 > days of his time. He chose to run software that is a known disk hoser. > Human generated *MAIL* will NEVER fill my spool, Never? > short > of some idiot mailbombing a user here or downstream of me. A useful statement. Mail will never fill my spool unless mail fills my spool. If you had a uucico that would stop accepting things when the spool got close to full, you could THEN say that human generated mail will NEVER fill your spool, without any qualifications. > That problem > can be quickly solved with a phone call to the offending site's upstream > admin. Your spool will be cleaned up by calling another site's admin? What is he going to do, dial into your system and clean it up for you?
peter@ficc.ferranti.com (Peter da Silva) (05/19/91)
gws@xenitec.on.ca (Geoff Scully) writes: > Oh, and for those people (like Peter) who complain about how much of a > hassle it is to set up direct connects to anon-uucp sites to do these > transfers, all I can say is, tuff luck. I'm not complaining. I'm explaining. I mail floppies and stamps and wait for the post office as often as not, simply because it's most convenient. People *will* do the convenient thing. I'm trying to show how the convenient thing can be made the right thing to do. Think of it as the moral equivalent of pushing for more recycling centers. If people have to drive 20 miles to recycle their milk jugs, they'll toss them in the trash. If people have to go through hassles to get files from anonymous-uucp, they'll use mail servers. If they can set up *one* script for *one* site, either with a 900 number or a service agreement, and type: uux - uunet!rftp ~/from-uunet OPEN sprite.berekeley.edu CD ~ftp GET mx.tar.Z QUIT ^D whenever they want a file, they'll do that instead of mail BITFTP@PRINCETON.EDU PATH yoursite!yourname OPEN sprite.berekeley.edu CD ~ftp GET mx.tar.Z QUIT ^D It's just as easy to set up and way more convenient to unpack. -- Peter da Silva; Ferranti International Controls Corporation; +1 713 274 5180; Sugar Land, TX 77487-5012; `-_-' "Have you hugged your wolf, today?"
gws@xenitec.on.ca (Geoff Scully) (05/20/91)
In article <TaF723w163w@phoenix.com> stanley@phoenix.com (John Stanley) writes: >gws@xenitec.on.ca (Geoff Scully) writes: > >> Can and will are different things. Fixing uucico (umpteen different >> versions from umpteen different vendors) > > Lsuc runs umpteen different versions? > No, but as has been pointed out many times now, the problem is net-wide and not unique to lsuc. >> Not that it is a bad idea, just that it does not solve >> the immediate problem. > > Fixing YOUR copy of uucico WILL fix your problem. Adding a disk will >NOT fix the problem, it just puts it off for a while. > Perhpas you don't realize this (running a PC and WAFFLE, for which you likely have source), but most sites do not have sources to uucico. Trying to convince a vendor that this needs fixing should be but is not always an easy thing to do. My immediate problem is not uucico. Mine works. My immediate problem is email abuse and the network wide problem it is causing. You continue to miss the distinction after it has been pointed out to you my multiple posters. >> Hahahaha. John, I don't know how much of a downstream you have, but for >> sites like xenitec (with ~25 downstream) and lsuc (with ~75 downstream) >> the idea of only running uucico under supervised conditions is absurd. > > If you choose to run software that has the proven ability to hose your >disks, and you run it without supervision, they YOU have made the choice >to accept the occasional hosing of your disks. YOU made that choice >of your own free will. If YOU now decide that you don't like the decision >you made, don't blame or punish the rest of us because YOU made the wrong >decision. > > If you choose to point a gun to your head and pull the trigger, don't >bitch about the person who loaded it. > You show a serious lack of understanding about what it means to run a site with *ANY* downstream, which is not surprising since your map entry shows you to have none (or maybe 1, I can't find an entry for syrgrp in the maps; Nice map entry too, incorrectly formatted, and of course, protecting your anonimity should anyone grow tired of your inane attitude). The problem has nothing to do with uucico writing on a full disk, but rather with what fills that disk. Since you seem to like analogy so much, how about if you know your car is built to protect your life in all cases except when hit by another car moving more than 55MPH, would you try to educate people not to speed or would you bitch at your auto manufacturer for not making your car safer? >> The point is not that we want to CHARGE them, but rather that we want >> them to be respectful of the fact that we provide them with a service >> WITHOUT CHARGING them. No one needs the headaches of administering the >> accounting for this in addition to administering a mail hub. > > Fine. Don't charge them. That is YOUR choice. But if your users are >a problem for you, YOU deal with THEM. Don't expect us to quietly suffer >your failings. > I don't have any failing here. I don't have a problem with my users. Many other admins I speak to regularly do, and they do take care of them. I have not inflicted any suffering on you or anybody else. >> >> email is for messaging, not file transfers. >> > >> > Email is for what the users email. When someone asks me, in mail, for >> >> There is a big difference between a list of cable freqs and ~60 MEG of >> sources. > > The only difference is size. Don't claim that email isn't for file >transfers and then say email is ok for file transfers. Be consistent. > The question at hand is one of respect for the time and resources of upstream admins. Sending a small list of cable freqs that happened to originate in a file is not going to bother any admin. The reason that people are starting to ignore the distinction is because of idiots like you who claim that if it is ok to send a small file, then all files are ok. I am being consistent. I am consistently amazed at your lack of respect for other peoples resources. >> Oh, and BTW, when you send a book to somebody, do you send it to >> somebody 1/3 of the way and then ask them to pay the price in time and >> stamps to have it continue its journey? Not likely. You send it directly >> to the destination, paying the postage yourself. > > If you don't want to handle mail without charging for it, don't >do it. If you want to drop replies from bitftp on the floor, do it. > Nice evasion of the question. It has nothing to do with me. I ask the question again. If I were to agree to handle your mail (read: MAIL) for free, would you be so discourteous as to send me a book? >> >> > What will you do when someone posts a request for something and >> >> >dozens of people mail it to him? >> >> >> >> again, email is for messaging, not file transfers. >> > >> > Respond to the question. People are already posting requests for >> >files to be mailed to them as a direct result of you getting BITFTP shut >> >off. What will you do when your spool fills up from people mailing files >> >to each other? You are going to cut off mail. Then people will be asking >> >for stuff to be posted. Blam! No more news. >> >> What a totally stupid and reactionist view this is. > > No, the stupid and reactionist view is to get BITFTP to stop providing >a service just because you can't handle it. > BITFTP still provides service, it just doesn't provide it to YOU, someone who had no business using it in the first place. Jim did not single handedly get BITFTP shut down. Nobody "got" BITFTP shut down. From what I know, Princeton took action on their own inititive, coincidently the day after Jim's initial posting. This problem has been building for years, growing in magnitude with every occurrence. The people at Princeton evidently got tired of hearing about the problem and decided to put the BIT back into BITFTP. >> You still operate >> under the assumption that the user making such a request has any business >> doing so. > > I made no such assumption. People ARE doing it. They will continue >to do it. People will respond to those requests. It makes no difference >whether they SHOULD be doing it, it will happen. What will YOU do when >it causes YOU problems? We already know how you handle problems with >your users asking for things from BITFTP -- you get BITFTP to stop >accepting requests from anyone. > As I said above, niether I or anyone else I am aware of was responible for you losing your free lunch. People are out there raping women all the time. Does this mean that because none of my female loved ones have been raped that I should not speak out against it? >> Jim did respond to the question. Sending large file transfers >> over a store and forward email network is evil. Period. > > That is not an answer. The question is not if it is evil, it is how >you will handle it when it DOES happen. Automobile accidents are evil >things. Do you refuse to wear a seat belt or carry auto insurance because >accidents are evil? > No, I do these things, but I also operate under the assumption that no one is going to intentionally ram me head on. Yes, it may happen, but I certainly don't take it as a given. >> If I got such a >> request (or found one from my downstream in the news), I would either >> advise him that I had these files for him, or advise him as to where it >> is available and tell him to establish a direct connect to the site that >> has it. > > That's nice. That's what I would do, too. That is not what everyone >would do. That is a fact. When I posted such a message telling someone >where the software was, I got 100+k of mail from someone who decided >that it was being nice to mail it to me without asking if I had already >received it, much less if I wanted it. > As you seem to be fond of pointing out, that's your problem. But it would seem to give you an interest in educating users not to send files by email. Somehow I doubt you will agree with that. :-) >> > Your uucico hosed you while transferring BITFTP mail, so BITFTP is >> >bad for everyone. That is a grand-daddy of over-generalizations. >> > >> >> As Jim mentions below, BITFTP has hosed many more than just lsuc's spool, >> and as a result, (admittedly only partially due to this), all of Ontario >> is facing termination of our access to (free) Internet mail forwarding. > > Cry for Ontario. So now Ontario will have to pay for mail forwarding >just like many other sites do. Why should I worry about what Ontario >gets for free? You seem to be speaking for Ontario, and Ontario's >opinion is that I should have to convince NASA to set up anonymous UUCP >and that I should have to call them long distance to get the material I >want from them. Well, tough titties for Ontario. When they change their >opinion, maybe I will change mine. > They will not change their opinion because they are not in business to service your every whim and desire. If they choose to not provide anon-uucp that is their choice and your tuff luck. If you are not on the internet and can't find alternative methods, you lose. What do I care about that? Do you really think that the rest of the world computer community at large owes you whatever you may desire, regardless of how much of their time and money is involved? >> Oh, and this access will still be cut off even though the >> BITFTP server at princeton now does The Right Thing. It was abused and >> now we will all pay for it reagardless. > > Don't forget, the reason the rest of us are paying is because Ontario >couldn't handle it. > Wake up. It is not because of Ontario's or anybody elses problems that you (and everybody else) have lost their free ftp lunch. It is a constant pattern of abuse, which you seem to advocate, which caused the service to be restriced back to the people who are paying for it and for whom it was originally intended to serve. >> >pass the same thing twice or thrice is more than compensated for by all >> >the things you won't have to carry AT ALL because they weren't posted. >> > >> >> Bullshit. At some point in time, most everything that is available >> *immediately* by FTP will be available *eventually* via the normal UseNet >> distribution method. > > Bullshit. > >> The point is, if you want it *now*, you pay for it, >> not me. > > When my mail from BITFTP starts to pass through your site, which is >the only way you would be paying for my mail, then you have a complaint. >Until then, don't complain about paying for carrying my mail when you >don't. > That was the generic "me" I was using. Obviously I was not clear enough for your blinkered field of vision. Let me rephrase. If x user on a machine not directly connected to the internet wants to get some source *now*, x user can pay for it (not pay *ME*, or his upstream admins, for it but pay for it himself, with his machine, his modem, his phone bill and his time). >> For those things that don't make it to UseNet and are not >> available any other way (anon-uucp, tapes, etc) all I can say is "Too >> Bad." > > Ontario has what it wants, the rest of the world can take a hike. Great >opinion. Makes Ontario look real friendly. > You are looking for nice safe easy scapegoat to crap on about losing your free access to ftp, and so you choose to dump on Ontario. As has been pointed out many times now, Ontario is not responsible for your loss, and yet you choose to make snide comments. Makes you look real friendly. >> You are deprived of the *priviledge* of using that free software >> because you can't get it. You do not have a *right* to have that >> software, and you certainly don't have a right to have it at my expense. > > Since none of my mail of carried at your expense, you have no right >to tell me I can't send it. > The generic "my" again. Even after seeing it used this way multiple times you still don't figure it out. >> Oh, and for those people (like Peter) who complain about how much of a >> hassle it is to set up direct connects to anon-uucp sites to do these >> transfers, all I can say is, tuff luck. > > Yeah, you have already told us how little you care about anything >outside your site. > What I have told you is how little I care about assholes who think that mail hubs like mine and Jim's are in business to service the every whim and desire of sites downstream of them. In fact I care a great deal about the net as a whole, and consider people with attitudes like yours to be a threat to that. >> Compare the cost of you doing this >> to the cost of buying a router and leased line to an AlterNet (or equiv) >> Point Of Presence and doing the FTP yourself. All I will say is that I >> will not save you the time and money by spending my time and money. > > Unless you can provide proof that my mail is costing you anything, >shut the hell up about how much money and time my mail is costing you. >Or Peter da Silva's mail. Or anyone else's. If you have a problem with >YOUR user's mail costing you time and money, then YOU deal with YOUR >user's. > I won't even comment on this again. That was a generic "my" and a generic "you" again. My user's mail costs me next to nothing in terms of time and money, and as I said above, I don't have a problem with users doing huge file transfers. I was refering to a general, recurring net-wide problem, not to my specific site. >> > When EVERY anonymous ftp site is also available via a mailserver, >> >THEN you can argue that BITFTP is of NO service to UUCP. It will be a >> >long time before that happens. Those who set up anon-ftp sites tend to >> >think in terms of Internet and forget about anyone who can't ftp. >> > >> >> There is a reason for this. > > Those who set up anon-ftp sites generally don't think about setting >up anon-uucp connections, and that is probably because they are thinking >of Internet and not UUCP or BITNET or anything else. It is also because >some of them have rules about dialup lines. It is NOT because ftp is an >internet only protocol, it is because they are on the internet and don't >realize that there are other networks. > I can't possibly believe that you really expect anybody to buy this load of bullshit. The reason that they are thinking internet when they set up ftp is because ftp is an internet protocol. The reason they *don't* think of other networks and protocols are many and varied, and you point out some of them. Another would be to avoid having to deal with idiots like you. Send me a note sometime telling me how it is that you manage to know so much about what Internet admins think about when setting up ftp, when you clearly have no experience in this relm. I don't either, BTW, but I don't presume to second guess their motivations or reasoning, or demand that they set up services to serve me when they may have neither the resources or desire to do so. >> Get it straight once and for all. FTP IS AN >> INTERNET SERVICE!!! IT WAS DESIGNED TO TRANSFER FILES BETWEEN DIRECTLY >> CONNECTED HOSTS COMMUNICATING AT HIGH SPEED. IT WAS NOT DESIGNED TO BE >> USED BY STORE AND FORWARD NETWORKS! PERIOD. > > Get this straight once and for all. FTP IS NOT BEING USED IN ANY STORE >AND FORWARD NETWORKS. THAT IS THE PROBLEM THAT, UNTIL RECENTLY, BITFTP >SOLVED. > That was my point. BITFTP provided a way to use FTP on a store and forward network, without regard to the costs incurred by the storing sites. FTP on the internet does not have this problem as it goes directly from source to destination. In solving the the problem of not being able to use FTP from a site not on the internet, it created a whole new set of problems, and hence was not a viable solution. Other solutions have been proposed here which would solve these problems while respecting the wishes of the admins of resources used along the way. >> Human generated *MAIL* will NEVER fill my spool, > > Never? > >> short >> of some idiot mailbombing a user here or downstream of me. > > A useful statement. Mail will never fill my spool unless mail fills >my spool. If you had a uucico that would stop accepting things when the >spool got close to full, you could THEN say that human generated mail >will NEVER fill your spool, without any qualifications. > A useful statement. Mail will never fill my spool unless some idiot goes out of his way to fill it. My uucico *does* stop when full. This does not change the fact that it was an idiot who filled it, nor does it change the fact that those people who request file tranfers that fill my spool without checking with me first to see if I have alternatives are idiots. I have allocated sufficient mail spool to handle 200+% normal mail traffic for all of my downstream. If it fills, it is becuase of abuse. How uucico reacts to that abuse it incidental to the fact of abuse. It is the abuse I am trying to stop. Fixing uucico does not address this problem. >> That problem >> can be quickly solved with a phone call to the offending site's upstream >> admin. > > Your spool will be cleaned up by calling another site's admin? What is >he going to do, dial into your system and clean it up for you? No, but I have found that net.courtesy provides for upstream admins removing connectivity for abusers. It prevents recurrence of the problem in most cases. If a reckless driver smashes into me, I cannot change the fact that my car and perhaps myself will be injured, however I will I try to make damn sure that it is a long time before the other driver gets back on the road. --g --- Geoff Scully Support Services -- XeniTec Consulting Services Internet: gws@xenitec.on.ca UUCP: ..!{uunet!}watmath!xenitec!gws "We need to look at what we owe each other, rather than what we can make off each other." Bob Rae, National Disaster Party, Ontario Premier elect. 09/06/90
emv@ox.com (Ed Vielmetti) (05/20/91)
Peter da Silva writes:
If they can set up *one* script for *one* site, either with a 900 number or
a service agreement, and type:
Are you insisting on BITFTP compatibility, or would that just be one
preferred option? I know there are lots of scripts around that know
how to deal with that...
uux - uunet!rftp ~/from-uunet
Aw, just for the sake of argument make that
uux - msen!rftp ~/from-msen
and let's wrap some stuff around it so it's a one-liner:
ftpget msen wilma.cs.brown.edu:/pub/xmx.tar.Z ~/from-msen
i.e.
ftpget service-provider host:/path/to/sources destination-directory
Write a shell script so that you can pipe comp.archives articles
into it and the sources come back at you, and I think everyone would
be reasonably happy. Naturally, you'd replace "msen" with "uunet" or
"uupsi" or "kremvax" depending on who's providing the service and how
much it costs. And also naturally there would be an interface to the
raw "OPEN, CD, GET" commands if you're dealing with a sufficiently
goofy remote system that expressing things in terms of one-liners is
not adequate to the task.
--Ed
emv@msen.comlyndon@cs.athabascau.ca (Lyndon Nerenberg) (05/20/91)
stanley@phoenix.com (John Stanley) writes: >gws@xenitec.on.ca (Geoff Scully) writes: >> Can and will are different things. Fixing uucico (umpteen different >> versions from umpteen different vendors) > Lsuc runs umpteen different versions? > Fixing YOUR copy of uucico WILL fix your problem. Adding a disk will >NOT fix the problem, it just puts it off for a while. [ Lots 'o drivel deleted ] > A useful statement. Mail will never fill my spool unless mail fills >my spool. If you had a uucico that would stop accepting things when the >spool got close to full, you could THEN say that human generated mail >will NEVER fill your spool, without any qualifications. John, what version of UUCP do you run? It's obviously very different from the version the rest of us run. Please tell me, in detail, how the uucico at your end knows whether or not it has enough room for an incoming file. Describe the protocol negotiations that take place between the two systems to pass such information as the size of the file about to be transferred, and the amount of space available at the receiving end. What was the name of that protocol? It sure as hell wasn't g, or f, or t, or x, or e. Most versions of uucico will refuse an incoming transfer if the amount of space (or the number of free inodes) in the uucp spool directory's filesystem is below a certain threshold (said threshold being compiled in to uucico). That's it. What is so magic about your version of uucico that it doesn't have this behaviour? And why don't you share the code with us? It would be a Good Thing to have a uucp protocol that would pass along things like the size of the file it's about to send. This would allow the receiver to determine if it can infact receive the entire file without running out of resources. Of course it wouldn't be foolproof, since you can have more than one uucico going at a time, and all of them could be receiving 9 MB files into a partition with 15 MB of free space. Of course, this new protocol will only work if both ends speak it. Since none of the machines lsuc talks to (well, maybe there is one) run the same system, you are suddenly faced with the prospect of porting to other architectures. You're argument that fixing uucico on lsuc will solve the worlds problems is utter nonsense. -- Lyndon Nerenberg VE6BBM / Computing Services / Athabasca University atha!cs.athabascau.ca!lyndon || lyndon@cs.athabascau.ca Packet: ve6bbm@ve6mc.ab.can.noam The only thing open about OSF is their mouth. --Chuck Musciano
stanley@phoenix.com (John Stanley) (05/20/91)
paul@frcs.UUCP (Paul Nash) writes: > As one of those with a long-distance (trans-Atlantic) telephone, and > attendant bill (that comes out of my private and personal pocket :-(), > I can only agree. This problem has caused me to turn off mail forwarding > to other sites, so that they can't get _any_ mail via my link, because > of a few megabytes (and $1000's) of FTP stuff that was spewed over > my phone. This is the proper solution. If you cannot afford it, and cannot get your users to stop, don't do it. > As it is, a few bad-mannered people > have spoiled it for everyone. This makes _me_ feel guilty, but it's > the only way to cope with a bad-mannered bank-manager. Just don't let those few bad-mannered users of YOUR system spoil it for everyone who doesn't use your system. gcs@polari.UUCP (Greg Sheppard) writes: > I wrote: >> If you don't want to be a mail server, then stop doing it. If you don't >>want to carry mail to or from bitftp, don't do it. If you can't handle the >>traffic, then get out of the kitchen. Don't demand that the world stop >>just because you want off. > > This seems like a pretty reasonable response. Maybe some constructive > solution for the uucp camp might be proposed. The simplest solution to the problem is to filter out all upstream mail to known mail servers. This is trivial to do, and all it takes is a simple script that runs before uucico is executed to scan the mail spool. If you want to make doubly sure you kill it all, grep all mail after uucico runs for From: known mail servers. This could be done in perl very easily. It could be made to look for common automatic splitting formats, or for UUENCODED files. You could have it kill any file bigger than X k. If you have users to whom you want to grant BITFTP privileges, you can check for them and let them through. While killing files going downstream doesn't keep the spool from filling up, it does make it harder for someone to find new and unique ways around the upstream killer. The upstream killer is the main protection: if he can't ask for it, it won't be sent. If you want to get fancier, write something that bounces the request back to the user. Tell the user why it was bounced, and if it was bounced in error to send mail back to you to let you know (so you can fine tune the script). If I get the inclination, and if I thought it would help get BITFTP turned back on, I would write the first version of this perl script. I couldn't guarantee that it would work everywhere (the UUCP here is not standard) it would be close (I hope). If you don't have perl, it is available for anonymous ftp from .... Oops. If you don't have perl, you should get it.
gws@xenitec.on.ca (Geoff Scully) (05/20/91)
In article <I=EBILB@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >gws@xenitec.on.ca (Geoff Scully) writes: >> Oh, and for those people (like Peter) who complain about how much of a >> hassle it is to set up direct connects to anon-uucp sites to do these >> transfers, all I can say is, tuff luck. > >I'm not complaining. I'm explaining. > I grant the distinction. I really was not trying to pick on you personally Peter, but just happened to remember your name anong those who stated (often correctly) that setting up connects to anon-uucp sites is a hassle. Perhaps I just had too much of other people's "I don't want to be hassled, I have a right to have it handed to me" attitude. >People *will* do the convenient thing. I'm trying to show how the convenient >thing can be made the right thing to do. Think of it as the moral equivalent >of pushing for more recycling centers. If people have to drive 20 miles to >recycle their milk jugs, they'll toss them in the trash. If people have to >go through hassles to get files from anonymous-uucp, they'll use mail servers. >If they can set up *one* script for *one* site, either with a 900 number or >a service agreement, and type: > > [rftp stuff] > >whenever they want a file, they'll do that instead of > > [BITFTP stuff] > >It's just as easy to set up and way more convenient to unpack. You bet. Just to clear something up for those of you who think I am of the "Don't you dare read a file into mail!" attitude, I have no problem with 1 hop from the internet transfers like this, where it is known in advance by the upstream admin that this will happen. My problem is with mailservers and things like BITFTP which send files over multiple hop connections, where the admins in line may not be prepared or willing to accept such large volumes. I agree that your ideas and others proposed here provide for acceptable alternatives to the BITFTP problems. --- Geoff Scully Support Services -- XeniTec Consulting Services Internet: gws@xenitec.on.ca UUCP: ..!{uunet!}watmath!xenitec!gws "We need to look at what we owe each other, rather than what we can make off each other." Bob Rae, National Disaster Party, Ontario Premier elect. 09/06/90
peter@ficc.ferranti.com (Peter da Silva) (05/21/91)
In article <EMV.91May19170420@poe.aa.ox.com> emv@ox.com (Ed Vielmetti) writes: > Peter da Silva writes: > If they can set up *one* script for *one* site, either with a 900 number or > a service agreement, and type: > Are you insisting on BITFTP compatibility, or would that just be one > preferred option? I don't care about the interface, as long as it lets me do the same things. I don't want to depend on the rftp server having up-to-date archives, or on the source I want being on an "official" archive site. > And also naturally there would be an interface to the > raw "OPEN, CD, GET" commands if you're dealing with a sufficiently > goofy remote system that expressing things in terms of one-liners is > not adequate to the task. Like SIMTEL? Or does rftp know about SIMTEL's <> stuff in your model? -- Peter da Silva; Ferranti International Controls Corporation; +1 713 274 5180; Sugar Land, TX 77487-5012; `-_-' "Have you hugged your wolf, today?"
merce@iguana.uucp (Jim Mercer) (05/21/91)
In article <PkD921w163w@phoenix.com> stanley@phoenix.com (John Stanley) writes: >paul@frcs.UUCP (Paul Nash) writes: > >> As one of those with a long-distance (trans-Atlantic) telephone, and >> attendant bill (that comes out of my private and personal pocket :-(), >> I can only agree. This problem has caused me to turn off mail forwarding >> to other sites, so that they can't get _any_ mail via my link, because >> of a few megabytes (and $1000's) of FTP stuff that was spewed over >> my phone. > > This is the proper solution. If you cannot afford it, and cannot >get your users to stop, don't do it. > >> As it is, a few bad-mannered people >> have spoiled it for everyone. This makes _me_ feel guilty, but it's >> the only way to cope with a bad-mannered bank-manager. > > Just don't let those few bad-mannered users of YOUR system spoil >it for everyone who doesn't use your system. you miss the point. everyone lost because of a few bad-mannered users on his neighbor's systems. before the abuse, he was willing to let modest amounts of transatlantic mail flow. then some boneheads decided they HAD TO HAVE that stuff from across the pond, and as a result, they connection was shut down to outside use. Mr. Nash was participating in what would now be considered a "classic USENET" role. he had resources, and he allowed the net at large to use them within his constraints. now that is gone. Mr. Stanley, please remember that a larger portion of uucpNET is run using other people's resources which are given as a public service. not everyone has to pay to be a member of USENET, and as a result they can live with the restrictions placed on them. your right to bitch about traffic stops when it leaves PSI. when your service is impeded, you can only yell at PSI. >gcs@polari.UUCP (Greg Sheppard) writes: > >> I wrote: >>> If you don't want to be a mail server, then stop doing it. If you don't >>>want to carry mail to or from bitftp, don't do it. If you can't handle the >>>traffic, then get out of the kitchen. Don't demand that the world stop >>>just because you want off. >> >> This seems like a pretty reasonable response. Maybe some constructive >> solution for the uucp camp might be proposed. > > The simplest solution to the problem is to filter out all upstream >mail to known mail servers. This is trivial to do, and all it takes is a >simple script that runs before uucico is executed to scan the mail >spool. If you want to make doubly sure you kill it all, grep all mail >after uucico runs for From: known mail servers. another example of your total lack of understanding of the operation of a mail hub. we have 9 modems, X.25 and direct links which can all be concurrently active. trivial to you is not trivial to us. this would also add processing cycles, which could be more effectively used in doing work for the organization that is paying for the resources. remember, most hubs are not in the business of providing mail routing, they do it as a public service. to be nice to the community at large. > While killing files going downstream doesn't keep the spool from >filling up, it does make it harder for someone to find new and unique >ways around the upstream killer. The upstream killer is the main >protection: if he can't ask for it, it won't be sent. if he doesn't ask for it (or can't) it won't be sent. > If I get the inclination, and if I thought it would help get BITFTP >turned back on, I would write the first version of this perl script. I >couldn't guarantee that it would work everywhere (the UUCP here is not >standard) it would be close (I hope). If you don't have perl, it is >available for anonymous ftp from .... Oops. If you don't have perl, you >should get it. and what if perl won't run on your system? yes it is possible there are systems out there who can't run perl (for various reasons). again, you illustrate your ignorance of the environment you are trying to fix. the UUCP you are running, as i understand from a posting referencing your map entry, is WAFFLE on an MS-DOS machine. hmmmm..... how many down stream sites do you have? what speed is your modem? is your system running 24 hr's a day? how much space do you have allocated for uucp/news? don't talk like a sysadmin, if you don't know what you are talking about. [ BTW: WAFFLE, in my experience, the best uucp suite on MS-DOS machines ] -- [ Jim Mercer work: jim@lsuc.on.ca home: merce@iguana.uucp +1 519 570-3467 ] [ "Clickity-Click, Barba-Trick" - The Barbapapas ]
emv@msen.com (Ed Vielmetti) (05/21/91)
In article <OZFBHU5@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: > And also naturally there would be an interface to the > raw "OPEN, CD, GET" commands if you're dealing with a sufficiently > goofy remote system that expressing things in terms of one-liners is > not adequate to the task. Like SIMTEL? Or does rftp know about SIMTEL's <> stuff in your model? my model rftp knows about simtel20 and its syntax, also it knows about the half dozen IBM VM systems on the net that don't have a proper way to fetch files out of subdirectories from the initial prompt. e.g. nis.nsf.net, where a single GET command doesn't work, you have to CD and GET. Just a few special cases, FTP'ing is generally predictable and standard enough to work well without much prior knowlege of the remote site. this rftp would also know that 99 44/100% of what's on simtel (behind horrible syntax and MILNET gateways) also lives on wuarchive.wustl.edu and whatever other official shadow archive systems there are for it. thus the Australian version of it would point to all of local Australian caches. --Ed
paul@frcs.UUCP (Paul Nash) (05/21/91)
Thus spake stanley@phoenix.com (John Stanley): > paul@frcs.UUCP (Paul Nash) writes: > > > > As it is, a few bad-mannered people > > have spoiled it for everyone. This makes _me_ feel guilty, but it's > > the only way to cope with a bad-mannered bank-manager. > > Just don't let those few bad-mannered users of YOUR system spoil > it for everyone who doesn't use your system. Whoa there! These are not users of _my_ system -- if they were, I wouldn't have a problem, 'cos I would be able to break their heads open. The problem is (a very few) users at _downstream_ sites, who route mail through me, and also request big FTP's without asking me if it's OK, or if they can contribute to my phone bill. My feelings are quite simple. I used to use BITFTP a certain amount, but at least _I_ paid the bill for the international link. If it is _really_ that important to anyone to get a specific file in such a hurry, why can't _they_ pay for the long-distance call, and call to uunet's 900 number (or something similar). If it isn't important enough for them to pay for it themselves, they should get someone who has FTP access to dump whatever it is onto a tape and mail it, snail-mail. While I did not call for BITFTP to die, I don't mourn its passing. However, the damage has been done, and a bunch of machines now get mail via an erratic alternative path, or has their mail dropped on the floor :-(. This is not the fault of most of the users of those machines, but is the fault of a few greedy fuckwits. If BITFTP had stayed alive, they would probably have overloaded their alternative link, lost that aswell, and lost _all_ contact with the outside world. While this is not enough reason, _in_ _itself_ for BITFTP to die, it would seem from the discussion here that there are enough sites who are affected for it to be worth a collective whole. Those who think that unlimited access is a good thing should just get a link to a BITNET machine. This will allow them to use BITFTP to their hearts' content. It will probably be expensive, but there's no such thing as a free lunch. ---=---=---=---=---=---=---=---=---=---=---=---=---=---=---=---=---=--- Paul Nash Free Range Computer Systems cc paul@frcs.UUCP ...!uunet!m2xenix!frcs!paul
peter@ficc.ferranti.com (Peter da Silva) (05/21/91)
In article <EMV.91May20155300@crane.aa.ox.com> emv@msen.com (Ed Vielmetti) writes: > my model rftp knows about simtel20 and its syntax, also it knows about > the half dozen IBM VM systems on the net that don't have a proper way > to fetch files out of subdirectories from the initial prompt. Sounds great. When do you expect to ship? -- Peter da Silva; Ferranti International Controls Corporation; +1 713 274 5180; Sugar Land, TX 77487-5012; `-_-' "Have you hugged your wolf, today?"
emv@msen.com (Ed Vielmetti) (05/21/91)
In article <X1GBR5F@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: > my model rftp... Sounds great. When do you expect to ship? In time for X11R5. Or as soon as some other internet service provider beats me to it and does it themselves; I'd recommend contacting your existing feed(s) directly and mention how happy you'd be to have a nice remote ftp facility and a full-text search interface to comp.archives. Presumably anyone with a wet piece of string connecting them to the internet could do this right now. If the 'rftp' design is proper, you could even be a hop or two off the internet and still offer the service as long as you have an 'rftp' link to an upstream site that's on the net. Given a reasonable caching model, and prefetching stuff into the cache that's mentioned in comp.archives, you'd be in real good shape. Make the links quick enough and disk space cheap enough and comp.archives turns into something very much like a comp.sources group. -- Edward Vielmetti moderator, comp.archives emv@msen.com
bdb@becker.UUCP (Bruce D. Becker) (05/21/91)
In article <kyV422w163w@phoenix.com> stanley@phoenix.com (John Stanley) writes: |[...] | Like I said. The problem was not BITFTP. The problem is software |that happily attempts to scribble across a disk on which there is no |space. We would not accept this in any other application, especially an |unattended one, but we will accept this from uucico. | | Well, BITFTP has shut itself off. Disks will now be filled with human |generated mail. Fixing uucico would stop the problem at its root, but |no, the next thing to be dropped will be mail itself. Then newsgroups |will become too large, and those will be dropped. | | Unless you fix the uucico problem, you will never be rid of the |problem of filled disks. I use a program which monitors spools space & inodes, and shuts off uucico or uuxqt if the level goes too low. It uses a shell script as part of its structure so that it can be invoked with different parameters depending on the login name or the system name, whichever is appropriate in the given context. Used carefully, it provides a kind of large- granularity type of flow control with respect to news and email throughput, which seems more useful than C news' approach of throwing away incoming stuff if there isn't room. -- ,u, Bruce Becker Toronto, Ontario a /i/ Internet: bdb@becker.UUCP, bruce@gpu.utcs.toronto.edu `\o\-e UUCP: ...!utai!mnetor!becker!bdb _< /_ "It's the death of the net as we know it (and I feel fine)" - R.A.M.
mrm@sceard.Sceard.COM (M.R.Murphy) (05/21/91)
In article <1991May20.182222.16345@iguana.uucp> merce@iguana.uucp (Jim Mercer) writes: >don't talk like a sysadmin, if you don't know what you are talking about. It would seem that more heat than light is being generated in this discussion. I'll try for light rather than heat. I suggest we look at the problem from a different perspective. Rather than joeuser making an abusive request of an MBAS, look at the problem as an MBAS abuse of the net. The MBAS makes abusive demands on noncooperative downstream sites. A zeroth level solution is for the MBAS to pull the plug. (Hi Princeton:-). A first level solution would be to have the MBAS check the return path for a request for someting like MBASsite!cooperating_site_or_path!requestingsite!joeuser where "cooperating_site_or_path" might be "uunet" or "uunet!reallybigsite". That would be pretty easy. It could use software that already exists (pathalias, smail2.5), and it would be fast. If the path to the requestor is no good, then don't allow the request or only allow small stuff. A site could certainly send an E-mail message to an MBAS saying that it would cooperate. That could be verified by telephone, registered mail, or DNA typing for you Phorgery Phreaks out there :-) It is easier to deal with an offending MBAS than with the vast morass of us joeusers. -- Mike Murphy mrm@Sceard.COM ucsd!sceard!mrm +1 619 598 5874
clewis@ferret.ocunix.on.ca (Chris Lewis) (05/22/91)
In article <103410@becker.UUCP> bdb@becker.UUCP (Bruce D. Becker) writes: >In article <kyV422w163w@phoenix.com> stanley@phoenix.com (John Stanley) writes: >|[...] >| Like I said. The problem was not BITFTP. The problem is software >|that happily attempts to scribble across a disk on which there is no >|space. We would not accept this in any other application, especially an >|unattended one, but we will accept this from uucico. > I use a program which monitors spools space & > inodes, and shuts off uucico or uuxqt if the > level goes too low. It uses a shell script as > part of its structure so that it can be invoked > with different parameters depending on the login > name or the system name, whichever is appropriate > in the given context. > Used carefully, it provides a kind of large- > granularity type of flow control with respect > to news and email throughput, which seems more > useful than C news' approach of throwing away > incoming stuff if there isn't room. Lsuc has one of these too. When I was last working on it (it may have been worked on since), I made a concious decision to not simply shut off uucico completely when the disk space went below the thresholds. Instead, "spoolfull" disables (and kills if necessary) uucicos that are likely to be bringing *in* lots of stuff. Ie: the incoming main feed (attcan) and a couple of other sites (utzoo being one. Becker was for a while - may still be, can't remember whether I disabled that). When the diskspace becomes available again, it automatically reenables uucico. The idea being that other sites (particularly outgoing news feeds) should remain enabled because they are taking stuff *off* lsuc, and if I disabled all uucico's, then it might never turn itself back on, and everything would stall out indefinately. (Jim was new to news at the time, and Dave wasn't doing it anymore, so I thought it should be as automatic as possible). (There are other issues, such as uucp between internal lsuc machines, and ordinary mail that made turning uucico completely off impractical) This can't be done entirely within uucico, because there are other disk partitions (ie: news) to take into account - spoolfull can do that, but it's REAL HARD for something like spoolfull to figger out *who* is shovelling stuff in to be precise in who to shut off. With spoolfull, and some careful c-news tuning lsuc has been remarkably robust in the face of 20Mb+ news surges from its feeds. On the other hand, static decisions such as the ones I made won't work in the face of dorks who insist on imposing their 50MB VMS utility downloads on all and sundry. It's been said before, and I'll say it again: lsuc has been remarkably generous in its disk, line, cpu and human resources over the years (I think I gave it its first feed in '84). And over these years it has been remarkably reliable (especially when you consider what their machine was for the first 5 or so years!). Lsuc and its administrators deserve nothing but praise for doing a good job over a long period of time. No machine has infinite resources, especially ones that don't charge for their services (such as lsuc). People using them, even indirectly, shouldn't abuse it. People who scream and yell that sites that can't handle mail surges shouldn't be in the mail forwarding business should consider two things: 1) There wouldn't be a net AT ALL if every site took that attitude 2) You should try running a site with 50+ mail feeds, and 10+ news feeds for a while. -- Chris Lewis, Phone: (613) 832-0541, Domain: clewis@ferret.ocunix.on.ca UUCP: ...!cunews!latour!ecicrl!clewis; Ferret Mailing List: ferret-request@eci386; Psroff (not Adobe Transcript) enquiries: psroff-request@eci386 or Canada 416-832-0541. Psroff 3.0 in c.s.u soon!
xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (05/26/91)
merce@iguana.uucp (Jim Mercer) writes: > stanley@phoenix.com (John Stanley) writes: >> Like I said. The problem was not BITFTP. The >> problem is software that happily attempts to >> scribble across a disk on which there is no >> space. We would not accept this in any other >> application, especially an unattended one, but we >> will accept this from uucico. > isn't this like saying "cars produce so much > pollution, we neet to improve peoples lungs" ? You may well deserve your "butcher of bitftp" appellation if you keep up that kind of response. John is exactly right; the problem is, and always has been, a piece of broken software, and a corresponding broken protocol, that is willing to keep accepting input it no longer has room to store. People will ignore a toothache until the tooth rots to the gum line; uucico has been that kind of a problem; this site has suffered, as I'm sure does every UUCP site with limited disk space, news (and perhaps mail; how would one know?) being dropped on the floor regularly because the transfer protocol hasn't the sense to say "full up, hold the rest for later". That's as broken as broken software can get, but it suffers from the same problem Henry Spenser is trying to correct with some draconian C News decisions: the uucico software is so widespread, getting a maintenance action to take place _literally_ everywhere looks like too much trouble to undertake, so why fix what's broken? The solution would have to be like Henry's; install a new uucico that is _deliberately_ incompatible with the old one, and bring it up (after suitable testing) everywhere with a breathing sysadmin at once to a schedule, and let the rest of the sites go isolate until their sysadmins have been kickstarted by the resulting incompatibility into fixing their sites, too. Volunteers? (Ha!) Kent, the man from xanth. <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>
darcy@druid.uucp (D'Arcy J.M. Cain) (05/26/91)
In article <1991May25.202516.12961@zorch.SF-Bay.ORG> Kent Paul Dolan writes: >every UUCP site with limited disk space, news (and >perhaps mail; how would one know?) being dropped on >the floor regularly because the transfer protocol >hasn't the sense to say "full up, hold the rest for >later". That's as broken as broken software can get, Your cure is worse. If someone downstream from me snags gcc and X and only has a 20 Meg DOS system then that stuff (assuming *I* have room for it) sits on my machine forever blocking stuff for everyone on my system and my other downstreams. I have to be able to drop undeliverable stuff. Why should everyone else suffer because of one bozo? >The solution would have to be like Henry's; install >a new uucico that is _deliberately_ incompatible >with the old one, and bring it up (after suitable Huh? Cnews is deliberately *compatible* with the RFCs. That's what some are whining about - that their own software can't go on being incompatible. -- D'Arcy J.M. Cain (darcy@druid) | D'Arcy Cain Consulting | There's no government Toronto, Ontario, Canada | like no government! +1 416 424 2871 |
scott@skypod.guild.org (Scott Campbell) (05/26/91)
In article <1991May25.202516.12961@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: [comments on how uucico is broken and needs to be fixed] >The solution would have to be like Henry's; install >a new uucico that is _deliberately_ incompatible >with the old one, and bring it up (after suitable >testing) everywhere with a breathing sysadmin at >once to a schedule, and let the rest of the sites go >isolate until their sysadmins have been kickstarted >by the resulting incompatibility into fixing their >sites, too. The problem is, of course, that most of us do not have source for uucico. If you want to write an entirely new version of uucico that does not include any AT&T code, maybe I will try it after I have seen lots of other people running for several months. However, I talk to sites with several different mail/news/operating systems so any new uucico you write must work on SUN OS, waffle, minix, System V R3, System V R2 and FSUUCP for me to install it (Those are just my neighbours -- I am sure some of you out there talk to other systems). If my uucico won't talk to all of these sites than I won't use it. The uucico I have has its problems but everyone out there is pretty compatible with it and that is what counts. As long as no one sends huge files (ala BITFTP) through my site I can get by pretty well. Sure - I drop news on the floor sometimes -- but is your new uucico going to check my news spool to see that there is room before it accepts news and check the mail spool before it accepts mail and checks the uucppublic spool before it accepts uucp traffic? All this and handle whatever equivalents the DOS versions use? I think making a new uucico for all of the various versions of unix out there (and DOS and whatever else talks UUCP - VMS? VM? Multics? Ultrix?) would be relatively less trivial than you would think... Maybe I am wrong. Someone want to whip off a new version of uucico this weekend? I don't want to pay you for it by the way. scott p.s. on the BITFTP issue: I think that if UUNET and UUPSI set up FTP servers for their customers, then most of the valid complaints would go away. In fact, any site that provides UUCP links off of the internet should provide their own method of providing UUCP-FTP services. If the site upstream from you doesn't offer it then too bad. Any agreement for mail forwarding you have is usually with them and them alone. (ie. paying PSI for mail does not necessarily mean that you are paying for BITFTP access - how much of the money paid to PSI got passed along to Princeton?) -- Scott J.M. Campbell scott@skypod.guild.org Skypod Communications Inc. ..!gatech!dscatl!daysinns!skypod!scott 1001 Bay Street, Suite 1210 ..!uunet!utai!lsuc!becker!skypod!scott Toronto, Ont. (416) 924-4059 ..!epas.utoronto.ca!nyama!skypod!scott
merce@iguana.uucp (Jim Mercer) (05/27/91)
In article <1991May25.202516.12961@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: > merce@iguana.uucp (Jim Mercer) writes: >> stanley@phoenix.com (John Stanley) writes: > >>> Like I said. The problem was not BITFTP. The >>> problem is software that happily attempts to >>> scribble across a disk on which there is no >>> space. We would not accept this in any other >>> application, especially an unattended one, but we >>> will accept this from uucico. > >> isn't this like saying "cars produce so much >> pollution, we neet to improve peoples lungs" ? > >You may well deserve your "butcher of bitftp" >appellation if you keep up that kind of response. >John is exactly right; the problem is, and always >has been, a piece of broken software, and a >corresponding broken protocol, that is willing to >keep accepting input it no longer has room to store. and one of his brilliant solutions for this problem, was to only run uucico under supervision. i agree that uucico is somewhat broken, but as you go on to say, the problem is so widespread, there is not much we can do about it. since it is going to be a long time before someone comes out with a software solution to the problem, i suggest we try to live within its limitations. -- [ Jim Mercer work: jim@lsuc.on.ca home: merce@iguana.uucp +1 519 570-3467 ] [ "AIDS. Stick it in your head instead!" - Billboard seen in Toronto ] [ (it lost (gained?) something in the translation from french) ]
bert@medley.ssdl.com (Bert Medley ) (05/27/91)
darcy@druid.uucp (D'Arcy J.M. Cain) writes: > In article <1991May25.202516.12961@zorch.SF-Bay.ORG> Kent Paul Dolan writes: > >every UUCP site with limited disk space, news (and > >perhaps mail; how would one know?) being dropped on > >the floor regularly because the transfer protocol > >hasn't the sense to say "full up, hold the rest for > >later". That's as broken as broken software can get, > > Your cure is worse. If someone downstream from me snags > gcc and X and only has a 20 Meg DOS system then that stuff > (assuming *I* have room for it) sits on my machine forever > blocking stuff for everyone on my system and my other > downstreams. I have to be able to drop undeliverable stuff. > Why should everyone else suffer because of one bozo? > Being a leaf node at home without FTP access, I know exactly what you mean. Because of the selfish/uneducated actions of a few, many are being denied access to FTP services. The problem wasn't BITFTP or the presence of any other mail based archive server. Pure and simple, it is a problem of education for those who are intelligaent enough to understand and policy for those too selfish. If BITFTP and other FTP->mail servers were to limit the number of and size of the files requested, that bozo could not get hold of gcc and X in one fell swoop. Instead, he would have to retrieve it in bite size pieces. A better solution for all concerned. -- Bert Medley ! bert@medley.ssdl.com !
herrickd@iccgcc.decnet.ab.com (06/02/91)
In article <EMV.91May19170420@poe.aa.ox.com>, emv@ox.com (Ed Vielmetti) writes: > > and let's wrap some stuff around it so it's a one-liner: > ftpget msen wilma.cs.brown.edu:/pub/xmx.tar.Z ~/from-msen > i.e. > ftpget service-provider host:/path/to/sources destination-directory > > Write a shell script so that you can pipe comp.archives articles > into it and the sources come back at you, and I think everyone would Ed, maybe it's time for you to start putting unique identifiers on comp.archives articles (like cbip's <vnnnimmm>, or whatever they are). Then msen can offer include by reference: carefget msen <vnnnimmm>:3rd-file ~/from-msen and msen consults the verification at the end of article <vnnnimmm> and retrieves that file. Wildcarding etc. follows. dan herrick herrickd@iccgcc.decnet.ab.com
emv@msen.com (Edward Vielmetti) (06/02/91)
>> ftpget msen wilma.cs.brown.edu:/pub/xmx.tar.Z ~/from-msen > >are). Then msen can offer include by reference: > carefget msen <vnnnimmm>:3rd-file ~/from-msen >and msen consults the verification at the end of article <vnnnimmm> >and retrieves that file. Wildcarding etc. follows. the problems here are with bitrot -- software changes, people move and take their code with them, grant money comes and goes :-). the closest thing to a unique id in each article is the Archive-Name: header; it's something like Archive-name: category/subcategory/package/time-stamp Now my sense of categorization is pretty weak, but the "package" part stays consistent. If you were to ask for getpackage msen xmx ~/from-msen we could fetch the database entry for xmx, discover that either we have a copy locally or we know where to get all of its pieces parts, and send it down to you. bitrot is your enemy here, the half life of a reference to an ftp site location is less than a year, and keeping tabs on all nn hundred different things is real work. --Ed