From: Digestifier To: Linux-Misc@senator-bedfellow.mit.edu Reply-To: Linux-Misc@senator-bedfellow.mit.edu Date: Wed, 8 Sep 93 12:13:25 EDT Subject: Linux-Misc Digest #115 Linux-Misc Digest #115, Volume #1 Wed, 8 Sep 93 12:13:25 EDT Contents: Re: Stacker-like Compression? (Michael O'Reilly) Re: NT versus Linux (RICHARD HOFFBECK) /sbin/sync (Nick Holloway) Shared libs for InterViews3.1 (Friedrich Heinrichmeyer) Support for Xircom parallel port ethernet adapters? (Tall Cool One) Linux and Lisp: Clisp or AKCL? (Brad Miller) QIC tape on Linux: SUMMARY (Dan Simoes) Re: NT vs Linux vs My Daddy is Better Than Your Daddy (Mike Dowling) Mitsumi CDROM under Linux: SUMMARY (Dan Simoes) ---------------------------------------------------------------------------- From: oreillym@tartarus.uwa.edu.au (Michael O'Reilly) Subject: Re: Stacker-like Compression? Date: 8 Sep 1993 12:54:10 GMT Rob Getter (rxg@cci.com) wrote: : I don't think a compressed file system would be all that difficult. Heh. Try and write one sometime. It's a bit of an eye-opener. I had a bash at one a while back, bashed on the sprite LFS. Unfortunately the VFS is not very compatable with the LFS structure, and it looked like takeing a LOT more time than I had thought, so I dropped it fast. : Random : access can be handled by compressing the file in blocks, and perhaps storing : an offset to each block at the beginning of the file or in its own : disk block. Perhaps the easiest way of doing things that springs to mind, is simply useing a significantly larger block size (i.e. 8K and up), and makeing inode pointers byte wise rather than block wise. Maybe. You'd pay a big price for not haveing things on sector boundries, but you would save a lot of space.. : that way, decompression can be done block by block, still leaving good random : access performance and also the possibility for demand paging executables and : shared libraries. You lose some compression, but not all that much. (look at : V.42bis which compresses small blocks of data but still gets ~50% on : uncompressed files). I'm not certain, but I don't this is true. Unless V42biz is particularly stupid, it retains a dictionary. Yes, it compresses in N byte blocks, but the dictionary wouldn't be discarded after each block. Real time compression on continuous streams is a vastly different kettle of fish from compressed file systems. Trust me on the one ... : In my opinion, the gzip algorithm would be good since the : decompression is very fast, but compression is slow. First, don't advocate a compression scheme unless you know whats it's doing... :) Now: gzip is a so-called 'distribution' compressor, meaning that it's build for good compression ratios + fast decompression. But! Gzip uses an lz77 variant. The lz77 variants usually have the very neat property that you can trade of compression for speed in a number of different ways. Curious people are directed to lzrw3-a. Having a fast initial compression, followed by a user-mode program that updates untouched files with better compression would be pretty cool. : The compression speed : isn't a problem since you can do lazy compression, first writing a file : normally, and then compressing it later. You could also have compression Yup, this is cool, but as I mention above, you can get pretty fast compression out of lz77's. Easily a few hundred K per second if you resort to assembly. : scheduled to occur once a day, or have it triggered by a percentage of : the disk being used up. that way, performance stays high until the disk gets : full and then gradually degrades. You can have the computer track usage and : compress files using an LRU strategy so that decompression time affects you : as little as possible. This starts getting complicated, and you need to move this out of the kernel into user mode. I carefully avoid mentioning above how the hell you would sync a user mode program modifing a live disk with the kernel.. :) : Overall, I would expect some performance loss, but not nearly as much as most : people seem to think. On a 386sx or a slower dx, it may very well have a : significant performance hit. Well, it's an optional feature afterall. It it's unuseable, don't use it.. . : I considered adding some of this to : Linux myself, : but I have very little time available and I heard that there were people : working on it already. I would certainly be willing to try it when : it becomes : available for testing, and until then, I don't see much point in : arguing about : how fast it will or won't be, or how complex it make the kernel, or how hard : it would be to recover from a damaged file system. Agreed. : Rob Getter Michael. ------------------------------ Crossposted-To: comp.os.ms-windows.advocacy From: rwh@cccs.umn.edu (RICHARD HOFFBECK) Subject: Re: NT versus Linux Reply-To: rwh@cccs.umn.edu Date: Wed, 8 Sep 1993 14:32:00 GMT In article <1993Sep7.161524.10856@kf8nh.wariat.org>, bsa@kf8nh.wariat.org (Brandon S. Allbery) writes: > In article <26gtu2$bem@clarknet.clark.net> phil@clarknet.clark.net (Phil Anglin) writes: > >In article <1993Sep6.152653.5040@kf8nh.wariat.org> bsa@kf8nh.wariat.org (Brandon S. Allbery) writes: > >>Err, IBM went with the 8088 because Motorola *wasn't* delivering the 68000 > >>when IBM wanted it. Check your history. > > > >When *did* IBM want it? According to some Motorola books > >I was browsing through, the 68000 was introduced in '79. > > Motorola released specs (including assembly language manuals, etc., which > ultimately *were* accurate) for the 68000 in '76 --- but *shipped* it in late > '79. > > The IBM PC was shipped in '79 as well. But there *is* lead time involved in > designing a computer; they'd have needed 68000s available in '78 at the latest > in order to build (and more importantly, ship) a machine based on it. The original IBM PC was shipped in August '81. --rick ------------------------------ From: alfie@dcs.warwick.ac.uk (Nick Holloway) Subject: /sbin/sync Date: Tue, 7 Sep 1993 11:56:51 GMT Here is something to stick in your /sbin -- a small staticly linked sync, for the times when you've trashed your dynamic libs, killed update, and you want to sync before you power off to boot your rootdisk. I wouldn't normally post binaries, but here is the uuencoded binary for sync: begin 755 sbin/sync M!P%D`!0````(``````````````````````````````"X)````,V`N`$```"[ 3`````,V`````````````!``````` ` end Yep, that's right. Only 64 bytes. (And yes, I do know anything less than 1 block is as good). I should say that the inspiration for this came from James Bonfield, who had a sun4 version of "Hello, World!" in a small number of bytes, I then created a sun3 version. Now, it is actually 'xyzzy' and prints out "Nothing happens.", and following a posting by Linus works under Linux. Here is the source for sync, "sync.S": cat << \SHAR_EOF > 'sync.S' # include .text .globl _main _main: movl $(SYS_sync),%eax /* sync () */ int $0x80 movl $(SYS_exit),%eax /* exit ( 0 ) */ movl $0,%ebx int $0x80 SHAR_EOF Compile using the following "Makefile": cat << \SHAR_EOF > 'Makefile' sync: sync.S /lib/cpp $< > $@.s as -o $@.o $@.s ld -s -N -e _main $@.o -o $@ rm -f $@.[so] SHAR_EOF -- Nick Holloway | `O O' | alfie@dcs.warwick.ac.uk, alfie@warwick.UUCP, [aka `Alfie'] | // ^ \\ | ..!uunet!mcsun!uknet!warwick!alfie ------------------------------ From: heinrich@fuhainf2.fernuni-hagen.de (Friedrich Heinrichmeyer) Subject: Shared libs for InterViews3.1 Date: 8 Sep 1993 15:19:22 GMT Has anyone built shared libs for InterViews? -- Fritz Heinrichmeyer Tel.: 02371/566-243 FernUniversitaet Hagen FAX: 02371/52212 Lehrgebiet ES EMAIL: fritz.heinrichmeyer@fernuni-hagen.de Frauenstuhlweg 31 58644 Iserlohn Germany ------------------------------ From: rky57514@uxa.cso.uiuc.edu (Tall Cool One ) Subject: Support for Xircom parallel port ethernet adapters? Date: 8 Sep 1993 15:29:39 GMT I just got a Xircom parallel port ethernet adapter. Is this device currently being supported by linux? If not, will it be supported in the near future?? Thanks for any info! _I_______________________________________________________________________I_ (_@_) (_@_) | | Raymond Yeung Internet: Nimbus@uiuc.edu | | | | rky57514@uxa.cso.uiuc.edu | | | | EE student at the | | | | University of Illinois CompuServe: 70700,1011 | | | | at Urbana-Champaign | | (___)-------------------------------------------------------------------(___) I I ------------------------------ From: bmiller@milton.cs.uiuc.edu (Brad Miller) Subject: Linux and Lisp: Clisp or AKCL? Date: Wed, 8 Sep 1993 15:21:51 GMT Hi, I'm interested in porting some lisp applications I have developed under LUCID to my home PC that is using LINUX. There seem to be two options: either clisp, which is included in the SLS distribution, or AKCL, which is available on sunsite. Can anyone tell me the trade-offs between the two packages. And exactly how "common" common lisp is between LUCID and these packages? thanks ------------------------------ From: dans@panix.com (Dan Simoes) Subject: QIC tape on Linux: SUMMARY Date: 8 Sep 1993 11:29:48 -0400 Recently in comp.os.linux.misc I wrote: > 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? Here are the replies I received. Many thans to all who took the time to respond. Overall, it looks like the way to go is SCSI, albeit an expensive route at that... | Dan | --- From: jgomezr@neptune.calstatela.edu (JL Gomez) I'm using an Archive Viper QIC-02 unit using 6250 tapes. It's works great under Linux. It's an external unit so can be shared between machines. I'm selling it to get a higher capacity tape drive. Gotta backup those gig drives! :-) Wangtek QIC-02 are also supported. You'll need to get the latest kernel (PL12) because the driver is built-in. --- From bmc@cblph.att.com Wed Aug 25 10:40:55 1993 Dan, I use a Wangtek 5150EN tape drive and QIC-36 controller card on my Gateway system (486DX33, ISA). The Linux QIC-02 used to be a separate patch, but is now included in the core kernel distribution (as of 99.12, possibly 99.11). You may have to configure tpqic.h before building the kernel. I've been using this setup for several months now (originally started with a patched 99.8 kernel) and it meets my needs fine. My tape capacity is 150 MB and it takes about 40 minutes to back up a 120MB partition. I have also done a full restore from tape and that worked fine (P.S. make sure the kernel on your disaster recovery/boot disk has the QIC driver configured in :^). I'm pretty weak on the hardware side of things, so I'll not go into the ins and outs of the various QIC features. It's kind of complicated and I don't think I understand it properly. Ergo, any explanation I give is likely to be wrong or overly simplistic. --- From wfkonij@cs.vu.nl Wed Aug 25 11:57:14 1993 Well, QIC-02 is one possible interface to QIC-24/QIC-120/QIC-150/QIC-525 quarter-inch cartridge tape drives. There is also QIC-36 and (most popular) SCSI. I suggest you aim for a drive with a SCSI interface and QIC-150 or QIC-525 tape format. Most drives can also read most lower formats and fewer can also write some lower formats. (e.g. a QIC-525 drive may be able to read QIC-24/120/150/525, and write QIC-150/525) Capacities are: QIC-24 on DC600A tape 60 MB (600 ft) QIC-150 on DC6150 tape 150 MB (600 ft) QIC-150 on DC6250 tape 250 MB (1020 ft) QIC-525 on DC6320 tape 320 MB (600 ft) QIC-525 on DC6525 tape 525 MB (1020 ft) If you buy a SCSI drive, you shouldn't have much trouble connecting it to a SCSI controller and having the driver recognize it. (Some drives might require a recent firmware ROM, check the FAQs) I myself have bought an Archive 2150L/SC402 QIC-02 combo, mostly because it happened to be dead-cheap from surplus. However, a QIC-02 interface card will take up yet another IRQ line (a scarce resource), and I doubt you will find a QIC-525 drive with QIC-02 interface anywhere. --- From mjohnsto@jpmorgan.com Wed Aug 25 12:18:13 1993 Dan, I think that most, if not all, the QIC-02 drives running are probably SCSI QIC-02's. Finding a driver for a a tape that uses an adapter board is a bit tricky. As an example, I have one of the Archive 250 Meg drives which attaches to the Floppy controller. Drivers support for this are currently still in Alpha. In effect, I need to buy a SCSI drive just to backup my system. Networking options are being considered as an alternative. Backups, particularly on a system as unstable as Linux is are never an option. I think, though, that to summarize, you'll avoid a lot of problems by using SCSI tape drives. --- From jpd@usl.edu Wed Aug 25 16:16:12 1993 I am using successfully the tpqic02-2g package with Linux 0.99PL9. My tape unit is a Tecmar QT-90e, which yields ~ 100MB on a DC600a. This is a qic24 device, apparently. --- From jjctc@chevron.com Wed Aug 25 18:51:13 1993 Yes. I'm normally using DC6525s, though I have fed DC6150s (much lower capacity, of course) into my drive and Linux never complained. I use the Wangtek 5525ES (attached to an Adaptec 1542C). Works fine for me. I generally use tar, but occasionally use dd. I bought it from a local dealer at about $575 (US). I don't think the driver is in alpha. It is SCSI. -- Dan Simoes Voice: 914.747.2900 x415 Danix Consulting email: dans@panix.com or Yorktown Heights, NY dans@danix.uucp ------------------------------ From: mike@moocow.math.nat.tu-bs.de (Mike Dowling) Subject: Re: NT vs Linux vs My Daddy is Better Than Your Daddy Reply-To: on.dowling@zib-berlin.de Date: Wed, 8 Sep 1993 16:40:43 GMT >>> On Sun, 29 Aug 93 01:35:29 MDT, rickie@trickie.ersys.edmonton.ab.ca (Richard Nash) said: Nash> Can we stop the child-like reactions? Nash> The Linux crowd can only benefit from what NT has to offer. A smart Nash> person looks at both the strengths and weaknesses of the competition Nash> and works to improve themselves from this analysis. Yes we may all Nash> secretly wish that Linux will spring up from out of the underground Nash> taking the computer communities by storm causing them to throw away Nash> and divorce MicroNT in droves! Don't hold your breath..... I agree whole heartedly, but I have a very naive question nevertheless. Does Windows NT actually exist yet, or is it merely a figment of someone's imagination? Is it perhaps merely a threat by Microsoft to produce something sometime? The world is raving about Windows NT, yet, here in Germany at least, I have yet to see a supplier that actually sells it. In fact, I have yet to meet somebody who knows somebody who knows sombody who has even seen the carton in which Windows NT is sold. Microsoft was supposed to go public with Windows NT on the 4th of May this year; has it been delayed, or has it been a total flop? I have just spent 6 weeks in the United States of America, but, although I admit that I did not make a great deal of effort looking, I still did not even see an advertisement for Windows NT! ------------------------------ From: dans@panix.com (Dan Simoes) Subject: Mitsumi CDROM under Linux: SUMMARY Date: 8 Sep 1993 11:40:59 -0400 In comp.os.linux.misc, I asked about the Mitsumi CDROMs. I wrote: > I think CD-Rom is a bit of overkill for me right now on my 386-25DX with 4mb, > but I saw a great price for this in, of all places, the mall. > It was a Mitsumi kit with controller and drivers (I think) all > for $139!!! I think that's $60 less than anywhere I've seen it in > Computer Shopper. > What are your thoughts on this cdrom under Linux, and would you recommend it, > or perhaps another? Here are the replies. It looks like a good deal, although there is always something newer and better. Thanks to all who replied. | Dan | --- From jprhode@eos.ncsu.edu Wed Aug 25 11:10:22 1993 The mitsumis work fine. Get the faster one though. It should have about a 300 ms access time. These are the ones you see for about $199. The old ones are 800 ms access time drives ( like I have ) and can be -slower- than floppy drives under Linux. The slow ones are already incompatible with some DOS games which require < 350 ms access time. Hope this helps. --- From david@emc2.concordia.CA Wed Aug 25 10:40:52 1993 If it's that cheap, it could be the old model. The new model is the one with "S" at the end of the model number. Something like LUO5S or whatever. The new model is good under DOS, and even reads multisession Photo CDROM, but I haven't tried it with Linux. --- From mjohnsto@jpmorgan.com Wed Aug 25 12:13:05 1993 I have heard some conflicting reports on whether this drive works w/Linux. If you get a definitive answer from someone, let me know! I'm tempted to buy one at today's prices. --- From rwebb Wed Aug 25 15:13:39 1993 Make sure it's the "new" fast model (which isn't even so new anymore). The older 8-bit interface LU002 had an access time of 650ms or worse. The newer 16-bit model LU005S gives you expanded interrupt selection, and has an access time of 350ms. I have this one. Note that the current Linux driver for the LU002/5 does not use DMA. For the price, the newer drive was a very good deal when I bought it. Some LU005S drives manufactured during March 1993 (mostly "D" series serial number) had some chip differences that caused problems with drivers under OS/2, Linux, and maybe Photo-CD compatibility. I think this has been resolved with updated drivers since then. Mitsumi also has a new model coming out soon that is still single-speed, and around 280ms access time: no great thrill. Keep a sharp eye out for the new Panasonic drives (300kb/s). I've already seen Software Etc. OEM versions of these for $250--you might do a little better via mail order. These prices for a double-speed CD tend to lessen the value of a 150kb/s Mitsumi, unless you're utterly unconcerned about access time and transfer rate. They're proprietary, just like the Mitsumi, but do allegedly work with the alpha SB Pro CD interface drivers available for Linux. Panasonic SCSI 300kb/s SCSI versions are also apparently in the works, but if cost is your main concern, these may not be the most optimal solution. I suppose I'm very happy to have had a 150kb/s Mitsumi, but I'm definitely wanting a faster CD since I like CD-ROM games under DOS as well. I would recommend one if you're not concerned about cutting-edge applications that beg for a 300+kb/s drive. --- From grina@fujitsu.fai.com Wed Aug 25 16:45:33 1993 That sounds like a great deal. The only thing to know about Mitsumi is that the older ones have a 650ms access time, but the newer ones are 350ms. They didn't raise the price when the speeded it up, BTW. My guess is that you're looking at a 650ms CD drive, but $139 is a great price nevertheless. --- From rogersd%chaserv.UUCP@oneb.UUCP Wed Aug 25 23:23:59 1993 We've been using one under Linux for a couple of months now. Since Patchlevel 12, the kernel sources include the driver. Previous versions of Linux required patches to the kernel. All in all, it works pretty good. --- From mchapman@eis.k8.rt.bosch.de Thu Aug 26 04:02:46 1993 Short answer: y. I have a mitsumi CDROM and it works fine under Linux. I only have the old driver for it so I can't play music CD's on it (I think the new driver supports that too) but for data its fine but not very fast. (Any normal speed CD is slow). I think there are two models, one with a 16 bit card (which I have) and an older model with an 8 bit card. As far as I am aware linux only uses the thing in 8 bit mode anyway. Linux doesn't use interrupts for it either. If your machine is networked with lots of users that might upset you because anything involved with the CD swallows up gobs of CPU (but not all of it) with the polling. For my typical usage this doesn't worry me at all as I am waiting for the data anyway!! $139 seems to be a bargain, here it costs DM 330 at the moment including 15% TAX (which translates to $170 without tax at the present exchange rate). --- From bhenning@wimsey.com Thu Aug 26 02:00:36 1993 Actually it works quite well. I just had to rebuild the 0.99pl12 kernel that came with SLS1.03 to point it at the right interrupt and then just typed 'mount /dev/mcd0 /cdrom -tiso9660' or 'workman -c /dev/mcd0 &' as the mood strikes me. --- From vince@victrola.wa.com Thu Aug 26 01:06:17 1993 I just paid $190 and it installs and runs perfectly at 0.99-12. --- From ashley@alumni.cco.caltech.edu Fri Aug 27 11:23:14 1993 If you want to run stuff under DOS go for it. The price is good and you can get cdroms with, say, the wuarchive.wustl for less than $30 (MSDOS section). You can go crazy just looking through the software. BTW, if you have little children the multimedia stuff is a must, but some of it is beyond the capability of the mitsumi. --- -- Dan Simoes Voice: 914.747.2900 x415 Danix Consulting email: dans@panix.com or Yorktown Heights, NY dans@danix.uucp ------------------------------ ** 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 ******************************