lmo@lsr-vax.UUCP ("Lance M. Optican - LMO") (09/20/90)
Who is Paul Haeberli, and why does he give away all those nifty programs in binary? It would be a big help to us mere mortal programmers if instructions were included on extracting and running such programs. Thanks! ---------------------------------------------------+----------------------- Lance M. Optican | uunet!lsr-vax!lmo National Eye Institute, NIH, Bethesda, MD | (301) 496-3549 ---------------------------------------------------+-----------------------
msc@ramoth.esd.sgi.com (Mark Callow) (09/22/90)
In article <9009201522.AA00565@>, lmo@lsr-vax.UUCP ("Lance M. Optican - LMO") writes: |> |> Who is Paul Haeberli, and why does he give away |> all those nifty programs in binary? Paul is a Principle Engineer in our research group and he gives away all those swell programs because he's a nice guy. |> |> It would be a big help to us mere mortal programmers |> if instructions were included on extracting and |> running such programs. Save the article in a file somewhere and issue the command uudecode <somewhere> uudecode creates a new file which is the executable binary. Read the uudecode man page for more details. The executable binary extracted by uudecode is ready to run. -- From the TARDIS of Mark Callow msc@ramoth.sgi.com, ...{ames,decwrl}!sgi!msc "There is much virtue in a window. It is to a human being as a frame is to a painting, as a proscenium to a play. It strongly defines its content."
matthew@castle.ed.ac.uk (M White) (09/23/90)
In article <1990Sep21.175208.266@odin.corp.sgi.com> msc@sgi.com writes: >In article <9009201522.AA00565@>, lmo@lsr-vax.UUCP ("Lance M. Optican - LMO") >writes: >|> >|> Who is Paul Haeberli, and why does he give away >|> all those nifty programs in binary? >Paul is a Principle Engineer in our research group and he gives away all those >swell programs because he's a nice guy. > >|> >|> It would be a big help to us mere mortal programmers >|> if instructions were included on extracting and >|> running such programs. > >Save the article in a file somewhere and issue the command > > uudecode <somewhere> > >uudecode creates a new file which is the executable binary. Read the uudecode >man page for more details. The executable binary extracted by uudecode is >ready to run. Very useful Mark, however, the code does not do much on some systems. When run on our 4D/220 GTXB (IRIX 3.2) it eats CPU time with nothing appearing on the screen. I have two points : 1) Binaries should not be posted to the net: I have been slated by workmates, quite rightly, for attempting to run Pauls program on our machine. The net is not secure and running binaries straight off it (even if the appear to come from sgi) is not a good idea. 2) SGI personnel, of all people, should provide at least SOME instructions with code. If you have not seen a uuencoded file before, it is not obvious what should be done with it. It should not be necessary for net-time to be spent with queries such as Lance's above. In future, if someone from SGI wants to be a "nice guy", I would feel happier if they took notice of the above points. Despite my moaning, it is nice to see software being distributed for people to play with. Please don't let me put anyone off posting. -- Matthew White - Visualisation Support - Edinburgh Parallel Computing Centre "All right, hands up if you think it was a Russian water tentacle." - Abyss
msc@ramoth.esd.sgi.com (Mark Callow) (09/25/90)
In article <6451@castle.ed.ac.uk>, matthew@castle.ed.ac.uk (M White) writes: |> Very useful Mark, however, the code does not do much on some systems. |> When run on our 4D/220 GTXB (IRIX 3.2) it eats CPU time with nothing |> appearing on the screen. I have two points : |> |> 1) Binaries should not be posted to the net: I have been slated by |> workmates, quite rightly, for attempting to run Pauls program on our |> machine. The net is not secure and running binaries straight off it |> (even if the appear to come from sgi) is not a good idea. Paul has posted considerably more than the Electropaint program you are complaining about. (Incidently that wasn't Paul's program, and it doesn't work on systems not running 3.3.) Most of his postings are filters for translating to and from various foreign image file formats and they all work. Which would you rather have, nothing or binaries? In some cases a binary is the only way we could distribute something because of, for example, use of a library that is not widely available or whose source is proprietary. |> |> 2) SGI personnel, of all people, should provide at least SOME |> instructions with code. If you have not seen a uuencoded file before, it |> is not obvious what should be done with it. It should not be necessary |> for net-time to be spent with queries such as Lance's above. |> Yes some simple instructions would help. -- From the TARDIS of Mark Callow msc@ramoth.sgi.com, ...{ames,decwrl}!sgi!msc "There is much virtue in a window. It is to a human being as a frame is to a painting, as a proscenium to a play. It strongly defines its content."
jim@baroque.Stanford.EDU (James Helman) (09/25/90)
1) Binaries should not be posted to the net: I have been slated by
workmates, quite rightly, for attempting to run Pauls program on
our machine. The net is not secure and running binaries straight
off it (even if the appear to come from sgi) is not a good idea.
The same is true of large source code distributions as well. I have
looked at only a small fraction of the source code off the net which
I've compiled, some of it installed suid root. Any piece of it could
be dangerous, but not necessarily by intention. A good example is the
recent XView source code distribution, whose original makefile (which
was quickly corrected and disseminated thanks to the net) did an "rm
-rf ../../." in response to a "make clean." Another was the gnuemacs
makemail security "hole", which resulted from someone incorrectly
installing suid root a program which was not designed for and did not
need to be installed that way.
I think it's important to raise the issue. Sysadmins of lots of
machines right on the Internet are too complacent about security, not
even bothering to put passwords on user, and often even system,
accounts. Others are too paranoid and want to forbid use of any
software from the net. They both worry me.
Everyone should remember what can happen, even when your machine is
running mainstream software:
Received: by thrush.STANFORD.EDU (3.2/4.7); Thu, 3 Nov 88 03:36:02 PST
Subject: Sun & Vaxen virus ALERT!
Date: Thu, 03 Nov 88 03:36:00 PST
This evening our cluster of Suns and Vaxen started having a fit.
Sluggish. Heavy load. The finger daemons were buzzing and lots
of sh's and rsh's started popping up.
. . .
Yep, someone is spreading a virus across the ethernet by executing a
shell commands via sendmail. The shell script compiles and runs a C
program which opens an ethernet connection to copy the full virus from
an infected machine. Apparently, it then looks for ways to propagate
itself to other machines. I've managed to intercept a copy of the
receptor program by creating a fake sed. But so far, I haven't been
able to get a full copy. This virus doesn't appear to do any damage
other than creating a heavy load and possibly crashing the machine
when resource limits are exceded.
Whether risking network software is worthwhile depends on how much you
trust the source and how much you want the software. And most of us
want software real bad.
Most of the past damage hasn't been caused by malice, but by goofs.
Let's hope both consumers and suppliers of code are careful enough to
avoid any disasters. It's too valuable an exchange to give up.
Jim Helman
Department of Applied Physics Durand 012
Stanford University FAX: (415) 725-3377
(jim@KAOS.stanford.edu) Work: (415) 723-9127spl@taurus.cs.nps.navy.mil (steve lamont) (09/25/90)
In article <1990Sep24.190428.28475@odin.corp.sgi.com> msc@sgi.com writes: >Which would you rather have, nothing or binaries? In some cases a binary >is the only way we could distribute something because of, for example, >use of a library that is not widely available or whose source is proprietary. First of all, I should say that Mr. Haeberli (sp?) has my deepest respect as a practitioner of our art and science and his contributions are appreciated. However, since you asked... "nothing" would be preferable. Binaries are too dangerous. Somebody along the line could easily tamper with them or, indeed, forge a posting, and cause damage to a great number of systems. spl (the p stands for please, the sources???) -- Steve Lamont -- SciViGuy -- Phone number of the week: (408) 646-2572 Confuser Center / Code 51 / Naval Postgraduate School / Monterey, CA 93943 "There are no fleas in the Republican Army." - Italo Calvino, _The Baron in the Trees_
arritt@kuhub.cc.ukans.edu (09/25/90)
In article <6451@castle.ed.ac.uk>, matthew@castle.ed.ac.uk (M White) writes: > I have two points : > > 1) Binaries should not be posted to the net: I have been slated by > workmates, quite rightly, for attempting to run Pauls program on our > machine. The net is not secure and running binaries straight off it > (even if the appear to come from sgi) is not a good idea. Personally, I PREFER binaries to source code; sources don't always compile cleanly on my system. Those who don't like binaries aren't being forced to download them and uudecode them. Those of us willing to do so presumably are aware of the risks involved. Caveat emptor. > 2) SGI personnel, of all people, should provide at least SOME > instructions with code. If you have not seen a uuencoded file before, it > is not obvious what should be done with it. It should not be necessary > for net-time to be spent with queries such as Lance's above. Hear, hear! At a minimum, include a brief description of what the file does and any requirements as to operating system, hardware configuration, etc. Perhaps a warning to the uninitiated re point (1) above would be appropriate (as a legal defense for the poster, if nothing else). ________________________________________________________________________ Raymond W. Arritt | Assistant Professor | Dept. of Physics and Astronomy | "everyone knew that as time went Univ. of Kansas | by we'd get a little bit older Lawrence, KS 66045 | and a little bit slower..." arritt@kuhub.cc.ukans.edu | arritt@ukanvax.bitnet |
tohanson@gonzo.lerc.nasa.gov (Jeff Hanson) (09/26/90)
Steve Lamont writes > However, since you asked... "nothing" would be preferable. Binaries are too > dangerous. Somebody along the line could easily tamper with them or, indeed, > forge a posting, and cause damage to a great number of systems. While I agree with his worry, I'd rather have something. However, if instead of posting, Paul put his creations on sgi.com or on vgr.brl.mil, where there is control over what gets put where and the posts to announce the new and wonderful programs, then the security concerns are allayed. Furthermore, this would limit the request of "I lost", "I never saw", "Could someone re-post" the latest. I believe in anonymous ftp as an excellent distribution technique. -- *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* \ / \ / \ / \ / \ / \ / Jeff Hanson \ / \ / \ / \ / \ / \ / * ViSC: Better * tohanson@gonzo.lerc.nasa.gov * * * * * * / \ / \ Science / \ / \ NASA Lewis Research Center / \ / \ Through / \ / \ * * * * * * * Cleveland, Ohio 44135 * * * Pictures * * \ / \ / \ / \ Telephone - (216) 433-2284 Fax - (216) 433-2182 \ / \ / \ / *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
MOHRINGJ%ESVAX@dupont.COM (09/26/90)
A brief description of what the file does and any requirements as to operating system, hardware configuration, etc., would be nice, but if it's a matter of posting or not posting, I'll muddle through on my own if I HAVE TO. I, for one, don't look a gift horse in the mouth. Jim Mohring DuPont Experimental Station Node: mohringj%esvax%dupont.com Phone 302-695-4325 FAX 302-695-1173 "Silence is the ONLY acceptable substitute for Brains"
joel@purvid.UUCP (Joel Tenenbaum) (09/27/90)
Several recent postings have dealt with the pros and cons of posting binaries (and to some extent, large sources) in terms of security and accompanying instructions. Another issue is relevant to those of us at the far ends of the Usenet distribution tree. My upstream node has pointed out that substantial phone time and occasional clogging of the queues occurs due to these large files (One of them, about 160K, violates the size limits on some of the intermediate mailers). It is my understanding that the etiquette in other groups is for the availability of such programs to be posted. The actual transfer is then done by mail or ftp from an archive. While we also have an Internet connection, I suspect that a number of readers are still phone based. Any thoughts? Joel -- Joel Tenenbaum joel@purvid.purchase.edu ...hsi!mlfarm!purvid!joel
baskett@forest.asd.sgi.COM (Forest Baskett) (10/03/90)
"SGI personnel, of all people, should provide at least SOME instructions with code. ... It should not be necessary for net-time to be spent with queries such as Lance's above." Paul Haeberli is one of those unusual individuals to whom many things are obvious that are down right mysterious to some of us mere mortals. His heart is in the right place but I'm often not sure where his mind is except that it usually turns out to have been in a good place. The net is rich and varied and, as a consequence, YOU can often find things on it that are useful to you. But the price seems to be that you also have to wade through stuff you find useless or even annoying. Forest Baskett Silicon Graphics