From: Digestifier To: Linux-Development@senator-bedfellow.mit.edu Reply-To: Linux-Development@senator-bedfellow.mit.edu Date: Sat, 27 Nov 93 20:13:15 EST Subject: Linux-Development Digest #265 Linux-Development Digest #265, Volume #1 Sat, 27 Nov 93 20:13:15 EST Contents: Re: Free Software and Motif (was: Re: Don't use Motif for free sw:...) (Eric Bina) Errors when compiling Elm 2.4.23 under Linux? (Peter Robinson) Problem in tcp.c??? (Ge van Geldorp) New Shared Tcl/Tk Libraries for Linux (David Engel) Re: Creeping featuritis (post --rant --flame) (Brandon S. Allbery) Re: Errors when compiling Elm 2.4.23 under Linux? (Vince Skahan) PCI support (Sean Sun) Re: crap xconfig comments (John E. Krokes) Re: PCI support (Drew Eckhardt) ---------------------------------------------------------------------------- From: ebina@ncsa.uiuc.edu (Eric Bina) Crossposted-To: comp.infosystems.www,comp.windows.x,comp.windows.x.i386unix,comp.windows.x.motif,gnu.misc.discuss,comp.sources.d Subject: Re: Free Software and Motif (was: Re: Don't use Motif for free sw:...) Date: 27 Nov 1993 11:45:22 GMT In article <2d2o18$nem@news.acns.nwu.edu>, john@hopf.math.nwu.edu (John Franks) writes: |> In article hops@x.co.uk (Mike Hopkirk) writes: |> > |> >Darrel Crow OSF/Motif Technology manager just posted a human readable |> >clarification of the Motif 2.0 licensing to the motif-talk mailing list |> >( If it doesn't get out to the newsgroup I'll see if its ok to repost it ) |> > |> >Following is ( I hope ) a precis of the main points of his posting vis a vis |> >PD/Freely distributed (binary) software( emphasises and errors omissions |> >are mine ). |> > |> |> ... Precis omitted ... |> |> If this account is accurate it is very disturbing. It says that NCSA |> is not complying with their license when they distribute Xmosaic |> statically linked binaries without a notice that users are required to |> have a Motif license. They can comply by including such a license, |> but anyone who uses such a binary on a computer without a Motif |> license will be liable to suit by OSF. The fact that NCSA has an |> educational license is only relevant for their INTERNAL use. |> |> In particular, academic and commercial institutions who are very careful |> about subjecting themselves to liability will be unwilling to use Xmosaic on |> any CPU without a Motif license. This must include nearly all Suns in |> existence today. Please pay CLOSE attention here! All the statically linked binaries we distribute (SUN, DEC, SGI) are compiled with Motif 1.1.4 which has a very different license restriction. The HP and RS6000 binaries ary Dynamically linked. If you don't have the shared libraries on your machine, you are out of luck. Eric |> |> |> |> |> John Franks Dept of Math. Northwestern University |> john@math.nwu.edu |> ------------------------------ From: peter@palace.DIALix.oz.au (Peter Robinson) Subject: Errors when compiling Elm 2.4.23 under Linux? Date: Sat, 27 Nov 93 13:40:48 GMT greets... having some problems when attempting to compile elm 2.4.23 under linux. below is a cut-down log of the make process... [ makelog ] cd lib; /usr/bin/make - all make[1]: Entering directory `/home/peter/elm/lib' /bin/chmod u+w ../hdrs/defs.h /bin/touch ../hdrs/defs.h /bin/chmod u+w ../hdrs/headers.h /bin/touch ../hdrs/headers.h cc -O -I../hdrs -c add_site.c -o add_site.o ... ... ... cc -O -I../hdrs -c tail_of.c -o tail_of.o cc -O -I../hdrs -c validname.c -o validname.o ar r libutil.a add_site.o addrmchusr.o atonum.o mk_aliases.o aliasdb.o mk_lockname.o can_access.o can_open.o chloc.o date_util.o errno.o expand.o figadrssee.o gcos_name.o get_tz.o getaddrfrm.o getarpdate.o getfullnam.o getword.o header_cmp.o in_list.o in_string.o istrcmp.o ldstate.o len_next.o mail_gets.o mcprt.o mcprtlib.o move_left.o ndbz.o okay_addr.o opt_utils.o parsarpdat.o parsarpwho.o posixsig.o putenv.o qstrings.o realfrom.o remfirstwd.o reverse.o safemalloc.o shiftlower.o strincmp.o striparens.o strtokq.o tail_of.o validname.o : libutil.a make[1]: Leaving directory `/home/peter/elm/lib' cd src; /usr/bin/make - all make[1]: Entering directory `/home/peter/elm/src' cc -O -I../hdrs -c addr_util.c -o addr_util.o cc -O -I../hdrs -c alias.c -o alias.o .. cc -O -I../hdrs -c editmsg.c -o editmsg.o /bin/chmod u+w ../hdrs/elm.h /bin/touch ../hdrs/elm.h cc -O -I../hdrs -c elm.c -o elm.o cc -O -I../hdrs -c encode.c -o encode.o cc -O -I../hdrs -c exitprog.c -o exitprog.o cc -O -I../hdrs -c expires.c -o expires.o ... ... ... cc -O -I../hdrs -c utils.c -o utils.o cc -O -I../hdrs -c wildcards.c -o wildcards.o cc -O -I../hdrs -c wordwrap.c -o wordwrap.o cc -o ../bin/elm addr_util.o alias.o aliaslib.o args.o a_edit.o a_screen.o a_sort.o a_quit.o bouncebk.o builtin.o calendar.o curses.o date.o delete.o edit.o editmsg.o elm.o encode.o exitprog.o expires.o file.o file_util.o fileio.o find_alias.o forms.o hdrconfg.o help.o in_utils.o init.o leavembox.o lock.o limit.o mailmsg1.o mailmsg2.o mime.o mkhdrs.o newmbox.o options.o out_utils.o pattern.o pmalloc.o quit.o read_rc.o remail.o reply.o returnadd.o save_opts.o savecopy.o screen.o showmsg.o showmsg_c.o signals.o softkeys.o sort.o string2.o strings.o syscall.o utils.o wildcards.o wordwrap.o ../lib/libutil.a -ltermcap (pretend that Undefined Symbol: is here..) vvvv ../lib/libutil.a(getarpdate.o): _get_tz_mins referenced from text segment ../lib/libutil.a(getarpdate.o): _get_tz_name referenced from text segment ../lib/libutil.a(parsarpdat.o): _cvt_dayname_to_daynum referenced from text segment ../lib/libutil.a(parsarpdat.o): _cvt_monthname_to_monthnum referenced from text segment ../lib/libutil.a(parsarpdat.o): _atonum referenced from text segment ../lib/libutil.a(parsarpdat.o): _cvt_timestr_to_hhmmss referenced from text segment ../lib/libutil.a(parsarpdat.o): _cvt_timezone_to_offset referenced from text segment ../lib/libutil.a(parsarpdat.o): _atonum referenced from text segment ../lib/libutil.a(parsarpdat.o): _atonum referenced from text segment ../lib/libutil.a(parsarpdat.o): _cvt_monthname_to_monthnum referenced from text segment ../lib/libutil.a(parsarpdat.o): _cvt_yearstr_to_yearnum referenced from text segment ../lib/libutil.a(parsarpdat.o): _cvt_timestr_to_hhmmss referenced from text segment ../lib/libutil.a(parsarpdat.o): _cvt_timezone_to_offset referenced from text segment ../lib/libutil.a(parsarpdat.o): _make_gmttime referenced from text segment ../lib/libutil.a(realfrom.o): _cvt_monthname_to_monthnum referenced from text segment ../lib/libutil.a(realfrom.o): _atonum referenced from text segment ../lib/libutil.a(realfrom.o): _cvt_timestr_to_hhmmss referenced from text segment ../lib/libutil.a(realfrom.o): _cvt_timezone_to_offset referenced from text segment ../lib/libutil.a(realfrom.o): _cvt_yearstr_to_yearnum referenced from text segment ../lib/libutil.a(realfrom.o): _make_gmttime referenced from text segment ../lib/libutil.a(tail_of.o): _addr_matches_user referenced from text segment ../lib/libutil.a(tail_of.o): _addr_matches_user referenced from text segment make[1]: *** [../bin/elm] Error 1 make[1]: Leaving directory `/home/peter/elm/src' make: *** [all] Error 1 If required, ask, and ye shall receive my config.sh and config.h... many thanks (btw: this is standard Elm, no 'patches') ============================================================================== One night I was lying in bed, looking up at the stars... Then I thought.... Where the hell is my roof?!?!? Peter Robinson Crystal Palace Software Yes, this isn't my peter@palace.DIALix.oz.au P.O. Box 396 SIG, but it'll do Victoria Park WA 6100 for now 8-) ============================================================================== ------------------------------ From: ge@dutlru.tudelft.nl (Ge van Geldorp) Subject: Problem in tcp.c??? Reply-To: Ge.vanGeldorp@lr.tudelft.nl Date: Sat, 27 Nov 1993 15:24:12 GMT Hello, I'm having a network problem which I believe is due to a problem in net/inet/tcp.c. However, I'm neither a Linux wizzard (only installed the system a week ago) nor a TCP/IP wizzard, so I could be very wrong. I'm using the Slackware 1.1.0 distribution. The tcp.c file I'm talking about has an id '@(#)tcp.c 1.0.16 05/25/93', ls -l shows 93/09/16 as the last-change date. Now to the problem. An application (actually it is a X client) is sending lots of packets, without doing any receiving. After a while, the application will block, unable to send more packets. This is NOT due to the receiving system being unable to accept more packets. What I found during debugging was the following scenario: a packet is sent from the Linux machine. The packet is acknowledged by the remote end: the remote end sends a packet with the ACK bit on, but without any data (I don't know the TCP-speak for this, but the packet consists of only a header). In Linux, the packet is picked up by the tcp_rcv() routine, which sees the ACK bit, calls tcp_ack(), which sees that the packet sent is received ok etc. All very fine so far. Then, tcp_rcv() will call tcp_data() to add the packet to the sockets rqueue. This means that the memory usage of the socket (as kept in sk->rmem_alloc) is increased by 120 (the size of the sk_buff) when tcp_rcv() returns. The next packet is sent by the Linux system, a new (otherwise empty) ACK packet comes in, the sockets memory usage is increased again etc. This goes on until yet another ACK packet is passed into tcp_rcv(), which (in the very beginning of the routine) checks the sockets memory usage against the upper limit SK_RMEM_MAX (which is 16k). Due to all the empty packets piled up, the test fails and tcp_rcv() drops the packet "due to lack of buffer space" as the DPRINTF says. Note that the tcp_ack() routine was not called. The application, which doesn't know about all this ACK business, happily continues to write to the socket. However, all ACKs from the remote end are dropped so at some stage the tcp code decides not to put the packet on the wire anymore but to store it in memory instead. As writing continues, the amount of allocated `write' memory is becomming larger than SK_WMEM_MAX (8k) and the write blocks. At this point, incoming ACKs from the remote end are dropped and the tcp_write is waiting for an ACK. Seems like a nice deadlock to me. If the application had done regular tcp_read()s, the above situation would not have developed. The tcp_read() would mark the empty ACKs as used, call cleanup_rbuf() which would dispose of the packets. The memory usage of the socket would drop, the next ACK to be received would be processed normally etc. However, this would mean that an application in order to be able to keep write()ing has to do a read() every now and then, which doesn't sound very logical to me. As stated in the beginning, I'm not 100% sure that the above analysis is correct. I can't believe all those people out there have been happily networking for a long time, while I run into a basic problem in my first week of Linux usage (it takes only 136 writes to fill up the receive buffer space with empty ACKs). Maybe someone who does understand all the TCP/IP stuff could give some comments? Thanks. Ge van Geldorp Ge.vanGeldorp@lr.tudelft.nl ------------------------------ Crossposted-To: comp.lang.tcl From: david@ods.com (David Engel) Subject: New Shared Tcl/Tk Libraries for Linux Date: Sat, 27 Nov 1993 16:45:24 GMT I've uploaded new versions of my Tcl/Tk shared libraries for Linux, along with source, to sunsite.unc.edu. You can find the following files in the /pub/Linux/devel/tcl directory: tcl7.3-bin.tar.z tcl7.3-src.tar.z tk3.6-bin.tar.z tk3.6-src.tar.z tclX7.3a-bin.tar.z tclX7.3a-src.tar.z blt1.0-bin.tar.z blt1.0-src.tar.z itcl1.3-bin.tar.z itcl1.3-src.tar.z All libraries require libc-4.4.4 or later. Additionally, the tk, blt and tkX (part of tclX) libraries also require XFree86-2.0 or later. Please report any problems or suggestions to me. David -- David Engel Optical Data Systems, Inc. david@ods.com 1101 E. Arapaho Road (214) 234-6400 Richardson, TX 75081 ------------------------------ Crossposted-To: gnu.misc.discuss From: bsa@kf8nh.wariat.org (Brandon S. Allbery) Subject: Re: Creeping featuritis (post --rant --flame) Date: Sat, 27 Nov 1993 16:17:21 GMT In article haley@scws6.harvard.edu (Elizabeth Haley) writes: >bsa@kf8nh.wariat.org (Brandon S. Allbery) writes: >Twould be nice, but what if the poor sod having to dearchive things is >not told it's multiple volume? All she's/he's left with is "Sudden >EOF!" True. The point was also raised about multivolume backups with a separate VTOC for each volume... but we're not talking about tar or cpio in that case anyway. ---But your user is *still* screwed if someone used Xenix's multivolume tar and tries to untar it on a Sun. The separate filter at least (presuming GNUware, the start of this discussion) could at least be ported and could become a de-facto standard. >>Actually, this usage is something of a holdover from the days when a "tty" was >>a KSR33... It's appropriate for e.g. "more" or "less" to do this, though. > >My tektronix 4107 terminal will not display > 127 ASCII Characters >either... It strips the eighth bit. I was speaking of using "cat" to display files. I think of "cat" as being a way to interpolate files into a pipeline; "more" and "less", etc. are used to display files. >>aiming for; business users tend to need a lot more special kernel routines >>than academic and research folks, which is one reason why SVR4 is so much >>larger than V7 and (earlier?) BSD. I tend to get into conflicts over this, > >I am curious, what kind of kernal routines do business users use that >academic types wouldn't? Let me rephrase: business users need, for performance reasons, things in the kernel which could be done outside it. An example is disk mirroring: most of the time, what should be mirrored is a database... and it's almost reasonable to give the DBMS a set of partitions (not filesystems) and let it do the mirroring itself. But unless the DBMS is given complete disks, each with a single partition, it can't reliably optimize reads by choosing the disk whose read/write heads are closest to the data to be read. (There are other examples, but they're negated by the use of smart disk controllers... and these days, anyone looking for top-speed database performance and *not* using an intelligent disk controller is merely working around a hardware performance bottleneck.) (Also, disk mirroring and disk striping *should* be done in *hardware*. Thankfully, RAID is now catching on in business...) There are other examples, which don't necessarily break down as academic vs. business, such as TCP/IP: just provide Ethernet drivers in the kernel and a variant of KA9Q that uses separate user processes for its servers and drivers. Performance will again suffer relative to the kernel version, however. (The point I'm getting at is that you can do quite a few things with *ix that seem to be commonly believed to require a microkernel architecture. But, with or without the microkernel, the trade-off is simplicity vs. performance.) >As a side note, how efficient is Mach with disk access, compared to >other things? Not having played with Mach itself, I can't answer that question directly... but I suspect the problems will be more in the path from the driver to the application (e.g. IPC details) than the driver. >It seems to me that businesses ought to consider hiring programmers to >make totally custom kernels if their business relies on fast >transaction management. Most of the computers can be standard boxes, It can be argued. Heck, it HAS been argued; this is one of the primary targets for mainframes. But commodity hardware is cheaper, and business is now trying to find ways to optimize *that* for transaction processing in order to "save money". ---In some ways *this* particular mess looks to me like a comedy of errors; I don't see "downsizing" as "rightsizing" when the business in question *needs* the transaction I/O performance of big iron. So the CPUs are slow; but in most common transaction processing applications the bottleneck is I/O, and *that*'s what is optimized. There are also the dedicated transaction processing machines (d*mn, I can't remember what the company's called now; used to be Britton-Lee). But again, it's not commodity hardware, and businesses trying to save money by switching to commodity hardware and/or by switching to open systems won't consider it. ++Brandon -- Brandon S. Allbery kf8nh@kf8nh.ampr.org bsa@kf8nh.wariat.org "MSDOS didn't get as bad as it is overnight -- it took over ten years of careful development." ---dmeggins@aix1.uottawa.ca ------------------------------ From: vince@victrola.wa.com (Vince Skahan) Subject: Re: Errors when compiling Elm 2.4.23 under Linux? Date: 27 Nov 1993 11:24:29 -0800 peter@palace.DIALix.oz.au (Peter Robinson) writes: >../lib/libutil.a(tail_of.o): _addr_matches_user referenced from text segment try "ranlib='ranlib'" in your config.sh file (Elm incorrectly assumes you don't have to run ranlib) to go from where you're at now, try "ranlib libutil.a" then another make and it'll link and run ok and you won't have to repeat the build. [...mild rant mode on...] this has been well documented in the linux mail HOWTO and previous faqs for at least 12 months.... -- ---------- Vince Skahan --------- vince@victrola.wa.com ------------- Today's words to delete from the English language: "Buttafuoco", "Bobbitt", "Michael Jackson" ------------------------------ Date: Sat, 27 Nov 1993 15:46:43 EST From: Sean Sun Subject: PCI support So how about it. Has any one tried the PCI machines with linux? Does it work properly. Is the performance any better? Sean. ------------------------------ From: bbfaus@wam.umd.edu (John E. Krokes) Subject: Re: crap xconfig comments Date: 27 Nov 1993 23:04:57 GMT In article , Brett Person wrote: >Well, I've never seen a monitor get fried by teeaking with the monitor >settings. I have seen OS/2 and other pieces of software do this trick to >calc frequencies. Under this logic, we should all quit using OS/2 and >Windows. > Amen to this! _____________________________________________________________________________ ( John E. Krokes -- "Mag" -- First Accolade to The One True Dave ) ) bbfaus@wam.umd.edu Most useful UNIX command: sleep 240 & ( (_____________________________________________________________________________) ------------------------------ From: drew@kinglear.cs.colorado.edu (Drew Eckhardt) Subject: Re: PCI support Date: Sun, 28 Nov 1993 00:15:42 GMT In article <93331.154643XXS105@psuvm.psu.edu>, Sean Sun wrote: >So how about it. Has any one tried the PCI machines with linux? Yes. >Does it work properly. Yes, although the NCR53c810 SCSI driver isn't finished yet. >Is the performance any better? Unknown. You'd have to take identical systems with the same chips on PCI / other boards to make that assesment. ------------------------------ ** 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 ******************************