Re: What DO you lose with Linux ???
On Tue, 6 Apr 1999, Steve Lamb wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Tue, 6 Apr 1999 19:10:33 -0600 (MDT), John Galt wrote:
>
> >I posited a problem wherein FTP and HTTP were both unavailable, so the
> >obvious solution is mail--NOT snail mail, email.
>
> And if email isn't available? And the protocol after that? And after
> that?
But the emailing standard predates both FTP and HTTP, thus the situation
existed once.
> It reminds me of a discussion a while back I had in the newsgroups
> against people who were so determined that everyone must know how to use vi
> to be called unix proficient. I told them I've been using Linux for 2+
> years, unix in general for 5+ years, was a SysAdmin and didn't know, care to
> know, or felt the need to learn vi. My answer, joe.
and the situation also existed once wherein joe wasn't an option, thus vi
was required learning.
> Well, one guy came up with a great situation. "What if..." What if I
> were on a machine that had no compiler, had no net access, no floppy drive,
> had no other editors or things which could be used *as* editors (sed & ed
> come to mind) but did have vi. How would I then edit files? I declared the
> machine unusable as it was obviously so archaic and/or esoteric that it is
> beyond and reasonable need of mine and I would promptly turn it off and find
> a real machine.
try doing that in the pre-joe days, and your alternative might've been not
to use a computer at all.
> Your "situation" is the same. It is easy to make a case where your
> answer is the only solution simply by excluding all other viable solutions.
> "What if..." What if both FTP and HTTP are unavailable. In such a
> situation, you've got problems more than email because if those two *basic*
> and *standard* protocols aren't available then your network is, in a word,
> fucked.
Maybe, but why the FTP->email gateways then? it might have been that they
were once needed, no?
> As in the situation with vi, there comes a point when you just go
> elsewhere for the solution. Just because every sane protocol is unavailable
> gives you a reason to break and abuse any protocol which is left and,
> further, to demand that other systems allow you to break said protocol. In
> my 6 month tenure as postmaster at my former job, a local ISP, I had two
> people complain to me because we would not allow email messages larger than
> 5Mb. They would not hear about DoS issues, or storage issues, or how to
> properly move the data, they wanted their attachments or else. I told both,
> or else. If they could find an ISP which suited their needs, they were more
> then welcome. That is why I am so vehemently opposed to anyone using email
> for large attachments. That is why I say that as the size of the attachment
> goes up, its value goes down. At some point it is better to use another
> protocol for a variety of technical and social reasons, EVEN IF it is the
> only protocol available (IE, another protocol is mail it) and EVEN IF the
> file is requested by the other user.
So you threw out the baby with the bathwater, then blamed the people who
complained about the lack of the baby? I just redefined "hostile
ISP"--mine is positively friendly by those standards. The variety of
technical reasons are all recent additions: FTP was actually a solution to
the large attachments problem, but not a complete one--mostly because the
site-building and access granting process was more trouble than some files
was worth. HTTP was another solution, provided that you didn't mind
making the file world-readable. Thus the protocol of email isn't being
broken when a large attachment is sent via email, it's being used as
intended, you have just misconstrued the fixes as being complete, which
they're still not.
> >The abuses are there, but there are times when FTP and HTTP are unusable--
>
> And in those cases I have described the proper response. If it is an
> ISP, change ISPs. Any ISP which does not provide space and the meens for
> anonymous FTP and web space with a functional HTTP server is screwing you.
> If it is because of corporate policy, either use an ISP or go over IT's head
> because they are obviously a bunch of clueless nits. In the interim, mail it.
Hmmmmm. I guess that the old DECnet must've been hell for you then.
> >This problem is going to be with us a long time, and carping about the
> >unsuitability one of the protocols for large files ain't helping.
>
> Meanwhile another problem is going to be with us for a long time. It is
> caled the Denial of Service attack. Furthermore, even legit attachments
> cause problems. In some cases with qpopper and Eudora (All versions to
> date) if a large attachment (1Mb is large enough) hits the mailbox, Eudora
> chokes and will not download it. Outlook(9X/Express) has a similar problem,
> I just don't know the rough size that triggers it. A person who uses PMMail
> got a 6.5Mb attachment. PMMail would download it fine, but he wanted to get
> it last, not first, and is now looking to the authors for a way to have
> PMMail not automatically fetch upon startup, at his discretion, so he can
> get the other messages first and then let PMMail get that one on the next
> check. Encouraging an abuse of the mail protocols doesn't help any of these
> and all three are problems that the professionals that keep the Internet
> running day in and day out encounter on a nearly daily, if not hourly basis.
The DoS attack is going to exist no matter what is done to stop it. It is
an artifact of TCP/IP networking: the only thing that can truly not be
denied is what isn't there. Shutting down a part of an existing protocol
because of it is ludicrous at best. The professionals that keep the
internet running, for the most part, know this, thus the minor fact that
large attachments to email exist to this date.
> How about this, if email is such a viable option for files, why isn't
> there an email method for dselect? Silly? That is how I see the whole idea
> of large files through email. Sure, someone could make an email method for
> dselect, and it would work, and, by your elimination of other options,
> someone really shoud. "What if..." What if someone doesn't have a floppy
> drive, doesn't have a CDROM, can't FTP, can't use HTTP, but somehow got
> Debian onto the machine in the first place and wants to upgrade?
Debian is a latecomer in that respect--there was a server that did
"updates via email" for Big Iron (gatekeeper?), I just can't remember
which one. IIRC there is still a mainframe/mini corp that provides OS
updates via email if asked--just can't remember which one (maybe not
now--it might've been one of the ones absorbed or TUed in the last few
years' bloodbath). Citations to be provided when I can get to my old
notes.
>
> - --
> Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
> ICQ: 5107343 | main connection to the switchboard of souls.
> - -------------------------------+---------------------------------------------
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGPsdk version 1.0 (C) 1997 Pretty Good Privacy, Inc
>
> iQA/AwUBNwrZsXpf7K2LbpnFEQJIaACcDUPnt4jaRglx2NWWco4cl7YlB1YAoORN
> w1YkIQszmoadLvq/n/4/ao/o
> =D+Vw
> -----END PGP SIGNATURE-----
>
>
>
> --
> Unsubscribe? mail -s unsubscribe debian-user-request@lists.debian.org < /dev/null
>
Pardon me, but you have obviously mistaken me for someone who gives a
damn.
email galt@inconnu.isu.edu
Reply to: