From: Digestifier To: Linux-Misc@senator-bedfellow.mit.edu Reply-To: Linux-Misc@senator-bedfellow.mit.edu Date: Wed, 1 Sep 93 02:13:08 EDT Subject: Linux-Misc Digest #79 Linux-Misc Digest #79, Volume #1 Wed, 1 Sep 93 02:13:08 EDT Contents: Re: [ANNOUNCE] pwd for Linux (Michael Fuhr) Re: Why would I want LINUX? (Joe Sharkey) Re: coprocessor makes LOTS of difference (John Henders) Re: QIC-02 recommendations wanted (428RBM@DELPHI.COM) *** PLEASE READ THIS BEFORE POSTING *** (misc-2.02) (Ian Jackson) Re: Stacker-like Compression? (Ian McCloghrie) Re: What, if anything, should be statically linked (Gregory Owen) Where can I find xtrek for linux? (Michael Bendickson) [Q] Any real-time extentions in LINUX (Sohail M. Parekh) Re: [TAPE] Sankyo / Archive / Summit (Michael Bongartz) Re: Stacker-like Compression? (Brandon S. Allbery) Re: High speed modems & Linux --- UUCP throughput (Jim Graham) ---------------------------------------------------------------------------- From: mfuhr@cwis.unomaha.edu (Michael Fuhr) Subject: Re: [ANNOUNCE] pwd for Linux Date: Wed, 1 Sep 1993 00:19:02 GMT amoss@picton.cs.huji.ac.il (Amos Shapira) writes: >sn@plato.chemietechnik.uni-dortmund.de (sn) writes: > How about this one (for csh/tcsh users, put in your .tcshrc): > alias pwd echo \$PWD > -Sven >It's not quite the same. Depends on what you want to have but the results >will be quite different when you cd through a symbolic link, and since I >use AMD which uses symlinks all over the place this is important for me. If you're using tcsh, the behaviour of changing directories through symlinks can be defined. "set symlinks=chase" will give you the real directory. "set symlinks=ignore" or "set symlinks=expand" will give you the link name (see the manpage for the difference between ignore and expand). For example: % alias pwd echo \$cwd % cd /usr % ls -l info lrwxrwxrwx 1 root root 10 Jun 12 03:07 info -> local/info % set symlinks=chase % cd info % pwd /usr/local/info % cd /usr % set symlinks=ignore % cd info % pwd /usr/info zsh has this capability as well; I don't know about other shells. -- Michael Fuhr "Nobody but cattle know why they stampede mfuhr@cwis.unomaha.edu and they ain't talkin'." -Unknown ------------------------------ Crossposted-To: comp.os.386bsd.misc From: joe@jshark.inet-uk.co.uk (Joe Sharkey) Subject: Re: Why would I want LINUX? Date: Mon, 30 Aug 1993 21:51:07 GMT In article <1993Aug29.192545.6570@ksmith.com> keith@ksmith.com (Keith Smith) writes: >In article <25d4tg$3d5@email.tuwien.ac.at> hp@vmars.tuwien.ac.at (Peter Holzer) writes: >>peter@NeoSoft.com (Peter da Silva) writes: >> >>>In article hasty@netcom.com (Amancio Hasty Jr) writes: >>>> How long did it take Microsoft to address the functionality provided >>>> by Unix-like system? >> >>>They haven't yet. >> >>Actually, they did. Before they adapted MS-DOS to the IBM-PC, they >>ported Unix (System III?) to a (non IBM) 8086 box and called it Xenix. >>Later they ported it to IBM-clones as well. Yes, but really actually, in time-order(?) Microsoft ported UNIX System III to a (non IBM) 8086 box called a PDP-11 and called it Xenix. Not a lot of room left on an RL-02, and you really wanted split I/D. Didn't Microsoft also port to VAX, Fortune, Altos.. ??? >Actually they never quite got this to work correctly, so a couple of >Hippie Computer guru's in Santa Cruz, CA got together and bought into >Xenix with exclusive distribution rights, and worked all the bugs out of >the Microsoft code. Can you say SCO? Fixing bugs isn't porting, valuable and skilled as it is. >Keith Smith joe. -- Joe Sharkey joe@jshark.inet-uk.co.uk ...!uunet!ibmpcug!jshark!joe 150 Hatfield Rd, St Albans, Herts AL1 4JA, UK Got a real domain name (+44) 727 838662 Mail/News Feeds (v32/v32bis): info@inet-uk.co.uk ------------------------------ From: jhenders@jonh.wimsey.bc.ca (John Henders) Subject: Re: coprocessor makes LOTS of difference Date: Wed, 1 Sep 1993 00:53:00 GMT las@io.org (Laszlo Herczeg) writes: >If anyone is thinking of buying a new system (and price _does_ matter for you) >I definitely recommend the 386-40 with a coprocessor combo over against >a 486. How does this compare for integar math, shifts, compares, etc. It would seem to me that this recommendation only holds true if your interest is in numeric operations. Kernel compile times I see from 486's at ~30% faster than my 386/40, and I doubt gcc or g++ use a lot of floating point math. -- John Henders GO/MU/E d* -p+ c+++ l++ t- m--- s/++ g+ w+++ -x+ ------------------------------ From: 428rbm@news.delphi.com (428RBM@DELPHI.COM) Subject: Re: QIC-02 recommendations wanted Date: 31 Aug 1993 21:14:31 -0400 dans@panix.com (Dan Simoes) writes: >I am thinking about getting a tape drive to use with Linux. >So as to be more compatible with the rest of the world, I'd like to >get a "real" 1/4" tape, i.e.DC6150, DC600A, etc. >I think this is known as QIC-02. >If you are running this type of drive under Linux, please let me know >what you are using, where you got it if possible, and how well it >works. I believe the drivers are still Alpha, no? >It probably is preferable to email me and then I can summarize, but followup >if you must... >Thanks, >| Dan | >-- >Dan Simoes Voice: 914.747.2900 x415 >Danix Consulting email: dans@panix.com or >Yorktown Heights, NY dans@danix.uucp i got a refurbished cipher 150MB for 69$ from a place called JEM 1-617-254-5500 and an everex ev811b qic-02 controller for $70. Been working fine so far. ------------------------------ From: ijackson@nyx.cs.du.edu (Ian Jackson) Subject: *** PLEASE READ THIS BEFORE POSTING *** (misc-2.02) Date: Wed, 01 Sep 1993 02:23:01 GMT Please do not post questions to comp.os.linux.misc - read on for details of which groups you should read and post to. If you have a question about Linux you should get and read the Linux Frequently Asked Questions with Answers list from sunsite.unc.edu, in /pub/Linux/docs, or from another Linux FTP site. In particular, read the question `You still haven't answered my question!' Then you should consider posting to comp.os.linux.help - not comp.os.linux.misc. Note that X Windows related questions should go to comp.windows.x.i386unix. The FAQ for this group is available on rtfm.mit.edu in /pub/usenet/news.answers/Intel-Unix-X-faq. Comments on this posting are welcomed - please email me ! -- Ian Jackson (urgent email: iwj10@phx.cam.ac.uk) 35 Molewood Close, Cambridge, CB4 3SR, England; phone: +44 223 327029 ------------------------------ From: imcclogh@cs.ucsd.edu (Ian McCloghrie) Subject: Re: Stacker-like Compression? Date: 1 Sep 93 02:39:24 GMT bsa@kf8nh.wariat.org (Brandon S. Allbery) writes: >In article <53893@sdcc12.ucsd.edu> imcclogh@cs.ucsd.edu (Ian McCloghrie) writes: >> I'd assume that you could maintain an "offset-into-file" counter >>for each block in your inode. This would require 4-bytes per block, >>assuming 4K blocks that's a 0.1% increase in space used, well offset >>by the savings from compression. Random access is doable. I'm >>still not in favour of compressed filesystems tho :) >...except that this only works if you compress each block independently. >Otherwise you *still* have to start compressing earlier in the file so that >the compressed block you want can be uncompressed. And if you're doing it You could probably do it by compressing, oh, 10 blocks at a time, in which case you'd have to read out the 10 blocks, uncompress them, write your new data into it, recompress them, and have some way of dealing with it if your new data doesn't fit into the same space as the old data. This last is the hard part. Plus the fact that you're hitting disk a lot more often than you need to in an uncompressed filesystem. >this way then there are better implementations and, I suspect, better >algorithms (gzip being optimized for compressing large files, you'd need a >horrendously large blocksize to get the same result you get outside the >kernel). Certainly, gzip is not the correct solution here. -- /~> Ian McCloghrie | Commandant of Secret Police - Cal Animage Beta. < < /~\ |~\ |~> | | <~ | email: ian@ucsd.edu Net/2, USL 0! \_> \_/ |_/ |~\ |__| _> | Card Carrying Member, UCSD Secret Islandia Club ------------------------------ From: gowen@apex.cs.tufts.edu (Gregory Owen) Subject: Re: What, if anything, should be statically linked Date: Wed, 1 Sep 1993 04:02:28 GMT In the ongoing thread about staticly linked binaries, niemidc@oasis.gtefsd.com (David C. Niemi) wrote: > I am basing this primarily on what commands I HAD TO have when fixing > badly crashed Suns that I did not have an alternate boot medium for > (or did, but did not have shared libraries available). I had to bring up a smoked sparc today, and I found myself repeatedly wishing I could just pop the boot/root combo into the 3.5 drive, just like Linux. As it happened, we booted off of two seperate hard drives, a cd-rom and a tape drive before we got anywhere. (not that we got very far). Oh yeah... my point. First, what use are statically linked binaries when a boot floppy with a root partition fits onto a floppy or two? This is vaguely hypothetical, but I think that is a very practical way to fix things -- I've used it on my linux box several times. Better than static binaries, IMHO. Secondly, and another idea that hit me whilst playing doctor to that 'puter today, wouldn't it do to have a floppy with selected static binaries on it? Then all you need is "mount" on the system and you can get that floppy mounted, from which you'll have most of the commands you need. Sort of a "Linux doctor disk." I'd be willing to look into building one if people thought it would be useful. If you do, drop me a line; if I get enough lines, I'll have a page... er, I mean I'll investigate what utilities people would want (although I'll tell you RIGHT NOW emacs won't fit. Learn VI. 8). Sun trivia question: fsck is not _really_ in /etc; its a link to /usr/bin/fsck. Which is the most annoying thing in the world when you keep trying to /etc/fsck the /usr partition. Greg Owen { gowen@forte.cs.tufts.edu, gowen@xis.xerox.com } 1.01 GCS/GO d++ p+ c++ l++ u++ e+ -m+ s++/- n- h !(f)? g+ -w+ t+ r-- y? "These fragments I have shored against my ruins/Why then Ile fit you. Hieronymo's mad againe./Datta. Dayadhvam. Damyata." ------------------------------ From: mbendic@gill.micro.umn.edu (Michael Bendickson) Subject: Where can I find xtrek for linux? Date: Wed, 1 Sep 1993 03:10:49 GMT Does anyone know where I can find xtrek binaries for linux? I would greatly appreciate it!!! Here's what I have: >Welcome to release 1.03 of SLS (SoftLanding Linux System) containing >kernel 99 alpha p11, libc 4.4.1, gcc 2.4.5 and XFree86 1.3. Linux is a Thanks, -Mike mbendic@mermaid.micro.umn.edu -- =============================================================================== Michael Bendickson University of Minnesota E-Mail: mbendic@mermaid.micro.umn.edu Institute of Technology =============================================================================== ------------------------------ From: sohail@trixie (Sohail M. Parekh) Subject: [Q] Any real-time extentions in LINUX Reply-To: sohail@rhonda.jsc.nasa.gov Date: Wed, 1 Sep 1993 04:47:05 GMT Does LINUX have any real-time extentions and/or does it conform to any POSIX .4 or .4a standards ??? Sincerely, Sohail -- Sohail M. Parekh Grumman Data Systems sohail@rhonda.jsc.nasa.gov 12000 Aerospace Ave. (713) 483-5912 Houston, TX 77034 ------------------------------ From: micha@mubo.saar.de (Michael Bongartz) Subject: Re: [TAPE] Sankyo / Archive / Summit Date: Tue, 31 Aug 1993 07:47:02 GMT On Fri, 27 Aug 1993 20:31:45 GMT in comp.os.linux, dan@oea.hobby.nl wrote: : OK. It seems that the technical problems encountered by the group trying : to develop a driver for FDC based tape streamers are unsurmountable, for : the moment at least, so I'm looking elsewhere for a backup system. During : my search I came across the following (affordable?) solutions: : - SCSI based Archive "" for about $600. 525 MB capacity. (includes : an Adaptec SCSI controller, which I don't need). : has anyone used these gizmos (un)successfully with LINUX? I've an Archive 525 in combination with an Adaptec 1542 B - no problems, about 9 MB / min. Bye, Micha -- A bad ad can ruin your whole day! EMail: micha@mubo.saar.de /\/\ University: bongartz@cs.uni-sb.de Voice: 0681/456-12 / \ Fax + Modem (ZyX 19k2): +49 681 456-14 SnailMail: Michael Bongartz, Neunkircherstr. 118A, 66113 Saarbruecken, Germany ------------------------------ From: bsa@kf8nh.wariat.org (Brandon S. Allbery) Subject: Re: Stacker-like Compression? Date: Wed, 1 Sep 1993 04:31:22 GMT In article <53965@sdcc12.ucsd.edu> imcclogh@cs.ucsd.edu (Ian McCloghrie) writes: >bsa@kf8nh.wariat.org (Brandon S. Allbery) writes: > >>In article <53893@sdcc12.ucsd.edu> imcclogh@cs.ucsd.edu (Ian McCloghrie) writes: >>> I'd assume that you could maintain an "offset-into-file" counter >>>for each block in your inode. This would require 4-bytes per block, >>>assuming 4K blocks that's a 0.1% increase in space used, well offset >>>by the savings from compression. Random access is doable. I'm >>>still not in favour of compressed filesystems tho :) > >>...except that this only works if you compress each block independently. >>Otherwise you *still* have to start compressing earlier in the file so that >>the compressed block you want can be uncompressed. And if you're doing it > > You could probably do it by compressing, oh, 10 blocks at a time, >in which case you'd have to read out the 10 blocks, uncompress them, >write your new data into it, recompress them, and have some way of >dealing with it if your new data doesn't fit into the same space I'd tend to think of this as using blocks that are 10 times larger... I also don't see the problem with "if your new data doesn't fit" --- why should it? The compressed FS simply allocates more physical blocks as appropriate and updates its internal pointers. Actually, a more optimal way to handle block compression is to allow different blocks from the same file to share the same code table (is that the correct term?). The advantage is that an essentially identical code table doesn't have to be stored in every compressed block for a file with many duplicate strings, which improves the de-facto compression ratio; the disadvantages are that (1) every compressed block has to have a pointer to the code table; (2) if the code table gets trashed, it takes multiple blocks with it; and (3) a random-access write to an existing block with strings that only partially match the code table might not be compressed as fully as if it were compressed on its own. And (4) that some pathological cases might result in every block getting its own code table anyway --- but because the tables aren't stored in the compressed blocks, the resulting "packing" of the data might be sub- suboptimal; in the worst case, the "compressed" file would actually *expand*. But then, pathological cases are a calculated risk. Still more optimal in terms of storage would be to allow blocks from different files to share code tables, but the overhead in determining which code table a given block is most "compatible" with would be prohibitive. ++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: jim@n5ial.mythical.com (Jim Graham) Subject: Re: High speed modems & Linux --- UUCP throughput Date: Tue, 31 Aug 1993 12:57:16 GMT NOTE: Followups to comp.dcom.modems, as this is really not Linux related anymore.... In article <1993Aug30.101824.1722@jonh.wimsey.bc.ca> jhenders@jonh.wimsey.bc.ca (John Henders) writes: [I wrote:] >>One thing you need to be careful about---it's possible (probable) that >>these stats include times for transferring the control files, and will >>also probably include transfer of files that are really too small to be >>of any value in a throughput measure. > Well, I was going to send my stats file, but it was rather large. As >what it says contradicts what you say, I'll include parts of it. > UUCP transmission history: [deleted] I'm not sure just what your point is here. Are you trying to say that your stats indicate that the summary posted earlier doesn't include the smaller files that aren't valid for throughput tests? If so, you may be right, but since you've deleted parts of the Stats file, it's hard to say. However, if you're trying to say that your stats somehow indicate that very small files *ARE* valid for throughput measurement, that isn't true. Trust me---I'm a professional in data communications, and very small data transfers tell you *NOTHING* about throughput (which, btw, is not measured in baud---the baud rate is the symbol rate, and is definitely not the same thing as the bit rate, expressed in bits/second, or throughput, which is expressed in either cps or bps...there are times when the values are equal, but they still aren't the same thing). If you have any doubts about how meanlingless the throughput measurements from very small files really are, just look at the following excerpts from my Stats file---I've trimmed the timestamps, etc., and have added comments at the end to tell you what the file was: received 16725 bytes in 9.903 seconds (1688 bytes/sec) # compressed news received 136 bytes in 0.031 seconds (4387 bytes/sec) # X.* command file received 3663 bytes in 1.690 seconds (2167 bytes/sec) # compressed news received 136 bytes in 0.093 seconds (1462 bytes/sec) # X.* command file received 21983 bytes in 13.082 seconds (1680 bytes/sec) # compressed news received 136 bytes in 0.035 seconds (3885 bytes/sec) # X.* command file The connection was V.32bis/V.42/V.42bis, and the serial port is locked at 38.4 kb (therefore, the maximum possible throughput is 3840 cps). The news batches were compressed with gzip, so it's safe to assume that V.42bis isn't going to do anything with it except transfer the original data. So, for news batches, we use the estimated throughput for a plain V.32bis/V.42 connection, which amounts to right around 1724 cps (1800 cps absolute maximum minus protocol overhead). Notice that the second transfer shows a throughput of 4387 cps, which isn't possible given the configuration here (would require a serial port speed of at least 43,870 bps). The last transfer shown (3885 cps) is also impossible for the same reason. Then, notice that the third transfer, a compressed news batch, shows a throughput of 2167 cps---well above the 1724 cps maximum that we can expect for compressed data. As any datacomm pro will tell you, if you want valid, meaningful throughput measurements, you have to transfer a *LOT* of data. > Note the first 3 packages are probably mail, thus the higher >throughput. The first 3 packages were very, very small files---the throughput numbers are basically meaningless. >>It's better to look in your Stats file and look at incoming files that >>are *AT LEAST* 200k (and if at all possible, twice that size). Otherwise, >>your measurements are, at best, uncertain. > > I hardly ever see a batch bigger than 100k, most are closer to 60. Ever heard of generating test data? If nothing else, find a huge compressed file on your feed site and uucp it (or ask the sysop there to do something like that). Remember, you need to pick a file that will take at least several minutes to transfer (for general-purpose measurements, a transfer that takes 4 to 5 minutes should be just fine). Later, --jim -- #include 73 DE N5IAL (/4) ==========================< Running Linux 0.99 PL9 >========================== INTERNET: jim@n5ial.mythical.com | j.graham@ieee.org ICBM: 30.23N 86.32W AMATEUR RADIO: (packet station temporarily offline) AMTOR SELCAL: NIAL ============================================================================== E-mail me for information about KAMterm (host mode for Kantronics TNCs). ------------------------------ ** 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-Misc-Request@NEWS-DIGESTS.MIT.EDU You can send mail to the entire list (and comp.os.linux.misc) via: Internet: Linux-Misc@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-Misc Digest ******************************