From: Digestifier To: Linux-Development@senator-bedfellow.mit.edu Reply-To: Linux-Development@senator-bedfellow.mit.edu Date: Fri, 5 Nov 93 00:13:23 EST Subject: Linux-Development Digest #210 Linux-Development Digest #210, Volume #1 Fri, 5 Nov 93 00:13:23 EST Contents: Re: idea for TERM client (Bill C. Riemers) Re: WANTED: COBOL compiler (Masami Ogoshi) Re: WANTED: COBOL compiler (David L. Craig) Re: WANTED: COBOL compiler (David L. Craig) Re: new Berkeley DB - anyone? (Tommy Thorn) Re: What's wrong with a DOS to Linux disk a (Andrew R. Tefft) 16550A handling in serial.c (Tim Cutts (Zoology)) RPCGEN for Linux? (David Levine) Re: GCC crashing Linux: kernel bug (Karsten Steffens) Re: new Berkeley DB - anyone? (Rene COUGNENC) Re: WILL ???BSD DIE? (Brendan Murray) Re: WANTED: COBOL compiler (David S. Fox) [BUG?] ESDI driver or EXT2 FS problems (Todd Koeckeritz/Euler) Re: idea for TERM client (Kirby Koster) Re: RPCGEN for Linux? (Evmorfopoulos Dimitris) ---------------------------------------------------------------------------- From: bcr@bohr.physics.purdue.edu (Bill C. Riemers) Subject: Re: idea for TERM client Date: 4 Nov 93 02:49:00 GMT In article <2b9ndo$6ll@news.u.washington.edu> you write: >jhall@nmsu.edu (James A. Hall) writes: >>I agree you can turn off call waiting. However my wife gets really >>hacked when her friends tell her they tried to call but couldnt get >>through all night. I would love to have a dialer/redialer type >>client. It would start and stop term based upon the status of the >>line. > >Get an extra phone line. Come on now. The idea behind term is that everyone can use it. That is why it allows usable x-window connections at 2400 BPS, can use 7-bit lines, and doesn't require you to be root on the machines you use it on. You could argue: Get a slip connection with a decent modem... But then that defeats the idea of doing the most you can with the money/resources you already have. I think it is a good idea, and if I actually worried about recieving phone calls, I would right such a beast before resorting to paying the phone company: $100 for installation of a new line and $20 a month for the luxery of the extra phone line. Maybe your budget can handle that, but mine can't. Bill ------------------------------ From: ogochan@jh4tjwgw.jh4tjw.prug.or.jp (Masami Ogoshi) Crossposted-To: comp.os.linux.help Subject: Re: WANTED: COBOL compiler Date: 4 Nov 93 06:06:42 GMT Reply-To: ogochan@jh4tjwgw.jh4tjw.prug.or.jp (Masami Ogoshi) In article <1993Nov2.224954.1702@penrij.UUCP> soup@penrij.UUCP (John R. Campbell) writes: >Are you really serious? > >COBOL == Completely Obnoxious Boring Obsolescent Lanquage > >There are NO happy COBOL programmers (an obvious oxymoron). This message makes no body to happy. Your message has no effective answer. Many hacker don't like COBOL, but COBOL is used many appications. I know V-LSI CAD system written in COBOL. I know compiler written in COBOL. I know basic OS utility written in COBOL. I know expert system kernel written in COBOL. >Actually, I really should not be so sure that this won't be done. >After all, there's a GNU ADA project, so why not a GNU COBOL project >(other than requiring lots of anti-nausea medication). RMS wants Gnu COBOL compiler. But no one do it, then Gnu has no COBOLs. I'm tring it, but it is very hard. -- ogochan@jh4tjw.prug.or.jp Masami Ogoshi 109 Okudani-cho Matsue city Shimane pref 690 JAPAN ------------------------------ From: dlc@access.digex.net (David L. Craig) Crossposted-To: comp.os.linux.help Subject: Re: WANTED: COBOL compiler Date: 4 Nov 1993 08:20:07 -0500 In article , Benjamin Z. Goldsteen wrote: > And people wonder why Linux is not taken seriously...don't you >understand? If you expect to be taken as a serious alternative to a >commercial OS you can't laugh in your "customers" face when he asks if you >support xyz. The truth is that a lot of people of real programs written in >COBOL. For all SCO's weakness, I bet it has native COBOL, Fortran, C, C++, >Pascal, and Ada compilers that work. Indeed, Micro Focus COBOL runs under AIX, HP/UX, SCO on all manner of hardware, not to mention those other operating systems. While their compiler is written in COBOL (shock!), it is one of the more efficient COBOL compilers available (double shock!!). So maybe a COBOL compiler could be the real killer application to put Linux on the map. There are a mind-boggling number of batch- oriented mainframe applications about to be rightsized. I'd be very interested in seeing them make their product available for Linux. I would also be interested in hearing if a free compiler project is or might be happening. ------------------------------ From: dlc@access.digex.net (David L. Craig) Crossposted-To: comp.os.linux.help Subject: Re: WANTED: COBOL compiler Date: 4 Nov 1993 08:29:13 -0500 In article , Masami Ogoshi wrote: > RMS wants Gnu COBOL compiler. But no one do it, then Gnu has no COBOLs. > > I'm tring it, but it is very hard. Tell us more. Are you specifically developing a Linux COBOL compiler? ------------------------------ From: tthorn@daimi.aau.dk (Tommy Thorn) Subject: Re: new Berkeley DB - anyone? Date: 4 Nov 1993 16:05:46 +0100 buytaert@imec.be (Steven Buytaert) writes: > |chk@data-hh.Hanse.DE (Christian Kuhtz) writes: No it was me. > |I got it (db-1.6.tar.gz), but I haven't tried it yet. I don't remember > |where I got it from, but check the database FAQ. > If someone knows this ftp site & where to get it, could this person > please post this information ? Much obliged... RTFM. From "catalog of free databases" (news.answers): > name: The Berkeley DB code > version: 1.72 > interfaces: ndbm, hsearch > access methods: hash, b+tree, recno > multiuser: no > transactions: no > distributed: no > query language: none > limits: can handle large items > robustness: The db routines are used in some production code so they > are likely to work reasonably well. > description: The Berkeley DB Code is a unification of several previous > interfaces. It also forms the basis of a unified interface > to new access methods (b+tree, recno). > references: "A New Hashing Package for UNIX", Margo Seltzer, Ozan Yigit, > Proceedings of the Winter USENIX Conference, Dallas, TX, 1991. > Also available by ftp'ing pub/oz/hash.ps.Z from nexus.yorku.ca. "Document Processing in a Relational Database System, Michael > Stonebraker," Heidi Stettner, Joseph Kalash, Antonin Guttman, > Nadene Lynn, Memorandum No. UCB/ERL M82/32, May 1982. > "LIBTP: Portable, Modular Transactions for UNIX," Margo > Seltzer, Michael Olson, Proceedings 1992 Winter Usenix > Conference, San Francisco, CA, January 1992. > reported bugs: does not align data in memory [fixed? --ed] > ports: SunOS 4.1.2, Ultrix 4.2A, BSD 4.4, and most other Unix > author: Margo Seltzer, Keith Bostic, Ozan Yigit > contact: Keith Bostic > how to get: ftp ucb/4bsd/db.tar.Z from ftp.cs.berkeley.edu > updated: 1993/10/12 -- Tommy.Thorn@daimi.aau.dk Staff-programmer Aarhus University, Ny Munkegade 116 Phone: +45 89423223 DK-8000 Aarhus C, Denmark. Fax: +45 86135725 PGP Public Key fingerprint: E7B1175FC30D9E96B67AF61D89A70A1F ------------------------------ From: teffta@cs690-3.erie.ge.com (Andrew R. Tefft) Subject: Re: What's wrong with a DOS to Linux disk a Reply-To: teffta@cs690-3.erie.ge.com Date: Thu, 4 Nov 1993 15:23:27 GMT In article 752395599@nella22.cc.monash.edu.au, junaid@nella22.cc.monash.edu.au (Mr A. Walker) writes: >debruijn@cs.utwente.nl (Steef S.G. de Bruijn) writes: > >>Doesn't ANYBODY see a BIG security hole here? If such a DOS >>driver existed, I would make SURE it was not present at my box. >>If I make directories totally unreadable for normal Linux users, >>I would like to keep it that way, also when people were Dozzing >>my machine... Yes this is a good point -- almost (see next good point). > If users have such privilaged access to a machine that they can >boot DOS then there is no way that you can prevent them from accessing >the disks, in some form, leading to securinty breaches. > What stops them from using bootb to boot LINUX and mount the >root file system as on a subdirectory, then modify the passwd files? Another good point -- if they can physically boot a floppy then they can also boot a rootdisk and have full access to your Linux partitions anyway. So having this driver doesn't give them anything they don't already have. Although one could say that a nice feature for a "read linux files under dos" utility would be the requirement of a linux password! :-) (yes, I know, for that to work it has to be able to read the filesystem in the first place, blahblah) but again, having physical access to the machine gives much easier ways to get to your system than getting around the above scheme. Requiring a password would at least stop the merely inquisitive (say, your 8-year old son). ------------------------------ From: tjrc1@mbfs.bio.cam.ac.uk (Tim Cutts (Zoology)) Subject: 16550A handling in serial.c Date: Thu, 4 Nov 1993 18:05:44 GMT I'm afraid I'm not much of an expert in these things, but I bought a 16550A serial card in the hope that it would improve term connections via an X25 gateway to my SunOS host. The old 8250 chip copes fine at 19200 baud on this serial connection, but drops characters at any higher speed, but ONLY on outgoing data (the CPU is a 486/33 and presumably copes with the interrupts). However, my 16550A is no better! :-( I am still limited to 19200 baud. I fiddled with the X25 PAD and SunOS stty parameters until I was blue in the face to get a clean line, but I'm fairly sure I have a clean line anyway. No joy. I posted to comp.sys.ibm.pc.hardware about it, and someone said "The 16550 isn't activated" So I thought I'd look at the kernel sources. I noticed that startup() in serial.c activates the FIFO with an 8 byte trigger, but only if it's a 16550A (why not a 16550?). Now my rc.serial does indeed correctly set /dev/cua2 to a 16550A. /dev/cua0 and /dev/cua1 are still on the old 8250. So presumably the FIFO *is* activated? Or is the chip itself not working for some reason? Is there some other reason why I am getting this one-way corruption? Thanks for any help. Tim. -- =============================================================================== Tim Cutts: tjrc1@mbfs.bio.cam.ac.uk | Refs 7.1 the academic reference CRC Mammalian Cell DNA Repair Research Group | database for Windows 3.1 is now Please support the Cancer Research Campaign! | on ftp.cica.indiana.edu ------------------------------ From: dlevi@ctp.com (David Levine) Subject: RPCGEN for Linux? Date: Thu, 4 Nov 1993 17:00:59 GMT Hey folks, I posted this to ...linux.help before. Let's see if I can get a response here. Does anyone know where to get 'rpcgen' for Linux. Or do I have to go out and build it from scratch. I'm still working with .99pl6, so I'm not sure if it comes with newer distributions. Someone had to use it before because I've noticed that some of the files in the sources are stubs files generated with rpcgen. Thanks in advance, Dave -- _______________________________________________________________________________ /\ /\ / \ /**\ / /****\ ../ /******\................... David P. Levine . \ /****/ . . \ /****/ . Phone: 617 374 - 8280 . \ / \**/ . E-Mail: dlevi@ctp.com . \/ \/ . . Cambridge Technology Partners . .................................. _______________________________________________________________________________ ------------------------------ From: karsten@kshome.ruhr.de (Karsten Steffens) Subject: Re: GCC crashing Linux: kernel bug Date: Thu, 4 Nov 1993 11:42:47 GMT Matthew Grant (grantma@newton.otago.ac.nz) wrote: : Above could be the cause of the paging bug. My case is that I run : Linux 0.99pl13 (standard kernel) with libc jump 4.4.2 on an Intel : 386DX25 with 8 MB interleaved memory, no 387 & 10 MB swap. Exercised the : machine hard with large back-ground C compiles, XFree86 1.3 running + : 1 or 2 copies of Emacs 19.19A going (all at same time) a few times in : the last few weeks. Have not noticed problems recompiling the kernel : in similar sort of situations with machine under load. Hi, I can say absolutely the same as Matthew concerning the problem, but a week ago the situtation was for me as bad as the initiator of this thread wrote. On my system (486 8MB 33MHz, vanilla pl13), it was quite impossible to do a kernel compilation after some 10 minutes of uptime. Always gcc complained about a sig 11 error. BUT things changed, without spending any money on it. What I did, really desperate, was that I just opened the big grey box where the computer sits in (as they say ;-), took off the 8 SIMMS , and noticed that although all of them have 3 chips, all of them have 70ns access time, but 4 of them are made by SAMSUNG, and 4 by some noname-brand. After setting in the SIMMS again, but switching the two banks, i.e, putting those from bank 1 now into bank 0, and vice versa, the problem with the SIG 11 errors totally disappeared. Now I have reached a continous uptime of ~3 days, and gcc doesn't mutter any more. Right now I compiled the kernel again, just for experimental reasons. CONCLUSION: there had been real memory errors (bad contact in the SIMM sockets?), and now after my "surgery" the RAM is in good contact with the rest of the board. Hope that holds. Ah. BTW, the no-name SIMMS seem to have a thinner board, and only silver contacts, not golden ones, as the SAMSUNGs have. Maybe that affects the quality of the contact in the socket. Really hope that its ok now for ever, because LINUX is the best OS I ever had at home... -- ==================> Karsten Steffens <===================== karsten@kshome.ruhr.de | steffens@ikp.uni-muenster.de Marl - close to Recklinghausen | Institut fuer Kernphysik North of the Ruhrgebiet | Westf.Wilhelms-Universitaet Muenster ------------------------------ From: rene@renux.frmug.fr.net (Rene COUGNENC) Subject: Re: new Berkeley DB - anyone? Date: 4 Nov 1993 05:05:08 GMT Ce brave Christian Kuhtz ecrit: > anyone out there who has ported the new Berkeley DB stuff to Linux? Or knows Use the BSD make (pmake) and it will compile quite well... I did it, linked sendmail 8.6.4 whith it. But just for the fun, as I don't use sendmail, smail does all I need... -- linux linux linux linux -[ cougnenc@renux.frmug.fr.net ]- linux linux linux ------------------------------ Crossposted-To: comp.os.mach,comp.os.os2.programmer.misc,comp.os.minix,comp.periphs,comp.unix.bsd,comp.unix.pc-clone.32bit,comp.os.386bsd.development,comp.os.386bsd.bugs,comp.os.386bsd.apps,comp.os.386bsd.questions,comp.os.386bsd.misc From: brendan@news.otago.ac.nz (Brendan Murray) Subject: Re: WILL ???BSD DIE? Date: Thu, 4 Nov 1993 19:59:45 GMT > In article jmonroy@netcom.com (Jesus Monroy Jr) ^^^^^^^ It seems a great shame that I have kill--filed this idiot, to get rid of drivel, and then I get to see it over and over and over again while those people who feel they must dignify his stupidity attack him. While the shrapnel that attends a jmonroy posting is always far more entertaining than the man himself, if we ignore him maybe he'll go away? What really puzzles me is that someone somewhere must be paying this fellow for his abilities - do you think he controls his mouth at work? Does anyone know what he actually does, for that matter? ------------------------------ From: fox@graphics.cs.nyu.edu (David S. Fox) Crossposted-To: comp.os.linux.help Subject: Re: WANTED: COBOL compiler Date: 04 Nov 1993 20:47:04 GMT In article <2bavi7$7j8@access.digex.net> dlc@access.digex.net (David L. Craig) writes: So maybe a COBOL compiler could be the real killer application to put Linux on the map. There are a mind-boggling number of batch- oriented mainframe applications about to be rightsized. Probably not. There are already some killer COBOL compilers for the PC, one of which was written by an NYU faculty member. It is not something you can just knock off. Unless you have a really really smart optimizer its just not interesting at all, since many of COBOL programs are written without much regard to efficiency. We actually had a COBOL attitude adjustment seminar here. (Furthermore, GNAT is being written just downstairs from where I'm sitting...) -- -david ------------------------------ From: euler@bnu003.cncc.bnr.com (Todd Koeckeritz/Euler) Subject: [BUG?] ESDI driver or EXT2 FS problems Date: Thu, 4 Nov 1993 22:11:13 GMT HARDWARE: 386/25Mhz 8M ram (Mylex motherboard) Adaptec 2322B8 ESDI controller One MiniScribe 16IL 330MB Full Height ESDI Drive (Primary disk) One ~315MB Half height ESDI Drive WREN IV (maybe VI) (Secndry disk) Archive tape drive (150M, 402 IF Card) Floppies SOFTWARE: SLS 1.03 Linux 0.99pl13 (non-SLS, clean from tsx-11) ext2fs 0.3[c & d] & 0.4 I posted this to comp.os.linux.help and didn't receive any replies. Since then I have performed some more tests and the results of those tests make me more concerned, so I am placing this in front of the developers in the hopes that if I have discovered a bug, it can be nipped. Obviously a bug this serious, if it does exist and is not specific to my hardware configuration, should have been uncovered before, but ... I discovered the problem on my system while copying the emacs-19.19 files from /usr/spool/uucppublic on my primary disk to another file system on my secondary disk. After I copied the files I found they were corrupted. This happens about 95% of the time I perform the operation. This is what I have done to isolate the problem. Rather than copy the entire set of files (the emacs-19.19-A package), I first tried copying separate files. What appears to happen is that most of the time the individual files copy fine producing uncorrupted data, validated with cmp. Successive copying of files appear to corrupt the earlier copied files. Unmounting and running e2fsck -frv /dev/hdb1 on the filesystem, normally produces a clean check. Once in awhile the copying of the files will produce a "block already free" error and then e2fsck will detect and correct the file system problem. After the repair the files are still corrupt. I was willing to hazard a guess that the results I am seeing in copying the files one at a time has something to do with the file system cache, i.e. the first cmp I do hits the cache, the cache is flushed during second copy, the second cmp actually reads from the disk, but .... I ran tests where I copied the emacs-19.19-A.bin.tar.gz file, validated with cmp, unmounted the file system, remounted, validated again with cmp, copied the el.1of2 file and then validated the bin file again (third time), and it was bad only on the third comparison. The corruption when viewed with cmp -l on the source and destination files shows a curious pattern. I have yet to see the least significant three bits differ, glorious octal output from cmp you know. I do see most of the differences in the most significant octal digit, sometimes in the middle. The bits in error also seem to always be cleared bits on the destination. After first noticing the problem and some initial testing, I low level formatted the drive. The only difference this produced was that some sectors that mke2fs was already finding were marked bad during the format and mke2sf -c didn't find any bad sectors after the low level format. (The computer had been in service for 4 years running SCO Xenix, without problems, until the upgrade to linux anyways, :-) ). The errors ocurr in different places on each copy. I would suspect bad sectors on the disk if it weren't for all of the movement the data has gone through and the history I have with the disk. I would be interested in hearing from anyone who has any good ideas on this as far as better bad block testing (better than mke2fs -c) and a reasonable method to determine the disk or file system blocks occupied by the corrupt file. If I could easily determine the disk blocks that contained the errors I could mark those as bad either until everything worked cleanly or until it became an absurd procedure, i.e. marking 1000 blocks bad on this disk would seem rather absurd to me given the history of the disk. Thanks for any help you may offer, Todd -- | Todd Koeckeritz (Todd.Koeckeritz@wARE.COM) (612) 638-9273 | | wARE, Inc. | +-----------------------------------------------------------------------------+ ------------------------------ From: kkoster@ub.d.umn.edu (Kirby Koster) Subject: Re: idea for TERM client Date: 4 Nov 1993 15:58:42 -0600 In article <2b9lihINNpcd@dns1.nmsu.edu>, James A. Hall wrote: >: than righting a new term client. ^^^^^^^^ ooopps. I meant writing. 8-) > ` >I agree you can turn off call waiting. However my wife gets really hacked >when her friends tell her they tried to call but couldnt get through all night. >I would love to have a dialer/redialer type client. It would start and >stop term based upon the status of the line. I can relate to that. That's why I ended up with a second line just for "computer usage." ;-) Kirby kkoster@ub.d.umn.edu ------------------------------ From: devmorfo@mtu.edu (Evmorfopoulos Dimitris) Subject: Re: RPCGEN for Linux? Date: 4 Nov 1993 22:52:27 GMT In article <1993Nov4.170059.9636@ctp.com>, dlevi@ctp.com (David Levine) writes: > Hey folks, > > I posted this to ...linux.help before. Let's see if I can get a response here. > > Does anyone know where to get 'rpcgen' for Linux. Or do I have to go out and > build it from scratch. I'm still working with .99pl6, so I'm not sure if it > comes with newer distributions. Someone had to use it before because I've > noticed that some of the files in the sources are stubs files generated with > rpcgen. > > Thanks in advance, > > > Dave > > > -- > _______________________________________________________________________________ > /\ /\ > / \ /**\ > / /****\ > ../ /******\................... David P. Levine > . \ /****/ . > . \ /****/ . Phone: 617 374 - 8280 > . \ / \**/ . E-Mail: dlevi@ctp.com > . \/ \/ . > . Cambridge Technology Partners . > .................................. > _______________________________________________________________________________ It exists on newer distributions. Check'em out. Dimitris. ------------------------------ ** 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 ******************************