From: Digestifier To: Linux-Development@senator-bedfellow.mit.edu Reply-To: Linux-Development@senator-bedfellow.mit.edu Date: Fri, 24 Sep 93 17:13:29 EDT Subject: Linux-Development Digest #125 Linux-Development Digest #125, Volume #1 Fri, 24 Sep 93 17:13:29 EDT Contents: Re: Net-2 Patches are GREAT (sometimes) (Alan Cox) Re: GPL and Linux device drivers (Eric J. Korpela) Re: /config (Bill C. Riemers) Re: /config (Bill C. Riemers) Re: Has any progress been made on the net-2 programs since May? (Brian McCauley) Re: term between AIX-Linux (Weimin Zhao) Re: Net-2 Patches are GREAT (Billy L. Williams Jr.) Re: Linux Slowly Dying Off? + Lets make a game for Linux (A Wizard of Earth C) Re: To all device driver writers; boot-time messages. (Guru Aleph_Null) Re: IPX Router Docs (J. Douglas Smith) Re: To all device driver writers; boot-time messages. (Herb Peyerl) Re: Bug in Kernel.99pl12? (Quota) (Marco van Wieringen) Re: ftp and ftpd pretty broke (Superuser) ---------------------------------------------------------------------------- Crossposted-To: comp.os.linux.misc From: iiitac@swan.pyr (Alan Cox) Subject: Re: Net-2 Patches are GREAT (sometimes) Date: Fri, 24 Sep 1993 17:35:47 GMT In article jan@swi.psy.uva.nl (Jan Wielemaker) writes: >jmorriso@rflab.ee.ubc.ca (John Paul Morrison) writes: >>the newest pl13 source and followed the net2-debugged instructions. The >>instructions tell you to move your inet directory, then unpack the new >>code. No Makefile or CONFIG is included with net2-debugged, so I >>assume you are supposed to copy the old ones (from inet.old!). I forgot to mention this. The new release when it comes out will have that corrected (and a few other oddments). >Tried exactly the same. I've got no network at home, but we're trying to >get the network stuff going at the University. Even using the loopback >net, just `rlogin myself' followed by logout crashed the system without >any message!? At least that works on plain pl13. Now I trust that the >inet-D package is debugged, but how does one get it *properly* linked >to the kernel? Nope you've found a bug. It took me 4 machines and about 40 rlogin attempts to duplicate it, but on some systems if you rlogin to localhost and the rlogin immediately screws up (as the rlogind/rlogin client pair of old tended too) you on odd occasion get a crash. This sort of thing illustrates how hard network debugging is, and why the real all new networking is taking so long. [Someone else asked how does NET2debugged fit in with the new networking. The answer is every relevant bug fix I've made has been fed back to the new networking people and most accepted and added. In time Net2debugged will no longer be neccessary and for once not being needed will make me happy! >The first thing I want are *reliable* remote running X11 applications. Try net2debugged on a real net. I don't release it until its had 3 days on a real machine doing real work on a busy net (40K/second broadcast packets + all the normal stuff). I've added local rlogin to my test list for the future and started looking at it except for that it does seem pretty much ok from reports so far apart from one other extra printk that crept in (udp.c udp_rcv kill the printk about Packet received for unknown socket). I've been using net2debugged heavily for X and its been quite good - I even test mpeg_play to a remote host as standard. >The second thing I want is nfs. NIS would be the greatest! NFS has been solid (but none too quick) since 0.99.11 (I think) 0.99.10 certainly had a memory corrupting bug. Over slip you need to turn on udp checksums and unless you have net2debugged set the slip mtu to about 1200 before not after you use dip to connect (goes for NET2E4 also) > Thanks --- Jan Thanks for finding a bug. I know where most of this evening will be going now 8-). Alan iiitac@pyr.swan.ac.uk ------------------------------ From: korpela@mofo.ssl.berkeley.edu (Eric J. Korpela) Crossposted-To: gnu.misc.discuss Subject: Re: GPL and Linux device drivers Date: 24 Sep 1993 17:49:24 GMT In article <1993Sep24.093444.4684@swan.pyr> iiitac@swan.pyr (Alan Cox) writes: > If I >write a program for MSDOS I'm not subject to microsofts rules either I just thought I'd point out that Microsoft thinks that you are required to follow their rules and pay them for the privilege. (Note the MS vs STAC case, where MS feels that replacing a part of their OS is copyright infringement. Also note that the part the STACKER replaces is a part that MS probably stole from STAC anyway. (ie the STAC vs MS case)) If competition isn't working for us litigate them out of existence! -Corporate motto for Apple, Microsoft, Lotus, etc., and so forth. -- Eric Korpela | The two most common things in the korpela@ssl.berkeley.edu | universe are Hydrogen and stupidity. | -Harlan Ellison ------------------------------ From: bcr@bohr.physics.purdue.edu (Bill C. Riemers) Subject: Re: /config Date: 24 Sep 93 16:16:23 GMT In article <27tkpq$i0r@senator-bedfellow.MIT.EDU> dthumim@athena.mit.edu (Daniel J Thumim) writes: >I was just following the discussion on the /config proposal, and it seems >that everyone has a different idea of what's being talked about. >Thus, in effect, the /config directory becomes a source tree for config- >uration files, and the translation utilities are used to "compile" the >useable config programs from the sources. Sounds way overly complicated. I expect this would: 1. Not significantly simplify configurations 2. Increase the amount of work needed to upgrade. Not only do you need to upgrade the programs and the /config files, but you also need to update the translating problem 3. Add one more place for bugs. My configuration doesn't work... was it a /config problem, a translating problem, or a problem with the program itself. 4. Adds another more documentation to read. (i.e. I want to modify lilo. Now I need to read lilo documentation and /config documentation.) If you really want to simplify configuration, simplify configuration, simplify improve the programs using the actual configuration files. If you wish to centralize where configuration files are kept, make a directory in /etc. (There are already to many root level directories as is. This makes it difficult to split the system across separate partitions and hard-drives.) Bill ------------------------------ From: bcr@bohr.physics.purdue.edu (Bill C. Riemers) Subject: Re: /config Date: 24 Sep 93 16:21:37 GMT In article <13011@dirac.physics.purdue.edu bcr@bohr.physics.purdue.edu (Bill C. Riemers) writes: In article <27tkpq$i0r@senator-bedfellow.MIT.EDU> dthumim@athena.mit.edu (Daniel J Thumim) writes: >I was just following the discussion on the /config proposal, and it seems >that everyone has a different idea of what's being talked about. >Thus, in effect, the /config directory becomes a source tree for config- >uration files, and the translation utilities are used to "compile" the >useable config programs from the sources. Sounds way overly complicated. I expect this would: 1. Not significantly simplify configurations. 2. Increase the amount of work needed to upgrade. Not only do you need to upgrade the programs and the /config files, but you also need to update the translating problem. 3. Add one more place for bugs. My configuration doesn't work... was it a /config problem, a translating problem, or a problem with the program itself. 4. Adds another document to read. (i.e. I want to modify lilo. Now I need to read lilo documentation and /config documentation.) Obcourse you can argue that I won't need to use /config, but if it exists some programmers will assume everyone has it and stop trying to make raw config files easy to understand and modify. If you really want to simplify configuration, then improve the programs using the configuration files. If you wish to centralize where configuration files are kept, make a directory in /etc. (There are already to many root level directories as is. This makes it difficult to split the system across separate partitions and hard-drives.) Bill ------------------------------ From: bam@wcl-l.bham.ac.uk (Brian McCauley) Subject: Re: Has any progress been made on the net-2 programs since May? Date: 24 Sep 1993 18:27:33 GMT Reply-To: B.A.McCauley@bham.ac.uk I'm moving this thread from c.o.l.help as I think it is now definitely a c.o.l.development issue. In article <1993Sep24.122320.21768@swan.pyr> iiitac@swan.pyr (Alan Cox) writes: In article B.A.McCauley@bham.ac.uk writes: >I've looked of sunsite, funet and tsx-11 for the newest net-2 sources >(for the daemons and clients) but I can find nothing dated after May. Most of the daemons and clients (rlogin/telnet and co excepted) are reasonably ok. Much more work has been going on in the network stack itself Yes but a number of relatively trivial bugs have been found and corrected why can these not net propagated back into the main public distribution. For example I found a 2 line fix to make ``lpr -p'' work and sent it in. I realise the net-2 developers may be busy working on kernel so perhaps we need somone who's not a kernel hacker (but a kernel hacker's mate :-) ) to take charge of updates to the source tree for these programs. >What finially convinced me that something was amiss was the note with >the README for the net-2-debugged stuff for pl13 saying that I'd need >to get the new telnet(d) to work with pl13. What new telnet(d)? What >am I doing wrong? The new telnetd/rlogind is nothing to do with the networking people. They are on athos.rutgers.edu in pub/linux. This is because bugs in the packet mode tty driver have been fixed. These were not uploaded to one of the standard archive as the author expressed (in the README) the same sentiment that I have just expressed that he'd rather see his fixes propagated back to the master source tree. Rather than see many versions of each utility on each archive. Perhaps a sensible approach would be to encourage people to at least submit patches for the net stuff and put these in the source directories alongside the 28th May sources. (Keeping the May 28th sources for the forseeable future). BTW is funet or tsx-11 the master copy? BTW2 please can someone explain why I can't communicate with mail-net. I subscribed to the tape channel long ago and I still get that but all messages I send to either the -request or the -owner address are ignored (they don't even bounce). -- \\ ( ) No Bullshit! | Email: B.A.McCauley@bham.ac.uk . _\\__[oo from | Voice: +44 21 471 3789 (home) .__/ \\ /\@ /~) /~[ /\/[ | +44 21 627 2171 (work) . l___\\ /~~) /~~[ / [ | Fax: +44 21 627 2175 (work) # ll l\\ ~~~~ ~ ~ ~ ~ | Snail: 197 Harborne Lane, B29 6SS, UK ###LL LL\\ (Brian McCauley) | ICBM: 52.5N 1.9W ------------------------------ From: wzhao@mcs.kent.edu (Weimin Zhao) Subject: Re: term between AIX-Linux Date: 24 Sep 93 19:11:51 GMT I'm running term1.07 on AIX 3 with my Linux box. At least, (multiple) trsh, txconn, and tupload are working, which are quite enough for me. When I compiled term, I added the following options to the xlc compiler, which were taken from its /etc/xlc.cfg: -qlanglvl=extended -qnoro -D_NONSTD_TYPES -D_NO_PROTO -D_BSD_INCLUDES \ -bnodelselect -U__STR__ -U__MATH__ I didn't understand at all what all these meant, but it worked for me. I did remember somebody over the net told me to check out the BSD configuration of the xlc compiler in that file. The compiler has a version of 1.2. -Weimin ------------------------------ From: williams@vierzk.bates.scarolina.edu (Billy L. Williams Jr.) Crossposted-To: comp.os.linux.misc Subject: Re: Net-2 Patches are GREAT Date: 24 Sep 1993 19:19:12 GMT In article , Jan Wielemaker wrote: >any message!? At least that works on plain pl13. Now I trust that the >inet-D package is debugged, but how does one get it *properly* linked >to the kernel? As per the README file, simply move your inet directory to inetd.old, then untar the new net distribution. The only oversight in the docs is that you'll have to copy the old Makefile and CONFIG files from the stock pl13 sources (make sure to change the net/inet/CONFIG and then "make config" in the top-level linux source directory as you would with any normal kernel). Have you tried this, and if so, how does it compile differently than the stock pl13 sources [are any files not getting compiled w/the new sources]? Billy L. Williams, Jr. -- Billy L. Williams, Jr. e-mail: williams@vierzk.bates.scarolina.edu University of South Carolina Master of International Business Candidate Try Linux--it will be the last OS you ever install............Go Cocks! ..................finger me for pgp key and more info.................. ------------------------------ Crossposted-To: comp.os.linux.help,comp.os.linux.misc From: terry@cs.weber.edu (A Wizard of Earth C) Subject: Re: Linux Slowly Dying Off? + Lets make a game for Linux Date: Fri, 24 Sep 93 19:23:54 GMT In article <1993Sep23.170927.22867@mnemosyne.cs.du.edu> jepler@nyx.cs.du.edu (Jeff Epler) writes: >It's still going -- I really doubt that anything could hurt Linux at >this time, except an possibly the simultaneous destruction of all x86 >chips in the world. (Of course, there's the 68K port...) Think of the benefit to mankind as a whole, though... Terry Lambert terry@icarus.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers. ------------------------------ From: spj@ukelele.gcr.com (Guru Aleph_Null) Subject: Re: To all device driver writers; boot-time messages. Date: Fri, 24 Sep 1993 19:42:42 GMT wirzeniu@kruuna.Helsinki.FI (Lars Wirzenius) writes: >nelson@crynwr.com (Russell Nelson) writes: >> I'd like to see a prefix, of say, "I:" for informative messages, "W:" >> for warnings (something is not standard, e.g. COM1 using IRQ 3), and >> "E:" for an actual drop-dead error, e.g. trying to mount a MS-DOS >> partition as root. >I quite agree with this suggestion, although I'd use slithgly longer >prefixes ("Info:", "Warning:", and "ERROR:", perhaps). Since most Linux boxes I assume are running on color displays, throw some color into there: green for "Info:", yellow for "Warning:" and red for "ERROR:". Gee, just like for traffic signals in the US. :) >What about making all merely informational bootup messages optional? >That would make the bootup screen less cluttered and it would be >easier to spot problems. How about teeing them into a file into /usr/log/boothistNN that say, keeps ten copies of the last reboot console-messages? >-- >Lars.Wirzenius@helsinki.fi (finger wirzeniu@klaava.helsinki.fi) >It doesn't matter who you are, it's what you do that takes you far. --Madonna -- ========================================================================= Simon "Guru Aleph-Null" Janes |... don't crespt the weasal ... |... just think of the master ... |... feel the grass, softly ... ------------------------------ From: jdsmith@novell.com (J. Douglas Smith) Subject: Re: IPX Router Docs Reply-To: jdsmith@novell.com Date: Fri, 24 Sep 1993 20:14:26 GMT In article <27s4sqINN56o@news.uwsuper.edu> pmcgilla@hp.uwsuper.edu (Mr. Patrick L. McGillan) writes: > The documentation metioned for the IPX router specs is available as a > postscript file (apprx 50 pages) from 129.123.1.44. This is also > netlab2.usu.edu and the path is netwire/novlib/11/ipxrtr.zip > > I would certainly love to jump in and help, but I am simply swamped in > work right now and don't even have time to upgrade to the latest kenels > let alone do any development. > > On my bookshelf I also have the Netware C interface for doing all kinds > of server things if you can help by getting the ipx packets out of the > machine. > Even if you had an IPX implementation, you still need to implement NetWare Core Protocol (NCP) on Linux. Without NCP (which is not freely available), you can't do anything on a NetWare file server (connections, access the file system, etc.). ------------------------------ From: hpeyerl@novatel.ca (Herb Peyerl) Subject: Re: To all device driver writers; boot-time messages. Date: 24 Sep 1993 20:39:46 GMT Guru Aleph_Null (spj@ukelele.gcr.com) wrote: : wirzeniu@kruuna.Helsinki.FI (Lars Wirzenius) writes: : Since most Linux boxes I assume are running on color displays, throw some : color into there: green for "Info:", yellow for "Warning:" and red for : "ERROR:". Gee, just like for traffic signals in the US. :) Actually; yeah. And you could also do color-postscript output for the "colour-console-printer" option. Lots of great ideas coming out. Keep 'em coming! -- hpeyerl@novatel.ca | NovAtel Commnications Ltd. hpeyerl@fsa.ca | ------------------------------ From: mvw@caution.cistron.nl.mugnet.org (Marco van Wieringen) Subject: Re: Bug in Kernel.99pl12? (Quota) Date: Fri, 24 Sep 93 20:18:40 In article <27ukrf$9pq@-a> stenger@zeus.uni-duisburg.de writes: >Has anybody any ideas? >Should I use a different quota-package (would be typical for SLS, where almost >nothing fits together)? If so, where? > Ok wait until next week and I will release a new set of diffs. The diffs that are used with sls are the ones I made for 0.99pl10. This weekend I will prepare the diffs for 0.99pl13 and send out a new package next week to sunsite and funet. This package should work ok for pl13 as I am already running it with the alpha pl13 kernel. When I upgrade to pl13 this weekend we will see if it works also for the original pl13 kernel. Watch for the announce on where to find it somewhere next week (If all goes well :-). Marco. M. v Wieringen -- ------------------------------ From: root@fusion.cuc.ab.ca (Superuser) Subject: Re: ftp and ftpd pretty broke Date: Fri, 24 Sep 1993 20:51:12 GMT urlichs@smurf.sub.org (Matthias Urlichs) writes: > In comp.os.linux.development, article , > clau@acs.ucalgary.ca (Christopher Lau) writes: > > > > That's because of the net-2 kernel in general.. I'm using the telnet and ftp > > clients from net-2 on a 0.99pl9 kernel, and the only problems I've had to date > > are the mput/mget and the wierd problem at login where the "331 Password > > required for .." message comes *after* the password prompt (Has anyone found > > a fix for this?? This is a particularly wierd problem since the source > > shows that the password prompt is printed *after* it tries to get the reply > > from the remote, but the opposite happens when you run it.. ) > > > This could be stdio buffering. The password prompt thing usually uses > /dev/tty instead of stdin/stdout, and if nobody flushes stdout... No, it's not, I thought this as well, but I put a couple of fflush() calls in there, and it didn't help any.. If anyone figures this out, please let us know. > -- > Don't force it, get a larger hammer. > --Anthony > -- > Matthias Urlichs \ XLink-POP Nürnberg | EMail: urlichs@smurf.sub.org > Schleiermacherstrasse 12 \ Unix+Linux+Mac | Phone: please use email... > 90491 Nürnberg (Germany) \ Consulting+Networking+Programming+etc'ing c4 -- Christopher Lau- "Mr. Unix" | / Fusion: Playing With Fire! StarBright Research | / / H + H -> He + 24 MeV -- | /_/_/_ "Bring back Trudeau!" root,lauc@fusion.cuc.ab.ca |____________ "This space for rent" ------------------------------ ** 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 ******************************