Subject: Linux-Development Digest #555 From: Digestifier To: Linux-Development@senator-bedfellow.MIT.EDU Reply-To: Linux-Development@senator-bedfellow.MIT.EDU Date: Tue, 15 Mar 94 16:13:16 EST Linux-Development Digest #555, Volume #1 Tue, 15 Mar 94 16:13:16 EST Contents: Re: 127.x.x.x (was Re: UDP report card) (Alan Cox) Re: select (Alan Cox) gcc/ld linking static binaries!!!? (sunny yum) Re: [Q] Adaptec 2842 SCSI driver yet? (Tseng Yaw-yih) Re: DIP: tty: getc: I/O error (Alasdair Turnbull) Re: 127.x.x.x (was Re: UDP report card) (Erick Herring) HELP REDUCE TRAFFIC (was: Re: Help! GCC errors [STUPID IDIOTS ON COMP.OS.LINUX.* GROUPS]) (Andreas Klemm) Re: Help! GCC errors [STUPID IDIOTS ON COMP.OS.LINUX.* GROUPS] (Kai Petzke) Re: SVGALIB only as root ? (Kai Petzke) Re: select (Christian Mautner) Re: Problem with NET-2 and Winsock Gopher/HTTP clients? (Borries Demeler/Biophysics) Re: X11R6? (Richard Migneron) Problem while printing (Jens Frank 29206029) ---------------------------------------------------------------------------- Crossposted-To: comp.protocols.tcp-ip From: iiitac@uk.ac.swan.pyr (Alan Cox) Subject: Re: 127.x.x.x (was Re: UDP report card) Date: Tue, 15 Mar 1994 11:15:04 GMT In article imp@boulder.parcplace.com (Warner Losh) writes: >I know of at least two commercial versions of IP that have had bug >fixes applied to them that stop them from spitting out 127.* to the >wire. I'm not aware of anything that supplants this requirement in >RFC 1122. > >Any system that does spits 127.* to the wire is broken. Any system which when supposedly 'correctly configured' spits 127.* to the wire is broken. On that basis Linux is ok. On the other basis nothign is OK because as route I can force the issue anyway. Alan ------------------------------ From: iiitac@uk.ac.swan.pyr (Alan Cox) Subject: Re: select Date: Tue, 15 Mar 1994 11:16:52 GMT In article Robert Andrew Ryan writes: >What standard specifies select should write to the timeval? SunOS 4.1 >is the only system I've seen where it's even mentioned as a possible >future enhancement. I certainly agree it's a useful enhancement, but it >is incompatible with a great number of previous implementations. This >is a serious source of bugs for the unwary porting interactive network >programs. > What standard specifies select() in the first place 8-) The later BSD/SunOS manuals are quite clear on the matter of writing to the time interval. Anyone who doesn't do it properly gets burned and its their fault (me included!). Alan ------------------------------ From: syum@crusher.ucr.edu (sunny yum) Subject: gcc/ld linking static binaries!!!? Date: 14 Mar 1994 22:40:06 GMT Lately I've been noticing some annoying behavior with gcc/ld during the linking phase... It appears as if gcc/ld is linking some of my binaries statically, although I have not passed any arguments to gcc/ld specifically indicating that I would like it to do so! I have gcc 2.5.8 and the ld that came with the 1.9.3 binutils (I believe). This behavior (linking things statically w/o me telling it to do so) seems to be assoicated with the order in whic libraries are specified for linking on the command line. Ex: gcc file.o -o file -ltermcap mylib.a might cause a static binary to be produced, where gcc file.o -o file mylib.a -ltermcap will create a shared binary... In a few other cases, I can't get a shared binary at all! (Ex: at2.6b compiles statically). Am I doing something wrong... is this a bug, or what? -- Sunny D. Yum (syum@ucrengr.ucr.edu) Any opinions expressed are mine alone ------------------------------ From: u800307@Winkie.Oz.nthu.edu.tw (Tseng Yaw-yih) Subject: Re: [Q] Adaptec 2842 SCSI driver yet? Date: 15 Mar 1994 13:12:27 GMT Mark Biegler (biegler@aristotle.cs.uregina.ca) wrote: > Hello, > Is the Adaptec 2842 SCSI driver available yet? The Hardware-HOWTO > doesn't mention it, and the SCSI-HOWTO states that's it's being worked > on, but both are a bit out of date. As well, the Slackware SCSI > bootdisk doesn't seem to have it as an option. > We will be making a few computer acquisitions and would like to use > this adaptor with Linux, but I need information ASAP. I'd hate to > have to buy something else if it's only a month away. > Thanks muchly, > Mark Biegler > ----- > Mark Biegler (VE5MPB) biegler@cs.uregina.ca > Department of Computer Science W: (306) 585-4110 > University of Regina H: (306) 522-1770 > Regina, Saskatchewan Canada S4S 0A2 Office: CW 307.12 Hello,I have the same problem. I would rather buy a 1542CF if I had known the driver is not avaliable yet. If you have the driver someday,please mail to me. my E-mail is u800307@winkie.oz.nthu.edu.tw Thank you very much !!! ------------------------------ From: aturnbul@morgan.ucs.mun.ca (Alasdair Turnbull) Subject: Re: DIP: tty: getc: I/O error Date: 14 Mar 1994 21:18:00 GMT Sorry if this is a FAQ (I read it and numerous howto's and didn't find it). I recently installed Slackware and, after getting getty_ps, started up my machine with a getty_ps watching ttyS1 (a Sportster 14400) at 38400. The first call in after reboot always gets hung up just after connection (no message from getty_ps). All future calls work fine. Second problem: I followed the advice in the Net-2-FAQ about setting up SLIP clients and servers. I can call in and establish my DIP connection but several things are wrong. First, once the DIP connection is established, I can't actually do anything with TCP/IP on the client side. For example, telnet host.slip.server.ca says Connected... but nothing ever comes back. Second, if the client eventually gets DIP to drop the connection, the getty_ps watching ttyS1 never gets respawned so the line never answers again (until reboot). Help! (these DIP problems probably stem from a lack of understanding. For example, what is the mtu number? What should it be on the server? On the client?) Many thanks. Alasdair aturnbul@morgan.ucs.mun.ca ------------------------------ From: herring@iesd.auc.dk (Erick Herring) Subject: Re: 127.x.x.x (was Re: UDP report card) Date: 14 Mar 1994 21:44:20 GMT >>>>> "CHedrick" == Charles Hedrick writes: CHedrick> Under 0.99pl15 and later, the kernel does not make CHedrick> routing entries. Your startup script is expected to do CHedrick> so. That's not specific to 127. It's true for all CHedrick> networks. I think that this is bad -- 127.xxx.xxx.xxx should _never_ be on the wire. This is required. It seems to make more sense for the kernel to populate the routing table with the special cases in RFC 1122 (3.2.1.3 Addressing: RFC-791 Section 3.2). This behavior should never be dependent upon the (possibly bad) setup of some machine. CHedrick> After some thought I believe I agree with Linus that CHedrick> enabling an interface shouldn't create a route. That's CHedrick> the job of the route command. There are different ways CHedrick> one might want to set up the route. I doin't think that enabling an interface should create a route, either. But I do think that the kernel should be responsible for ensuring the special cases. CHedrick> 2) The RFC is clear that 127 addresses should never CHedrick> appear outside the host. I don't believe it was CHedrick> intended to say that they have to be implemented on the CHedrick> host. That is, one could simply drop all packets to CHedrick> 127, and not receive any of them. I personally consider CHedrick> 127 to be a class A network with exactly one host on it, CHedrick> 127.0.0.1. I believe that any other 127 address should CHedrick> be considered "host unreachable". But the point being CHedrick> made by the RFC's is: whatever you do with 127 on your CHedrick> machine, no address involving it should show up outside CHedrick> your machine. In the Linux context, the easiest way to CHedrick> do that is with CHedrick> route add 127.0.0.0 dev lo I guess that I agree in principle, but I don't think that shoving the responsibility for something important over to the sysadmin is wise. As I pointed out in my previous post, the entry in DNS is 0.0.127.in-addr.arpa. That means that if 127.0.0.2 goes to the nameserver, the response is going to be "localhost". CHedrick> One could argue that rc.local is part of the system as a CHedrick> whole, and it's the responsibility of the people CHedrick> creating setup scripts to make sure that the loopback CHedrick> interface is always turned on properly. I guess I'd be CHedrick> willing to accept that, but it would make me feel CHedrick> slightly better to know that 127 will never leave the CHedrick> machine. I really think that we are in violent agreement about this -- the question, then, is how do we keep them off of the wire? Regards, Erick ------------------------------ From: andreas@knobel.knirsch.de (Andreas Klemm) Crossposted-To: alt.pud,alt.stupidity Subject: HELP REDUCE TRAFFIC (was: Re: Help! GCC errors [STUPID IDIOTS ON COMP.OS.LINUX.* GROUPS]) Date: 15 Mar 1994 13:28:01 GMT : I am being repressed. (crfisher@nyx10.cs.du.edu) wrote: : In article <2kvr8o$4iv@senator-bedfellow.mit.edu>, : Mitchum DSouza wrote: : >Dean Junk: : > Do one of the following: : > : >1) Read the library release notes TO THE LETTER - EVERY SINGLE SENTENCE. : >2) Read the GCC-FAQ before asking GCC related queries. : > : >Mitch : WHAT IS THE POINT IN REPLYING IF YOU DO NOT KNOW THE ANSWER? : Although it may seem that every newsgroup in the c.o.l.* : series actually have the word flame in them, they do not. I am so : sick of the petty replies and responses I see here all the time. : If you can not help someone then do not bother to even reply. You : do no one any good when you do. All you do is waste resources : and show that you don't even know hot to flame properly. Hey ! Please don't be so angry about people who say more or less RTFM first. Please remember some facts ;-) - The amount of traffic in c.o.l.* is enormous - There are so many newcomer questions that are FAQ's - There are so many "poor quality" subjects which makes reading/helping very hard ! Suppose you have an amount of 30 minutes a day, to ANSWER BEGINNER QUESTIONS. WHAT WOULD YOU DO in newsgroups, where several hundreds (thousands ?! ;-) of people are waiting for help ??? - answer only SOME questions verbousely - or answer MUCH MORE questions by telling people what doc gives help on that topic ? Besides it's BOARING to answer the same questions again and again in a verbose way. If there is good docu available, a pointer should be ENOUGH. Don't think I'm an impatient soul or an arrogant expert. No ! Please read this under the background, that there *is* good docu available and people should try to read it first. So many people have spend hours of their free time to make this help available to newcomers .. but so many people do ignore that again and again .. It seems to be more convenient to ask other people. This INDOLENT MANNER brings us the hundred's of UNNECCESSARY POSTINGS. "Help me, I'm a consumer" ;-) It makes no fun reading overcrowded newsgroups. The few articles or threads with good Subjects, questions of general interest are hidden by the mass of - let me simply say - shit. Another thing is, that nearly all unmoderated linux newsgroups contain so MANY ARTICLES WITH BAD SUBJECTS, that you have NO CHANCE to recognize, if the question was ALREADY ASKED by another person. HARD TIMES THESE DAYS !!! Here some suggestions, that could help minimize the traffic additionally. I personally think that the idea of the "AUTO MODERATION" off certain groups (see CURRENT VOTING) is a good idea. But PACKAGE MAINTAINGER could also do some good things, to PREVENT hundreds of unnecessary or unnecessary bad (-> quality of subjects) articles: HI PACKAGE MAINTAINERS !!! ,-) WHAT ABOUT THE FOLLOWING PROPOSALS: a) force people to install manual pages or available FAQ's, HOWTO's and ghostscript during the installation (ghostscript -gs- for printing postscript files). b) Write people (root) a greetings mail after a successfull installation. It should include the following topics: - how to get help in Linux (man, xman, info, xinfo) - location of available documents (faq's, howto's) - how to print the docu - printer setup - - how can I print postscript files on a non PS printer (how to use gs as a filter) - explain to them, that linux newsgroups are overcrowded, so they should read locally installed docu firs, instead of waiting for an answer that points them to that docu if it's a faq ;-) - if posting for help, explain user, that he should choose a significant Subject (not only "need help"). [ perhaps include apsfilter ( printer filter with file type auto recognition) into your package, so people can print ps and dvi files automagically ] c) Include in /etc/motd or /etc/issue a note, where system specific End User Docu is locally installed. "Please note, that lot's of documentation is installed in /usr/doc. Please read it first instead of posting the 1001st frequently asked question" d) distribute an initial news database (for cnews or inn) that contains the up to data faq's in a separate newsgroup read.me.first or such, that won't be expired.... e) include in /etc/profile a line to fire up the systems favourite newsreaderwith this group read.me.first. Hope that could help a bit avoiding faq's and perhaps some annoyances, too. Andreas /// -- Andreas Klemm /\/\____ Wiechers & Partner Datentechnik GmbH andreas@knobel.knirsch.de ___/\/\/ andreas@wupmon.wup.de (Unix Support) ------------------------------ From: wpp@marie.physik.tu-berlin.de (Kai Petzke) Subject: Re: Help! GCC errors [STUPID IDIOTS ON COMP.OS.LINUX.* GROUPS] Date: 15 Mar 94 12:41:26 GMT kevin@frobozz.sccsi.com (Kevin Brown) writes: >In article jhenders@jonh.wimsey.com (John Henders) writes: >>crfisher@nyx10.cs.du.edu (I am being repressed.) writes: >> So it helps people to encourage them to post to the wrong group, >>does it? what about the people who are trying to use the group for the >>reason it was created? Don't they count, in your worldview? >There is no good answer to this problem. Part of the reason it exists to >begin with is that comp.os.linux.development is badly named because a lot >of people wanted to be "cute" and have the abbreviation come out c.o.l.d. >(otherwise, they would have been more sensible and just named the group >comp.os.linux.kernel, ... Crerating a group comp.os.linux.kernel will not stop any problem. People will start asking their kernel related questions in it. There is only one change: follow-up on each misplaces article on c.o.l.d, saying, that this is the wrong group to place this article, and that you would be happy to answer, if the question is reposted to the right group. But you need a somewhat flame-proof asbestos west, if you do that regularly. -- Kai Petzke Advertisement by Microsoft in a well-known German magazine: If you don't like our programmes, then make your own ones. However, they expect you to use Microsoft products for this -:) ------------------------------ From: wpp@marie.physik.tu-berlin.de (Kai Petzke) Subject: Re: SVGALIB only as root ? Date: 15 Mar 94 12:47:33 GMT d16i@zfn.uni-bremen.de (Ralf Wirdemann) writes: >Hi, >I have some problmes with my SVGALIB. I cant execute >the programms, which use this lib. I allways get the >message "svgalib: i/o permission denied". This porblems doesnt >occurs as root. Does anybody know a solution ? >Thanks in advance, Ralf. Please avoid asking questions in comp.os.linux.development. This group was once created to discuss the development of linux as a whole, and not your particular problem. -- Kai Petzke Advertisement by Microsoft in a well-known German magazine: If you don't like our programmes, then make your own ones. However, they expect you to use Microsoft products for this -:) ------------------------------ From: chm@vlsivie.tuwien.ac.at (Christian Mautner) Subject: Re: select Date: 15 Mar 1994 13:22:01 GMT : The behaviour that is exhibited is that the select returns immediately, with a : value of 1 (i.e., one FD ready). : A subsequent recvfrom system call on the `ready' FD returns the error : ECONNREFUSED (which is a TCP -level error message on a UDP system call). I had the same problem once, I tried to select(2) a SOCK_DGRAM-Socket, and, well, it showed exactly the same behavior: select returns 'yes' ;), and when I recvfrom(2)ed, I got 'connection refused.' This was with Slackware 1.1.1 (99.14) and I didn't try it again with a newer kernel. The same program worked on a sun without any problems and as expected. It was surely not a problem of writing to the timeout-variable. cu chm. -- spacethefinalfrontierthesearethevoyagesofstarshipenterpriseitscontinuingmission toexplorestrangenewworldstoseekoutnewlifeandnewcivilisationtoboldlygowherenoone hasgonebefore ---------------------------------------- chm@vlsivie.tuwien.ac.at ------------------------------ From: demeler@selway.umt.edu (Borries Demeler/Biophysics) Subject: Re: Problem with NET-2 and Winsock Gopher/HTTP clients? Date: Tue, 15 Mar 1994 15:06:23 GMT In article <1994Mar11.112959.15393@sun0.urz.uni-heidelberg.de>, Andreas Helke wrote: >Steven Kirby (kirby@scarlett.libs.uga.edu) wrote: > >This problem might be related to telnet hangs when telneting from a pc with >crynwr packet drivers and Clarkson univerity telnet or winqvt telnet with >winsock.dll to a linux computer. I in general get a hanging connection when >scrolling too fast. Changing to v mode in elvis and holding the cursor down I'm experiencing the same problem (winqvt/trumpet winsock dll, pl15) although acceptable, since the problem can be avoided by scrolling somewhat slower. When connecting to an Ultrix DEC I never experience the problem. My setup is 486-50/8 MB Ram/20 MB Swap/SMC Elite/thin net. -Borries Demeler ------------------------------ From: adopt@CAM.ORG (Richard Migneron) Subject: Re: X11R6? Date: 13 Mar 1994 18:39:14 -0500 floyd@myhost.subdomain.domain (Christian Pablo Tagtachian) writes: >: The X11R6 source-code has not been released to the public and is >: currently only available to X Consortium members. The source is >: scheduled to be released on April 15. >Does anyone know where to get information about it? New features... etc..? >Thank you very much. Yes, in "The X Journal" of a while back (2-4 months ago) Richard ------------------------------ From: frank@namu06.gwdg.de (Jens Frank 29206029) Subject: Problem while printing Date: 15 Mar 1994 16:24:31 GMT I was printing some bigger file with 'cat foo>/dev/lp1'. Then some program, I suppose sync, accessed the hard drive. Instantly the printer got confused, turned off his status display, and refused any cooperation until I turned it off. This behaviour was reproducable. The printer-port and the IDE-controller share the same board, one of these All-In-One-IO-Cards. Does anyone know a) Why this happens ? and even more important b) How to fix it ? ============================================================================ jens frank, Goettingen, Germany frank@namu01.gwdg.de ------------------------------ ** 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 ******************************