From: Digestifier To: Linux-Development@senator-bedfellow.mit.edu Reply-To: Linux-Development@senator-bedfellow.mit.edu Date: Fri, 22 Oct 93 19:13:13 EDT Subject: Linux-Development Digest #181 Linux-Development Digest #181, Volume #1 Fri, 22 Oct 93 19:13:13 EDT Contents: Drive Size for doing development? (Patrick Brewer) Re: NIS ? (Dave Rosser Jr.) At-Lan-Tec parallel eth yet? (Thomas J Bilan) Linux and Gopher 2.08 ??? (Norbert Kuemin) /dev not needed? (Stephen Harris) UNIX trademark now X/Open (Stephen Harris) Linux for MIPS R4000 ? (Geoffrey Furnish) Re: Internet connectivity [RE: Puzzled by internet] (Kent Fox) Re: developping an OO environment over Linux ? (Olaf Schlueter) Re: ugly name for core dumps (core.imagename) -> patch for "img.core" (slhpv@cc.usu.edu) Re: Andrew File System (Heikki Suonsivu) Re: Andrew File System (Gary Keim) Bug in tcpip package? (Joe Emenaker) Re: Andrew File System (Michael Polis) ---------------------------------------------------------------------------- Subject: Drive Size for doing development? From: pwb@choh090.cho.ge.com (Patrick Brewer) Date: 20 Oct 93 08:20:00 EDT This question is addressed to people doing development on linux. How much disk space would you recommend some one have if they wanted to do development on a pc running linux? Would you recomend a drive for DOS and another drive for linux or is it safe to partition one drive for both? Please respond by e-mail to noble@catt.ncsu.edu or to patrick.brewer@cho.ge.com Thank you. ------------------------------ From: dave@cwis.unomaha.edu (Dave Rosser Jr.) Subject: Re: NIS ? Date: Fri, 22 Oct 1993 12:45:22 GMT tdi9110@abacus.hgs.se (Benny Holmgren) writes: >Hello >Fromwhat I've heard,there's a development of NIS going on out there somewhere. >If so, does anyone know who's working on it and how's it going. I'd like some >status info on the project. > Thanks.. Hi Benny, I went out to ftp.uni-paderborn.de and got the sources and bins. However uppasswd was not available in binary. After updating my libs all the sources compiled fine( with the occasional warning :)) except yppasswd. error: /usr/bin/gcc -I./ -V 2.4.5 -b i486-linux -o yppasswd yppasswd.o -lshadow /usr/lib/libshadow.a(getpass.o): Undefined symbol _kill referenced from text segment make: *** [yppasswd] Error 1 I'm stumped. I thought _kill was in libc.a??? (or libc.sa). I'm looking for the debuged version of the shadow passwd suite. Anyone know where it is? Well that how far i got ANY help would be greatly appreciated, does someone already have a binary for yppasswd? Is there a fix so i can compile it? will the new shadow passwd suite have a new libshadow.[s]a that will fix this? Dave Rosser Jr. ------------------------------ From: bilan@cps.msu.edu (Thomas J Bilan) Subject: At-Lan-Tec parallel eth yet? Date: 22 Oct 1993 13:51:27 GMT I was reading in the Ethernet-HOWTO and found that a driver for the AT-LAN-TEC parallel port ethernet adapter was in development. Does anyone know if this is still planned or is AT-LAN-TEC pulling a Xircom? Tom Bilan -- /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ $ Department of Death by Engineering ^ Surgeon General's Warning: $ $ Michigan State University ^ Graduate School may cause brain $ $ bilan@cps.msu.edu ^ damage and sporadic loss of hair $ ------------------------------ From: ZAD_KUEMIN@TRZCL1 (Norbert Kuemin) Subject: Linux and Gopher 2.08 ??? Date: Fri, 22 Oct 1993 15:52:17 GMT Hi there, I've got some troubles with Gopher 2.08..... If there is a TAB in a textfile, it will erase the beginning of these line.. Example ============================================================================== This is the first field This is the second ============================================================================== will look in Gopher like this : ============================================================================== This is the second ============================================================================== Anyone an answer ? GREETINGS .................. +----------V----------+ Norbert Kuemin |RFC822: norbert.kuemin@alcatel.ch | A L C A T E L | Alcatel STR |DECnet: PSI%4795123920::ZAD_KUEMIN +---------------------+ |X.400: c=CH a=arCom p=Alcatel S T R CH-8804 Au / ZH | s=Kuemin g=Norbert ------------------------------ From: sweh.womble@spuddy.UUCP (Stephen Harris) Subject: /dev not needed? Date: Thu, 21 Oct 93 22:30:55 GMT In article <1993Oct20.134218.18667@excaliber.uucp> joel@rac3.wam.umd.edu writes: > [who wrote what deleted] > > [re not needing /dev anymore] > > I, for one, will go no further with LINUX if it strays far from > > "standard unix" (I realize there are many unix variants, but > > I've yet to see one that didn't use /dev :-) > But your Favorite Tools rely on /dev. Many many applications assume > that the bit bucket can be found at /dev/null, e.g. Many others OK, these are valid points. They could be dealt with in a number of ways (some already mentioned): 1) symlink /dev to /proc/dev 2) symlink contents to /proc/dev into /dev 3) COPY contents of /proc/dev to /dev 4) /proc/dev is in fact a LIST of devices the system knows, and this is used to mknod the devices in /dev at boot time. I agree that a /dev IS needed (I badly worded the original message). What isn't needed is a static /dev with a MAKEDEV shell script. Since the kernel knows what devices are present, its not much harder for it to tell us (in theory - practice is probably different :-) ), and to build the /dev on that information. > assume /dev/tty exsists. Uucp type packages assume that the lock info > in /usr/spool/uucp/LCK.... refers to /dev/.... And so on. or /usr/locks, or /usr/spool/locks, or..... standards, what a large choice :-) > If you really wanted to, I suppose we could move everything to proc, > and then symlink /dev stuff to proc stuff, but I can't even imagine > why that would be good. Because the /dev list would then be automagically be up todate with what the kernel has access to, what it has compiled in, what hardware is present etc. It would also enable STANDARDS to be set ( I *bet* some people have tty64..tty67 still as the serial ports - or maybe not 'cos these are real old names that the people involved know enough to fix it :-) ttyS0 or ttys0 or tty00 or what? ) because these names would be in the kernel. > Also, /dev files must be available on bootup, so you don't want them > on a mounted fs. My /proc is mounted. A bit harder, but not much of a problem. / is already mounted without access to the /dev files. /proc could be mounted in the same way from rc files. "mount -nt proc /proc /proc" wouldn't need any resources that /dev provides. "mount -a" would need to be updated to treat "proc" the same way as "root" (ie put an entry in mtab, but not try to mount) [ or heck, do it via a syscall() if you don't really want /proc to do the job - use syscall() to return an array of name/major/minor devices ] Stephen Harris sweh.womble@spuddy.uucp ...!uknet!axion!spuddy!sweh.womble * Meow! Call Spuddy the Cat for Usenet access in the UK. Call 0203 364436 * ------------------------------ From: sweh.womble@spuddy.UUCP (Stephen Harris) Subject: UNIX trademark now X/Open Date: Thu, 21 Oct 93 22:38:15 GMT In article <1993Oct20.010412.1257@Synopsys.Com> jbuck@synopsys.com writes: [ regarding calling Linux "Unix" ] > (I'd be delighted if this were done, partly to cool the jets of those > folk who are always suggesting that something brand-new and very non > Unixlike be invented for Linux and that traditional Unix mechanisms > be tossed). I don't see anyone saying "toss out traditional Unix mechanisms". What I see are people saying "we could extend/improve/replace existing systems with a better setup whilst maintaining compatibility" (or at least any proposal worth looking at). Remember, Unix is an old system really. Some of its designs are now obviously outdated, inefficient and sometimes simply bad. The current /dev discussion is like this: /proc/dev is IMHO a better way of doing things, but when/if it is implemented the implementor is going to have to take care of backward compatibility. Don't let prejudices of existing systems prevent new improved ideas entering into the system. Following your logic a /proc filesytem would never have appeared in ANY Unix implementation, because old Unix systems always grovelled through the kernel.... Stephen Harris sweh.womble@spuddy.uucp ...!uknet!axion!spuddy!sweh.womble * Meow! Call Spuddy the Cat for Usenet access in the UK. Call 0203 364436 * ------------------------------ From: furnish@dino.ph.utexas.edu (Geoffrey Furnish) Subject: Linux for MIPS R4000 ? Date: 22 Oct 1993 14:46:40 GMT Hello all, Sometime ago there was discussion about a possible MIPS hw/sw project which was to employ Linux as the OS. Has there been any actual work in this area. Anybody besides me interested in seeing Linux on R4000. I might (maybe, possilby, but no promises) be able to free some time for this, but would certainly need a lot of help. Geoff Furnish furnish@dino.ph.utexas.edu ------------------------------ From: ai539@yfn.ysu.edu (Kent Fox) Subject: Re: Internet connectivity [RE: Puzzled by internet] Date: 22 Oct 1993 16:44:09 GMT Reply-To: ai539@yfn.ysu.edu (Kent Fox) In a previous article, araw@elm.circa.ufl.edu (Robert Moser) says: >To everyone curious what happened to the "Puzzled by internet" followup: Sorry, I missed this one the first time around ... if you are looking for internet connectivity, *the* source of information is the 'pdial' list - available for anonymous ftp from ftp.netcom.com:/pub/info-deli/pdial. It is sorted by area code(s) served, and includes international sites. ------------------------------ From: olaf@toppoint.de (Olaf Schlueter) Subject: Re: developping an OO environment over Linux ? Date: 22 Oct 1993 16:23:39 +0100 rideau@ens.fr (Francois-Rene Rideau) writes: > Is it possible to link my current (MS-DOS) TASM .obj output modules with unix >object modules Probably not. gas/ld uses its own object file format. >(These files rely heavily upon TASM's macro-language, whereas GAS >hasn't got anything like that; perhaps someone has got a good, powerful >preprocessor, i.e. something else than this stupid cpp) ? gas comes along with a powerful macro language called C. (You may wish to look at the inline assembly facilities of it). Sorry, couldn't resist. -- Olaf Schlüter, Sandkuhle 4-6, 24103 Kiel, Germany, Toppoint Mailbox e.V. "MSDOS didn't get as bad as it is overnight -- it took over ten years of careful development." David Megginson ------------------------------ From: slhpv@cc.usu.edu Subject: Re: ugly name for core dumps (core.imagename) -> patch for "img.core" Date: 22 Oct 93 00:42:43 MDT In article , rfrankel@us.oracle.com (Rick Frankel) writes: > [edited] > In article koenig@nova.tat.physik.uni-tuebingen.de (Harald Koenig) writes: > > koenig> whats amout using 'core' as file name extension (isn't used > koenig> yet), so finding *.core sould be more secure and collisions > koenig> with soures wouldn't occur (if your file system supports > koenig> enough characters in file names for imagename.core). > > Seems like a reasonable approach. > I would like to see something like this: core\imagename, that way you could find and remove core files using the command: rm core\\* very unlikely to have filename conflicts. Dave Dunn ------------------------------ From: hsu@cs.hut.fi (Heikki Suonsivu) Subject: Re: Andrew File System Date: 22 Oct 1993 18:49:58 GMT In article Court Demas writes: AFS sucks anyways. Use NFS :-) AFS would be better than NFS, but I don't see what is the point of trying to be compatible with AFS which isn't used anywhere (a major example of how making something propretiary looses :-). Writing a new WAFS wouldn't be that difficult, and risk of ligitation would be much less worse. Anybody working on this, mailing lists etc? - Heikki Suonsivu, T{ysikuu 10 C 83/02210 Espoo/FINLAND, hsu@cs.hut.fi home +358-0-8031121 work -4513377 fax -4555276 riippu SN /G=Heikki/S=Suonsivu/O=hut/OU=cs/PRMD=Inet/ADMD=Fumail/C=FI ------------------------------ From: Gary Keim Subject: Re: Andrew File System Date: Fri, 22 Oct 1993 16:22:09 -0400 Excerpts from netnews.comp.os.linux.development: 22-Oct-93 Re: Andrew File System Heikki Suonsivu@cs.hut.f (645) > AFS would be better than NFS, but I don't see what is the point of trying > to be compatible with AFS which isn't used anywhere (a major example of how > making something propretiary looses :-). % ls /afs alw.nih.gov dsg.stanford.edu nersc.gov andrew ece net.mit.edu andrew.cmu.edu ece.cmu.edu northstar.dartmouth.edu anl.gov es.net nsf-centers.edu athena.mit.edu ethz.ch others.chalmers.se bcc.ac.uk fnal.gov palo_alto.hpl.hp.com bstars.com gr.osf.org pegasus.cranfield.ac.uk bu.edu grand.central.org pitt.edu cards.com graphics.cornell.edu psc.edu ce hrzone.th-darmstadt.de pub.nsa.hp.com ce.cmu.edu huge.psc.edu rel-eng.athena.mit.edu cern.ch iastate.edu rhrk.uni-kl.de cheme inel.gov ri.osf.org cheme.cmu.edu ipp-garching.mpg.de rose-hulman.edu ciesin.org ir.stanford.edu rpi.edu citi.umich.edu isi.edu rrz.uni-koeln.de club jrc.flinders.edu.au rus.uni-stuttgart.de club.cc.cmu.edu kiewit.dartmouth.edu sfc.keio.ac.jp cmf.nrl.navy.mil lrz-muenchen.de sipb.mit.edu cmu.edu lsa.umich.edu slac.stanford.edu cs math.lsa.umich.edu spc.uchicago.edu cs.arizona.edu me ssc.gov cs.brown.edu me.cmu.edu stars.com cs.cmu.edu media-lab.mit.edu stars.reston.unisys.com cs.cornell.edu msc.cornell.edu theory.cornell.edu cs.unc.edu mtxinu.com titech.ac.jp cs.utah.edu nada.kth.se transarc.com cs.washington.edu ncat.edu ucop.edu cs.wisc.edu nce umich.edu css.cs.utah.edu nce_ctc uni-freiburg.de ctd.ornl.gov nce_psc urz.uni-heidelberg.de ctp.se.ibm.com ncsa.uiuc.edu vfl.paramax.com dmsv.med.umich.edu nd.edu wam.umd.edu That's quite a few nowhere's. -Gary Keim Andrew Consortium ------------------------------ From: jemenake@trumpet.aix.calpoly.edu (Joe Emenaker) Subject: Bug in tcpip package? Date: Thu, 21 Oct 1993 14:20:11 GMT I grabbed the tcpip.tgz off of tsx-11 down where the MCC stuff is kept. I got it a few days ago. Curious thing I noticed: When the install script runs, it asks for ip addresses in the form of: xxx.yyy.zzz.qqq. However, if I have an ip address like 129.65.90.12, and I pad it with zeroes like this: 129.065.090.012, the telnet and ftp programs (possibly others) come up with some *funky* numbers for the ip address, like 129.51.12.33 or something. Has anybody else noticed this? -- Joe Emenaker - Sexual Engineer | Our infernal mailer daemon has been quite jemenake@oboe.calpoly.edu | insistent that my signature be limited to just ..or.. @bslab65.calpoly.edu | 4 lines. However, as you can see, I have ..or.. @cash.calpoly.edu | figured out an elegant way to put as many as ------------------------------ From: mfp+@CS.CMU.EDU (Michael Polis) Subject: Re: Andrew File System Date: Fri, 22 Oct 1993 21:10:40 GMT In article , hsu@cs.hut.fi (Heikki Suonsivu) writes: |> |> In article Court Demas writes: |> AFS sucks anyways. Use NFS :-) |> |> AFS would be better than NFS, but I don't see what is the point of trying |> to be compatible with AFS which isn't used anywhere % ls /afs Uni-freiburg.de ece nsf-centers.edu VFL.Paramax.com ece.cmu.edu others.chalmers.se alw.nih.gov es.net palo_alto.hpl.hp.com amstest ethz.ch pegasus.cranfield.ac.uk amstest.cs.cmu.edu fnal.gov pitt.edu andrew gr.osf.org pittsburgh.ibm.com andrew.cmu.edu grand.central.org psc.edu anl.gov graphics.cornell.edu pub.nsa.hp.com athena.mit.edu hepafs1.hep.net rel-eng.athena.mit.edu bcc.ac.uk hrzone.th-darmstadt.de rhrk.uni-kl.de bstars.com huge.psc.edu ri.osf.org bu.edu iastate.edu rose-hulman.edu cards.com inel.gov rpi.edu ce.cmu.edu ipp-garching.mpg.de rrz.uni-koeln.de cern.ch ir.stanford.edu rus.uni-stuttgart.de cheme isi.edu sfc.keio.ac.jp cheme.cmu.edu jrc.flinders.edu.au sipb.mit.edu ciesin.org kiewit.dartmouth.edu spc.uchicago.edu citi.umich.edu lrz-muenchen.de ssc.gov club.cc.cmu.edu lsa.umich.edu stars.com cmf.nrl.navy.mil math.lsa.umich.edu stars.reston.unisys.com cmu.edu me test cs me.cmu.edu test.alw.nih.gov cs.arizona.edu media-lab.mit.edu test.cs.cmu.edu cs.brown.edu msc.cornell.edu theory.cornell.edu cs.cmu.edu mtxinu.com titech.ac.jp cs.cornell.edu nada.kth.se tmpcmu cs.unc.edu ncat.edu transarc.com cs.utah.edu nce ucop.edu cs.washington.edu nce_ctc umich.edu cs.wisc.edu nce_psc uni-freiburg.de css.cs.utah.edu ncsa.uiuc.edu urz.uni-heidelberg.de ctd.ornl.gov nd.edu vfl.paramax.com ctp.se.ibm.com nersc.gov wam.umd.edu dmsv.med.umich.edu net.mit.edu dsg.stanford.edu northstar.dartmouth.edu I guess not. :-) At least not anywhere in Finland. NFS is used more widely because setting up a server is trivial and clients are shipped with every self-respecting networking package. AFS is most useful when you want to have a lot of clients beating on a single server. The only reason you'd want AFS on linux is to access existing servers. Caching is good, especially if you only have a SLIP line. You can probably get by with the AFS to NFS translator. An AFS port is unlikely, at least from Transarc. Probably what would have to happen is that someone with a source license would have to port it and donate the port to Transarc. "Someone" probably isn't CMU, since Mach is an option around here if you want to blow the disk space. ------------------------------ ** FOR YOUR REFERENCE ** The service address, to which questions about the list itself and requests to be added to or deleted from it should be directed, is: Internet: Linux-Development-Request@NEWS-DIGESTS.MIT.EDU You can send mail to the entire list (and comp.os.linux.development) via: Internet: Linux-Development@NEWS-DIGESTS.MIT.EDU Linux may be obtained via one of these FTP sites: nic.funet.fi pub/OS/Linux tsx-11.mit.edu pub/linux sunsite.unc.edu pub/Linux End of Linux-Development Digest ******************************