From: Digestifier To: Linux-Development@senator-bedfellow.mit.edu Reply-To: Linux-Development@senator-bedfellow.mit.edu Date: Sat, 4 Dec 93 23:13:09 EST Subject: Linux-Development Digest #290 Linux-Development Digest #290, Volume #1 Sat, 4 Dec 93 23:13:09 EST Contents: Re: FD_ series of commands (Doug McIntyre) Re: THE ULTIMATE FAQ ANSWER (Louis P. Kruger) Re: ext2fs and 0.99pl14 Re: Creeping featuritis (post --rant --flame) (Keith Smith) ext2fs querk (David Jeske) SQL for University Ingres (enrico badella (L.R.)) Neuronal networks (Christian Pablo Tagtachian) Re: SQL for University Ingres (Zeyd M. Ben-Halim) Re: Creeping featuritis (post --rant --flame) (Grant Edwards) Re: Creeping featuritis (post --rant --flame) (Grant Edwards) Re: ext2fs querk (Brandon S. Allbery) ---------------------------------------------------------------------------- From: merlyn@jacobs.jacobs.mn.org (Doug McIntyre) Subject: Re: FD_ series of commands Date: 3 Dec 1993 11:53:04 -0600 jacobsd@solar.cor2.epa.gov (Dana Jacobsen) writes: >In <1993Nov18.053105.2322@hip-hop.sbay.org> root@hip-hop.sbay.org (Remco Treffkorn) writes: >>Brian Zarnett (bzarnett@jupiter.scs.Ryerson.CA) wrote: >>: Can anyone tell me how or what the FD series of commands in types.h do? >>: there is FD_ZERO, FD_ISSET, fd_set (variable) etc. >>Those are macros used in conjunction with the select function. >>Try 'man select'. If you do not have the linux man pages get the book: >> Internetworking with TCP/IP Volume III Comer/Stevens The Comer vol3 book is ridled with bugs and mis-information. Go for UNIX Network Programming by R. Stevens. Much better. For implementation details, I prefer the GNU C Library reference manual. (But the first 2 vols of Comer are okay.) > I find the documentation for the FD macros to be a little skimpy (Comer >"documents" by giving one example, albeit a very nice one). Here's my >question: xbattle has a line "if (FDSET(blah,&blah))" in it, which works >fine on SunOS, but fails on Linux. The SunOS FD_SET is: ... > Now, the SunOS FD_SET may be evaluated, but gcc 2.4.5 doesn't think the >asm version can. None of the documentation I've seen really mentions >whether anything other than FD_ISSET has a return value. This may be a >simple question (replace the "if(FD_SET())" with "FD_SET(); if(FD_ISSET())") >but it might be nice to see the documentation explain this a little better. >This would of course be the Linux documentation since we're not going to >change either SunOS or Comer's book. It's also interesting that this >works on SunOS. Fluke or feature? The GNU C lib ref says that FD_SET returns nothing (ie. its a macro that evaluates to void). The Linux assembly will evaulate to nothing, its not an expression in any form, so its compliant with what the FSF has determined to be correct (ie. from POSIX, whatever other standards are out there). FD_ISSET() does evaulate to a value, so you can use FD_ISSET() in the if statement. There is a ton of code out there that is dependent on the particular implementation of a library. It doesn't mean that it is ``correct'' as the various standards groups have determined.. -- merlyn@jacobs.mn.org I don't wanna watch TV... I don't wanna listen to the Corporations.. I don't wanna drown in American Society.. -- L7 ------------------------------ From: lpkruger@tucson.Princeton.EDU (Louis P. Kruger) Crossposted-To: comp.infosystems.www,comp.windows.x,comp.windows.x.i386unix,comp.windows.x.motif,gnu.misc.discuss,comp.sources.d Subject: Re: THE ULTIMATE FAQ ANSWER Date: 3 Dec 93 22:45:42 GMT In article <2dmfg2$31l@smurf.noris.de>, Matthias Urlichs wrote: *stuff deleted* >Note, also, that it's impossible to write new Motif programs when all you >have is the (runtime part of the) shared library; all the library gives you >is space saved on disk and in memory. Guess what? You still can't distribute >a shared Motif library. > >This restriction hurts me personally, and absolutely nobody, including OSF, >benefits from it. I don't know about you but I refuse to pay anything at all >to a company which promotes stupidity like that. > Hold it! OSF certainly benefits... who would pay for Motif if it were free? Believe it or not, there are some companies out there that are actually interested in Profits. I think Linux has spoiled us all :) >-- >The sudden sight of me causes panic in the streets. They have >yet to learn - only the savage fears what he does not understand. > --The Silver Surfer >-- >Matthias Urlichs \ XLink-POP N|rnberg | EMail: urlichs@smurf.sub.org >Schleiermacherstra_e 12 \ Unix+Linux+Mac | Phone: ...please use email. >90491 N|rnberg (Germany) \ Consulting+Networking+Programming+etc'ing 42 Louis Kruger ------------------------------ From: jwest@jwest.ecen.okstate.edu () Subject: Re: ext2fs and 0.99pl14 Date: Sat, 4 Dec 1993 19:01:50 GMT In article lam836@cs.cuhk.hk writes: >I've upgraded to 0.99pl14 a few days ago. Just now, I ran dosemu49pl3 >and there seems to be a bug somewhere that causes the keyboard to become >inresponsive when I switch back to the VC running dosemu (the screen was >blanked, and Linux seems inresponsive to what I type. This problem has >happened more than once in the past). I had no choice but to press the >reset switch on my PC. Just for the record, I also get a very similar problem. If I run dosemu and then try to access the net (any fashion, reading news, sending mail, ftp, etc) I get several kernel panics and then a lockup about 50% of the time. This is with linux-0.99pl14 and dosemu49pl2 or pl3. I tried switching back to dosemu49 (no pl) just for grins and get locks everytime I try to access the net later. Jim ========== Jim West Associate Professor Electrical and Computer Engineering Oklahoma State University jwest@master.ceat.okstate.edu ------------------------------ Crossposted-To: gnu.misc.discuss From: keith@ksmith.com (Keith Smith) Subject: Re: Creeping featuritis (post --rant --flame) Date: Sat, 04 Dec 93 17:16:54 GMT In article <1993Dec210.51.14.7664@silverton.berkeley.edu>, D. J. Bernstein wrote: >In article <1993Dec01.160511.3272@ksmith.com> keith@ksmith.com (Keith Smith) writes: >> This is a typical Unix Laziness. It seems to me were talking about a >> Statically liked binary of less than 100K in either case. The >> intelligent thing to do would be to COMBINE the programs into one. > [ ... ] >> I'd like to see a SINGLE binary hard >> linked to pax,tar,cpio, and whatever else that handles _all_ of the >> issues that may come up, INCLUDING compression & the like. > Down at the bottom of the article Dan says: >Code duplication is _not_ the intelligent thing to do. First off a single binary would not contain _any_ duplicated code, but I digress ... >Yeah, brilliant. What happens when thirty different programs like this >are running on the system? Boom, three megabytes gone---provided you >can fit each of your monster applications into a mere 100K. I've been under the assumption that TEXT segments are shared. That would mean 30 invocations of a 100K program would take only 100K! Secondly, if you have 30 simultaneous tar/cpio type jobs running you must have a BIG machine, in which case 3 MB is gonna be _nothing_ in terms of memory. Thirdly if you have a machine that will even SUPPORT half that number of external type tape/disk devices SIMULTANEOUSLY you are _not_ running a PC, so the arguments are moot. >I prefer to see each utility written in terms of a few small tools. The >thirty programs might become thirty small wrappers around twenty common >tools. Even if all these wrappers and tools take 25K each, the total is >only a megabyte. No 30 wrappers at 25K + 30 Tools at 25K + 60 Filters at 25K and no TEXT segment sharing you end up with 3MB of RAM. If the text segment IS shared your argument is event worse, if everyone is using DIFFERENT filters and tools. > >Two megabytes of RAM saved. Call it $100 per machine. Dream on. > >The memory waste also translates into sluggishness: you have to wait >longer when you first start up a 100K application than when you first >start up a 25K wrapper around common tools which are already in memory. > On the contrary, WRONG, WRONG, WRONG. A PIPE is much slower than direct memory use in a program. writing to a pipe is slower. The more different files that are OPENED have more to do with the speed of loading software than actually READING them in unless they are just freaking HUGE, (Like GNU emacs). Any time you pass data thru the kernel in any form you slow it down drastically vs manipulating it in program. All of your arguments here are arguments AGAINST LINUX also, as it is a monolithic program also. -- Keith Smith keith@ksmith.com 5719 Archer Rd. Digital Designs BBS 1-919-423-4216 Hope Mills, NC 28348-2201 Somewhere in the Styx of North Carolina ... ------------------------------ From: jeske@ux4.cso.uiuc.edu (David Jeske) Subject: ext2fs querk Date: 4 Dec 1993 22:14:33 GMT I recently came across a strange file system querk. I had another computer NFS mounted on /Net/colossus, There was a directory on that computer under /Archive/XFree/BCLinux/XFree/ /Archive/XFree /Archive/XFree/BCLinux/ were both empty except for the one directory entry under them. (I took something off tape into here) ANyhow, I went to /Archive (actually /Net/colossus/Archive) and did a "mv XFree XF" to rename "/Archive/XFree" so I could them move the "deeper" /Archive/XFree/BCLinux/XFree down to /Archive. when I did this there was no longer a "/Archive/XF/BCLinux/Xfree", BCLinux was there, but it was completly empty. The stranger part was that when I named "XF" back to "XFree" the "BCLinux/XFree" directory came BACK!. The filesystem was ext2, on pl13, and it was over NFS, but does this not seem like a large bug of some kind? -- David Jeske(N9LCA)/CompEng Student at Univ of Ill at Cham-Urbana/NeXT Programmer CoCreator of the GTalk Chat Software System - online at (708)998-0008 Mail: jeske@ux4.cso.uiuc.edu NeXTMail: jeske@sumter.cso.uiuc.edu jeske@atlantis.eid.anl.gov Talk: jeske@armageddon.slip.uiuc.edu ------------------------------ From: badella@polec1.polito.it (enrico badella (L.R.)) Crossposted-To: comp.databases,comp.os.linux.misc Subject: SQL for University Ingres Date: 4 Dec 1993 22:34:11 GMT I'm playing with University Ingres on my Linux box; it's a nice peice of code but what I'm really missing is SQL, I cannot get uesed to QUEL. Has anybody every tried adding a SQL engine? Please don't tell me to buy Ingres from Ask 8*) ------------------------------ From: floyd@arthax.satlink.net (Christian Pablo Tagtachian) Subject: Neuronal networks Date: Sat, 4 Dec 1993 16:11:39 GMT Hello, I am looking for a developement package for neuronal networks, does anyone know about the existance of such thing for Linux? I also got SmallTalk with its interface for X, but it doesn't allow you to develope X11 applications, is there any add-on for it to support such thing? Thank you very much. Christian Buenos Aires, Argentina. Subject: Neuronal networks Newsgroups: comp.os.linux.development Organization: Arthax, a ride into the unix world Summary: Keywords: X-Newsreader: TIN [version 1.1 PL8] Hello, I am looking for a developement package for neuronal networks, does anyone know about the existance of such thing for Linux? I also got SmallTalk with its interface for X, but it doesn't allow you to develope X11 applications, is there any add-on for it to support such thing? Thank you very much. Christian Buenos Aires, Argentina. ------------------------------ Crossposted-To: comp.databases,comp.os.linux.misc From: zmbenhal@netcom.com (Zeyd M. Ben-Halim) Subject: Re: SQL for University Ingres Date: Sun, 5 Dec 1993 01:56:02 GMT In article <2dr393$qsp@galileo.polito.it>, enrico badella (L.R.) wrote: >I'm playing with University Ingres on my Linux box; it's a nice peice >of code but what I'm really missing is SQL, I cannot get uesed to QUEL. I seriously doubt that anyone is going to add SQL to university ingres, at least without being paid for it. Most of the people familiar with QUEL and SQL think QUEL is better and have no incentive to add SQL. >Has anybody every tried adding a SQL engine? Please don't tell me >to buy Ingres from Ask 8*) > -- --- Zeyd M. Ben-Halim zmbenhal@netcom.com 10479 1/4 Santa Monica Blvd, LA, CA, 90025 (310) 470-0281 ------------------------------ Crossposted-To: gnu.misc.discuss From: grante@hydro.rosemount.com (Grant Edwards) Subject: Re: Creeping featuritis (post --rant --flame) Date: Sun, 5 Dec 1993 00:07:47 GMT etcom.com> X-Newsreader: TIN [version 1.2 PL0] Rajappa Iyer (rsi@netcom.com) wrote: : In <1993Dec3.174833.12155@black.toppoint.de> kris@black.toppoint.de (Kristian Koehntopp) writes: : >In haley@scws14.harvard.edu (Elizabeth Haley) writes: : >>O.K. Rajappa, while we're doing our homework, here's some for you: : >>Given a directory "stuff" which contains 35 files, avaeraging 2-3 Mega : >>bytes in size, and given a device "/dev/fd0a"; a 1.44 Meg floppy drive, : >>design a shell script that will put these files onto a series of : >>disks. We must then be able to retrieve these same files with either : >>the same or another script. : >Without thinking I would do something along the lines of : >#! /bin/sh -- : >tar cvf - $HOME/ | ( : > count=0 : > while : : > do : > dd of=/dev/fd0a bs=1k count=1440 : > echo "Backup of Volume $count done." : > count=`expr $count + 1` : > echo "Please insert Volume $count." : > read input < /dev/tty : > if [ "$input" = "quit" ] : > then : > break : > fi : > done : >) : There is no way to find out when to quit. What do you mean? It looks like it quits when it's done, or you type "quit" when prompted for another volume. : This will not address the <= 256 bytes slack space requirements to : be sure Please explain, it looks to me like every disk but the last will contain exactly 1.44MB. : Another problem which is not addressed by this method would be files : larger than volume size... Again, it looks to me like it would work fine with large files. Please explain your statement. I think I'll give the above shell script a try just for grins... Stay tuned kids. -- Grant Edwards |Yow! Your CHEEKS sit like Rosemount Inc. |twin NECTARINES above a MOUTH |that knows no BOUNDS -- grante@rosemount.com | ------------------------------ Crossposted-To: gnu.misc.discuss From: grante@hydro.rosemount.com (Grant Edwards) Subject: Re: Creeping featuritis (post --rant --flame) Date: Sun, 5 Dec 1993 00:49:13 GMT Dec5.000747.16418@rosevax.rosemount.com> X-Newsreader: TIN [version 1.2 PL0] Grant Edwards (grante@hydro.rosemount.com) wrote: : : kris@black.toppoint.de (Kristian Koehntopp) writes: : : >haley@scws14.harvard.edu (Elizabeth Haley) writes: : : >>O.K. Rajappa, while we're doing our homework, here's some for you: : : >>Given a directory "stuff" which contains 35 files, avaeraging 2-3 Mega : : >>bytes in size, and given a device "/dev/fd0a"; a 1.44 Meg floppy drive, : : >>design a shell script that will put these files onto a series of : : >>disks. We must then be able to retrieve these same files with either : : >>the same or another script. : : >Without thinking I would do something along the lines of : : >#! /bin/sh -- : : >tar cvf - $HOME/ | ( : : > count=0 : : > while : : : > do : : > dd of=/dev/fd0a bs=1k count=1440 : : > echo "Backup of Volume $count done." : : > count=`expr $count + 1` : : > echo "Please insert Volume $count." : : > read input < /dev/tty : : > if [ "$input" = "quit" ] : : > then : : > break : : > fi : : > done : : >) : : There is no way to find out when to quit. : What do you mean? It looks like it quits when it's done, or you type : "quit" when prompted for another volume. Oops, it doesn't know when to quit. I spent about 5 minutes and came up with this update of Kris' most excellent shellscript: #! /bin/sh -- tar cvf - $1 | ( count=0 while : do echo "Please insert Volume $count" read input < /dev/tty if [ "$input" = "quit" ]; then break fi set `dd of=/dev/fd0 bs=1k count=1440 2>&1` eject echo "Volume $count done." if [ "X$1" != "X1440+0" ]; then echo "Backup Finished." break fi count=`expr $count + 1` done ) I've tested this and it works on SunOS 4.1.3. It handles files bigger than a single disk. There is no empty "slack" on any disk other than the last one. I don't imagine it took Kris more that a couple minutes to write the original, and it took me less that five minutes to refine and test my version. Given another five minutes I could write and test the script that recovers files, but I've left that as an exercise for the reader. Changes from Kris' script include: 0) Directory name to be backed up is given on command line. 1) Prompts for first disk as well as subsequent disks. 2) Automatically stops after last disk. 3) Added "eject" command for my SPARC's floppy drive. It would get a little old shoving that paper clip into the little hole after every disk. If you've got manual eject a-la PCs then you don't need this. Issues: 0) Little or no error recovery if you shove in a bad disk. 1) Restoring files requires you to read all disks prior to the one containing the desired file(s). I don't know if gnu-tar handles these issues any better or not. When discussing the problem commonly known as "gnubloat" it is wise to remember the famous indictment: "RMS thinks that Unix is just another program you can run under emacs." Thus the now-famous gnu attitude "let's throw in 3 or 4 kitchen sinks, we've got virtual memory! Oh, and put in a lisp interpreter -- if we've forgotten anything, we'll add it on later..." ;) Back in the PDP-11 V7 days, the limit of 64K text and 64K data required a certain amount of elegance finesse that seems to be lacking lately. -- Grant Edwards |Yow! Is something VIOLENT Rosemount Inc. |going to happen to a GARBAGE |CAN? grante@rosemount.com | ------------------------------ From: bsa@kf8nh.wariat.org (Brandon S. Allbery) Subject: Re: ext2fs querk Date: Sun, 5 Dec 1993 03:25:18 GMT In article <2dr249$c1o@vixen.cso.uiuc.edu> jeske@ux4.cso.uiuc.edu (David Jeske) writes: >ANyhow, I went to /Archive (actually /Net/colossus/Archive) and did >a "mv XFree XF" to rename "/Archive/XFree" so I could them move >the "deeper" /Archive/XFree/BCLinux/XFree down to /Archive. >when I did this there was no longer a "/Archive/XF/BCLinux/Xfree", >BCLinux was there, but it was completly empty. You almost certainly renamed the business end of a symlink. This is one reason I don't like symlinks: since they work by name, if you rename the target of a symlink, the symlink points into space. As you noticed, it's even more fun when the symlink is recursive... ++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 Do not taunt Happy Fun Coder. (seen on the Net...) ------------------------------ ** 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 ******************************