heiby@falkor.UUCP (Ron Heiby) (04/30/88)
Robert L Sillett (spectre@unix.cis.pittsburgh.edu.UUCP) writes: > Well, someone asked for arc for Unix. I don't know if this > will run on every Unix system, but it works on mine. As far > as I can tell, this is also 100% compatible with pkarc old > and NEW methods. > begin 700 arc [...] > end Well, I never thought I'd see the day. Wow, what a treat! A uuencoded Ultrix a.out file! No, it will not run on every Unix system. It will run on a very small number of Unix systems. Part of the reason why most Unix systems have a C compiler available is so that people can share SOURCE code and compile it for their own systems. That is why there is no comp.binaries.unix or comp.unix.binaries newsgroup. Since it turned out that this was an Ultrix a.out (by looking at strings in it after uudecoding it), this isn't even a binary for PCs or a program that will help more than a handful of people deal with binaries for PCs. The source for UNIX arc was recently posted. There is no reason for posting binaries of it. I'm sure that relatively few of you would be interested in the a.out of arc from my SVR3 68020 system. Let's give a bit more thought to our postings. I almost sent this as mail, but figured that if there was one person out there, there'd probably be others. We don't want UNIX BINARIES! Thanks. P.S. Robert, have your site administrator fix your software so that the ".UUCP" doesn't get tacked onto your domain in the Reply-To field. It's a simple change to rn's Pnews command. -- Ron Heiby, heiby@mcdchg.UUCP Moderator: comp.newprod & comp.unix "I believe in the Tooth Fairy." "I believe in Santa Claus." "I believe in the future of the Space Program."
feg@clyde.ATT.COM (Forrest Gehrke) (05/02/88)
In article <162@falkor.UUCP>, heiby@falkor.UUCP (Ron Heiby) writes: .> Robert L Sillett (spectre@unix.cis.pittsburgh.edu.UUCP) writes: .> > Well, someone asked for arc for Unix. I don't know if this .> > will run on every Unix system,....... As far as I can tell, .> > this is also 100% compatible with pkarc old and NEW methods. .> .> Well, I never thought I'd see the day. Wow, what a treat! A uuencoded .> Ultrix a.out file! No, it will not run on every Unix system. It will .> run on a very small number of Unix systems. Part of the reason why most .> Unix systems have a C compiler available is so that people can share .> SOURCE code and compile it for their own systems. That is why there .> is no comp.binaries.unix or comp.unix.binaries ................. Can someone provide a source that handles PARC for Sys V Unix, please? Forrest Gehrke
loci@csccat.UUCP (Chuck Brunow) (05/03/88)
I agree whole-heartedly with the posting referenced above. The Unix OS runs on far too many different hardwares to make posting binary programs a viable or useful effort. The existing binary groups are strictly limited to the hobbyist types of machines are have more of an air of junk mail than anything useful. Much of Usenet is devoted to an exchange of ideas and techniques which is completely unlike the jumble of unreadable postings to binary groups. It may be a great ego trip for somebody to post their little pet project or worse, to post something they had no part in creating, but it's just a eye-sore at 1200 baud. I favor billing the persons who post multi-part binaries for transmission costs to all sites that receive it. That way, unless there are enough users who want it badly enough to pay for it posting will go into the bit-bucket. In summary, keep your UNIX binary postings to yourself. If you're too timid to let the world see the code, it probably isn't any good anyway.
mike@ists (Mike Clarkson) (05/04/88)
In article <162@falkor.UUCP>, heiby@falkor.UUCP (Ron Heiby) writes: > Well, I never thought I'd see the day. Wow, what a treat! A uuencoded > Ultrix a.out file! No, it will not run on every Unix system. It will > run on a very small number of Unix systems. Part of the reason why most > Unix systems have a C compiler available is so that people can share > SOURCE code and compile it for their own systems. That is why there > is no comp.binaries.unix or comp.unix.binaries newsgroup. And besides, no Unix system admin in their right mind would let a binary off the net onto their system. It's one thing for viruses to trash peoples PC disks, but *nobody* is going to get at my 1 gigabyte SMD drive. Nobody! -- Mike Clarkson mike@ists.UUCP Institute for Space and Terrestrial Science mike@ists.yorku.ca York University, North York, Ontario, CANADA M3J 1P3 (416) 736-5611
madd@bu-cs.BU.EDU (Jim Frost) (05/09/88)
In article <197@ists> mike@ists (Mike Clarkson) writes: |In article <162@falkor.UUCP>, heiby@falkor.UUCP (Ron Heiby) writes: |> Part of the reason why most |> Unix systems have a C compiler available is so that people can share |> SOURCE code and compile it for their own systems. That is why there |> is no comp.binaries.unix or comp.unix.binaries newsgroup. No. MOST of the reason why UNIX systems have a C compiler available is because the UNIX environment is a development environment, made by programmers for programming. It also happens to be convenient to have the compiler online for the language your system was written in. As for why there isn't a binaries group for UNIX, it's simply a matter of heterogenous systems. UNIX runs on more different kinds of machines than any other operating system (that I've seen, anyway). It's just not practical to post binaries. Besides, nearly all UNIX systems contain a compiler *because the system was made for program development* so you're assured high penetration when you distribute source code. On PC's, virtually no systems come with a compiler of any kind, and compilers are generally expensive. Programmers buy them, but your average guy doesn't have one. Binaries have much higher penetration. |And besides, no Unix system admin in their right mind would let a binary |off the net onto their system. It's one thing for viruses to trash peoples |PC disks, but *nobody* is going to get at my 1 gigabyte SMD drive. This is terribly closed-minded. Why haven't viruses proliferated on UNIX systems? Protection, for one thing. A program generally requires special permissions to do something really damaging to a UNIX system. This is part of why root logins shouldn't have "." in their path -- you don't want to accidentally give a user program those types of permissions. On PC's, there is seldom any kind of protection at all, and it's usually easy to get around. It doesn't take a particularly brilliant hack to write a program to trash a disk when there is nothing to stop a program from reading or writing the disk directly. Another reason is that UNIX systems vary so much that you just can't be sure of the type of hardware you're dealing with. You can't be sure what kind of removable storage a UNIX system uses. Floppy? Tape? Removable hard drive? Optical drive? Videotape? Try to write a virus program that 1) doesn't need to be superuser to have an effect and 2) understands enough different forms of hardware to be effective. It's somewhat tougher than writing a program to stomp on an unprotected hard drive. Also, the odds are very poor that anything written on removable storage on your system will find its way to another. It does happen, but not often enough to get good contamination. Would I use a binary off the net on my own UNIX system? Sure. Would I ever run it as root? Not in your lifetime. jim frost madd@bu-it.bu.edu