From: Digestifier To: Linux-Misc@senator-bedfellow.mit.edu Reply-To: Linux-Misc@senator-bedfellow.mit.edu Date: Sun, 29 Aug 93 23:13:10 EDT Subject: Linux-Misc Digest #70 Linux-Misc Digest #70, Volume #1 Sun, 29 Aug 93 23:13:10 EDT Contents: WANTED: Compiled Xmosiac + term (David Simpson) Re: SLS considered harmful (wasRe: Bashing Peter MacDonald) (Peter MacDonald) Re: Stacker-like Compression? (Curtis L. Olson) Re: Zyxel modems & Linux (David Fox) Re: NT versus Linux (Mark A. Davis) "tip" (dialup term program) available for testing (Derek Upham) Re: has anyone done booted a diskless Sun 3 from Linux? (Per Andersson) [Q] 10baseT ethernet card recommendations? (joanne mc nichols) Re: SLS considered harmful (wasRe: Bashing Peter MacDonald) (Steve McMahon) Re: Stacker-like Compression? (Ian McCloghrie) Re: Bashing Peter MacDonald (rodrigo vanegas) Re: Stacker-like Compression? (Brandon S. Allbery) Re: Stacker-like Compression? (Ian McCloghrie) *** PLEASE READ THIS BEFORE POSTING *** (misc-2.01) (Ian Jackson) Re: Stacker-like Compression? (Howlin' Bob) ---------------------------------------------------------------------------- From: davesimp@soda.berkeley.edu (David Simpson) Subject: WANTED: Compiled Xmosiac + term Date: 29 Aug 1993 22:25:21 GMT Well, I saw a statically linked with Motif version of Xmosaic on sunsite. I also saw a patch to allow Xmosaic to work over term. Unfortunately I don't have motif on my system, so I can't recompile Xmosaic with term enabled. Has someone done this? If so, can you send me the binaries or put them up for anonymous ftp somewhere. Thanks. Dave Simpson davesimp@soda.berkeley.edu ------------------------------ From: pmacdona@sanjuan (Peter MacDonald) Subject: Re: SLS considered harmful (wasRe: Bashing Peter MacDonald) Date: Sun, 29 Aug 93 22:42:38 GMT In article <25qgp2$t5g@samba.oit.unc.edu> mdw@sunSITE.unc.edu (Matt Welsh) writes: >I have to agree that childish complaints against Peter's work are >unwarranted. However, I feel personally responsible for at least some >of SLS's popularity: after all, I advocate it in virtually all of the >current Linux documentation. > >Why? I don't think that SLS is the best release available. I think that >SLS needs a lot of help, from someone who knows something about packaging ... Anyone who has been around for a while might remember that I have repeatedly asked people to take over administration of series or packages. The only respondants ever were Thomas Dunbar (TeX) and Vince Skahan (newspak). And Vince is no longer on board. Putting a distribution together is not too tough. But keeping it up to date with all the interdependancies is harder. Compounding the problem is that I also seem to do a lot of kernel tinkering. I have long said that this is to big of a job for one person. There are some outstanding bugs or shortcomings with SLS. However, it is also true that many of the reports are not exactly straightforward. For example, someone posts that the way to make a swapfile is: dd if=/dev/hda of=/dev/swap count=4096 bs=1k The subsequent damage is blamed on SLS having a soft link for /dev/swap. This was just a harmless oversight, until someone followed the above bad advice. And, just about all manor of user problems are blamed on SLS. Despite this, I daily get mail from people using SLS successfully. On the other hand, I have been thinking for some time that it would be a good idea to have a test site for upgrading to new releases. It just seems few heed the warning not to upgrade right after a new release. Also, SLS has a great many installation options. Testing all of them myself is out of the question. A case in point: I always install on a single partition. But in 1.03, a bug crept in with the /root in fstab, only for multipartition installs. Although it was fixed in 3 days, I still hear reports of it. If anyone wishes to help by taking over control of some portion of SLS, let me know. However, to be frank, I don't know if I am too optimistic about people stepping forward. It is much easier to criticise and tear down, than it is to particpate and become the target of criticism. Peter ------------------------------ From: olson@micro.cs.umn.edu (Curtis L. Olson) Subject: Re: Stacker-like Compression? Date: Sun, 29 Aug 1993 23:05:57 GMT In response to: > > Is there a stacker-like on the fly disk compression software for Linux? kfogel@colossus.cs.oberlin.edu (Karl Fogel) writes: >Hey, would it be difficult to add a feature to the kernel >whereby gunzip is automatically called on any compressed file when >access to it is requested (and gzip called when it's time to write?) >This would amount to on-the-fly compression (although one had better >be sure to have a working and uncompressed version of g[un]zip -- >perhaps it could be included in the kernel itself, or something?) How would this work when you performed some operation that accessed a large group of files, like backing up your entire hard disk? Curt. -- . --o0o-- Curtis Olson (olson@cs.umn.edu) ------------------------------ From: dfox@hip-hop.suvl.ca.us (David Fox) Subject: Re: Zyxel modems & Linux Date: Sun, 29 Aug 1993 20:33:18 GMT Enrico Scotoni (Enrico.Scotoni@p46.f520.n301.z2.fido.imp.com) wrote: : hi 2u2, : > Hi. Zyxel modems were mentioned several times as a good modem : ^^^^ : simply the best : Features: : - 14'400 bps (V32bis, V42bis) : - up to 16'800 bps + 19'200 bsp proprietery : - Fax up to 14'400 bps : - Voice (your pc turnes into a phone-answring machine) Yum. I've heard something about a thing called 'modgetty' or is it 'mgetty'? that you can use to run on Linux and use the box as a phone answering machine without any extra hardware. This is nice, but where to get the needed files? : regards : Enrico Scotoni -- David E. Fox email: hip-hop!dfox@amdahl.com 5479 Castle Manor Drive San Jose, CA 95129 Thanks for letting me change the magnetic 408/ 253-7992 images on your hard drive. ------------------------------ From: mark@taylor.uucp (Mark A. Davis) Subject: Re: NT versus Linux Date: Sun, 29 Aug 1993 23:04:22 GMT ses@tipper.oit.unc.edu (Simon E Spero) writes: >In article <1993Aug29.183608.21655@taylor.uucp>, >Mark A. Davis wrote: >>hedrick@geneva.rutgers.edu (Charles Hedrick) writes: >> >>>NT is actually a multi-user system. >> >>That is totally incorrect, >To set matters straight; _NT_ is a multi-user operating system in that NT >allows for multiple processes to be run by different owning users at the >same time. Access to shared resources such as files can be controlled through >the use of ACLS. >NT 3.1 does not provide any applications to allow a remote user to 'login' >and execute arbritrary programs. In addition, there is no documented API >for obtaining a token to allow a process to act as a different user (setuid >and friends). mail complaints to postmaster@FTC.gov >In a nutshell, NT is a true multi-user operating system, but at present >there's no real way of making use of that fact apart from logging on and >off. Perhaps semantics but- NT is NOT Multi-user. It may have aspects of multiuser support in it, but it is operationally not multi-user. Oh, btw, besides a non-existent telnet session with NT, what devices would even enable NT to support real-life multi-user functions? It can't talk to terminals, has no termcap/terminfo, can't use X or Xterminals. Perhaps if it really ever does support multi-user, should all the users share the console? -- /--------------------------------------------------------------------------\ | Mark A. Davis | Lake Taylor Hospital | Norfolk, VA (804)-461-5001x431 | | Sys.Administrator| Computer Services | mark@taylor.wyvern.com .uucp | \--------------------------------------------------------------------------/ ------------------------------ From: upham@cs.ubc.ca (Derek Upham) Subject: "tip" (dialup term program) available for testing Date: 29 Aug 1993 16:49:24 -0700 There's now a version of "tip" that seems to work correctly for Linux. It's in "ftp.cs.ubc.ca:pub/pickup/upham/tip.tar.z". For those of you who have absolutely no idea what I'm talking about, "tip" is one of the granddaddies of remote dialup programs (it's from the late 70s or the early 80s, at least). I decided to port it because it's really really small---my static binary is just over 100k, compared to ~330k for a shared "kermit". The interface is also much simpler than other available terminal programs, which will make it easier to automate dialups (I hope). The main changes I've made are as follows: * The terminal drivers are now Posix, not BSD. This meant abandoning support for everything but Hayes modems (that's the only type I have to test). * "tip" used to catch ^A and ^P characters, doing uppercasing with them. I've put those functions onto tilde escapes like the others. This means "tip" is now suitable for use with "tcsh" and "emacs". :) * I've trimmed the run-time messages slightly (just to be a bit less verbose, and easier to write regexps for). * Sending tip an empty string ('', for example) now connects you directly to the modem without dialing. Then you can set registers or do whatever you want. This version of "tip" seems much better-suited for use on a small system than any of the alternatives. For example, "tip" and "rz" on a bootable diskette should be enough to snarf other software from a BBS or mainframe in an emergency. Try out the program and let me know if there are any bugs. Derek -- Derek Lynn Upham University of British Columbia upham@cs.ubc.ca Computer Science Department ============================================================================= "Ha! Your Leaping Tiger Kung Fu is no match for my Frightened Piglet Style!" ------------------------------ From: ppan@celsiustech.se (Per Andersson) Subject: Re: has anyone done booted a diskless Sun 3 from Linux? Date: Sun, 29 Aug 1993 23:47:09 GMT In article <35995@galaxy.ucr.edu> jason@galaxy.ucr.edu (jason bishop) writes: > > Seriously, to have a working sun you would need a server with >a working xdm, tftp, bootp, portmap and nfs, right? anything else? Wrong (sorry). What you need is this: rarpd - to get the IP-address tftpd - to load the boot program bootparamd (NOT bootp) to get info on root and swapfiles/filesystem. Not a problem since it is included in Xkernel, written by someone@nada.kth.se. NFS (rpc included) If SUNs had used bootp as for example RS6000 does life would have been much easier. Anybody working on BPF support for Linux ? ( BPF is the Berkeley Packet Filter, for raw access to network interfaces) -- ============================================================================= Per Andersson - ppan@celsiustech.se (perand@stacken.kth.se on free time) Managing networks ( and occasionally SUNs) at, but not speaking for: CelsiusTech AB, J{rf{lla, Sweden ------------------------------ Crossposted-To: comp.os.linux.help From: pre2@kimbark.uchicago.edu (joanne mc nichols) Subject: [Q] 10baseT ethernet card recommendations? Reply-To: pre2@midway.uchicago.edu Date: Mon, 30 Aug 1993 00:29:55 GMT Hello netting Linux users! I find myself in the fortunate position of getting an ethernet connection to the internet. I have read the NET-2 FAQ, but I still have one question with which I would like some help: Does anybody have any recommendations for 10baseT ethernet cards? I am unsure which models in the FAQ are 10baseT, and the FAQ does not really make any hints as to price/performance for these cards. Any help you could give for these cards would be GREATLY appreciated (distributors and prices would even be a bigger plus!) since I will be buying the card sometime this week. Thanks a lot! Joanne Mc Nichols (pre2@kimbark.uchicago.edu) ------------------------------ From: steve.mcmahon@lambada.oit.unc.edu (Steve McMahon) Subject: Re: SLS considered harmful (wasRe: Bashing Peter MacDonald) Date: 30 Aug 93 00:42:11 GMT >>>>> On Sun, 29 Aug 93 22:42:38 GMT, pmacdona@sanjuan (Peter MacDonald) said: PM> If anyone wishes to help by taking over control of some portion of PM> SLS, let me know. However, to be frank, I don't know if I am too Are you going to give those some portion of the proceeds? And what restrictions are going to place on their work? -Steve ------------------------------ From: imcclogh@cs.ucsd.edu (Ian McCloghrie) Subject: Re: Stacker-like Compression? Date: 30 Aug 93 00:30:55 GMT kfogel@colossus.cs.oberlin.edu (Karl Fogel) writes: >In article <1993Aug29.184348.21751@taylor.uucp> mark@taylor.uucp (Mark A. Davis) writes: > Hey, would it be difficult to add a feature to the kernel >whereby gunzip is automatically called on any compressed file when >access to it is requested (and gzip called when it's time to write?) >This would amount to on-the-fly compression (although one had better >be sure to have a working and uncompressed version of g[un]zip -- >perhaps it could be included in the kernel itself, or something?) Ummm... This has the downside of requiring a _significant_ amount of extra code in the kernel. This is gzip on my system: 57 -rwxr-xr-x 3 root wheel 56610 Jul 1 18:29 /usr/bin/gzip* That's using shared libs and optimized/stripped as far as it'll go. You don't get to use the shared libs with the kernel. 60K is a hefty chunk of code to be adding to the kernel, the word here is "bloat". Leaving it as a user-process is going to a) horribly slow (gzip is not what you'd call really fast) and b) create MASSIVE admin headaces. (like the ever-present problem with the /lib/libc.so.4 symlink, but 10 times worse). A compressed filesystem needs its own compression algorithm, designed specifically for the purpose it is being used for, a general purpose program like gzip is too inefficient in this role. I, personally, dislike compressed filesystems because A) they're slow (don't tell me about how much faster a 486/50 CPU speed is compared to disk access, I've got a 386/25). and B) cleaning up from little 'accidents' is much, MUCH harder. -- /~> 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: rv@cs.brown.edu (rodrigo vanegas) Subject: Re: Bashing Peter MacDonald Date: Mon, 30 Aug 1993 02:23:11 GMT In article <1993Aug27.024517.19825@VFL.Paramax.COM>, eds@VFL.Paramax.COM (Ed Skladany) writes: > Lighten up, grouches. If you're willing to devote the time to > produce your own binary Linux distribution that's better than SLS, > then you have a right to complain. Otherwise, just describe the > problem objectively and keep the childish remarks to yourself. Well, i don't have time myself. But there are other distributions out there! Try the MCC distribution, for example, which i found to be much simpler and far more reliable. It doesn't come with X you say? Well it does come with instructions for getting X, so this is hardly a drawback. SLS bashing happens not because we don't appreciate Peter's job but because we also appreciate the better job being done by the compilers of other distributions. Don't take it personally... rodrigo vanegas rv@cs.brown.edu ------------------------------ From: bsa@kf8nh.wariat.org (Brandon S. Allbery) Subject: Re: Stacker-like Compression? Date: Mon, 30 Aug 1993 01:43:13 GMT In article <53891@sdcc12.ucsd.edu> imcclogh@cs.ucsd.edu (Ian McCloghrie) writes: >kfogel@colossus.cs.oberlin.edu (Karl Fogel) writes: >>In article <1993Aug29.184348.21751@taylor.uucp> mark@taylor.uucp (Mark A. Davis) writes: >> Hey, would it be difficult to add a feature to the kernel >>whereby gunzip is automatically called on any compressed file when >>access to it is requested (and gzip called when it's time to write?) >>This would amount to on-the-fly compression (although one had better >>be sure to have a working and uncompressed version of g[un]zip -- >>perhaps it could be included in the kernel itself, or something?) > > Ummm... This has the downside of requiring a _significant_ amount >of extra code in the kernel. This is gzip on my system: Everybody's missing the hardest part: random access. Any program which does an open-for-append will also trigger it: how do you cope with seek-to-end- then-write? Transparently uncompress into an invisible file at open time and then write, then recompress at close? SLOOOOOOOOWWWWWW.... ++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: imcclogh@cs.ucsd.edu (Ian McCloghrie) Subject: Re: Stacker-like Compression? Date: 30 Aug 93 01:58:33 GMT bsa@kf8nh.wariat.org (Brandon S. Allbery) writes: >In article <53891@sdcc12.ucsd.edu> imcclogh@cs.ucsd.edu (Ian McCloghrie) writes: >>kfogel@colossus.cs.oberlin.edu (Karl Fogel) writes: >> >> Ummm... This has the downside of requiring a _significant_ amount >>of extra code in the kernel. This is gzip on my system: >Everybody's missing the hardest part: random access. Any program which does >an open-for-append will also trigger it: how do you cope with seek-to-end- >then-write? Transparently uncompress into an invisible file at open time and >then write, then recompress at close? SLOOOOOOOOWWWWWW.... 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 :) -- /~> 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: ijackson@nyx.cs.du.edu (Ian Jackson) Subject: *** PLEASE READ THIS BEFORE POSTING *** (misc-2.01) Date: Mon, 30 Aug 1993 02:23:02 GMT Please do not post questions to comp.os.linux.misc. 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: gt8134b@prism.gatech.EDU (Howlin' Bob) Subject: Re: Stacker-like Compression? Date: 30 Aug 93 02:27:45 GMT bsa@kf8nh.wariat.org (Brandon S. Allbery) writes: >Everybody's missing the hardest part: random access. Any program which does >an open-for-append will also trigger it: how do you cope with seek-to-end- >then-write? Transparently uncompress into an invisible file at open time and >then write, then recompress at close? SLOOOOOOOOWWWWWW.... I think that you're missing the *point*: a compressed filesystem is really only optimal for certain types of files, no matter how it's implemented. Large non-writable files (executables, Info pages, etc.) are excellent candidates for compression, especially if they're rarely accessed. Random access read and sequential write are fairly easy to support in the (de)compression code, and I think that's whtat Stephen Tweedie is aiming for. The compression will be done in-kernel, but I don't know if he's using the gzip algorithm or something else. -- Robert Sanders Georgia Institute of Technology, Atlanta Georgia, 30332 uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt8134b Internet: gt8134b@prism.gatech.edu ------------------------------ ** 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 ******************************