From: Digestifier To: Linux-Misc@senator-bedfellow.mit.edu Reply-To: Linux-Misc@senator-bedfellow.mit.edu Date: Fri, 27 Aug 93 01:13:24 EDT Subject: Linux-Misc Digest #59 Linux-Misc Digest #59, Volume #1 Fri, 27 Aug 93 01:13:24 EDT Contents: Re: [ANNOUNCE] pwd for Linux (Peter Mutsaers) Re: Linux and Corporate America (dan@oea.hobby.nl) Re: High speed modems & Linux (Matthew Dillon) Re: 64K Vs 128K Cache:-is difference worth $40.00 (Matthew Dillon) Re: High speed modems & Linux (Matthew Dillon) could someone please.. (crazy lion) Bashing Peter MacDonald (Ed Skladany) Re: 800 meg core dump! (Ed Skladany) Re: 800 meg core dump! (Matthew Dillon) xtank: Anyone have working threads? (Phil Rzewski) postscript labels (Greg Berg) Re: High speed modems & Linux (Thomas Davis) Re: BACKUP: tar or cpio? (Brandon S. Allbery) *** PLEASE READ THIS BEFORE POSTING *** (misc-2.01) (Ian Jackson) Re: NT versus Linux (Charles Hedrick) Re: NT versus Linux (Charles Hedrick) SLIP success (Charles Hedrick) Re: Linux Ftp site..... (Charles Hedrick) Re: NT versus Linux (Charles Hedrick) ---------------------------------------------------------------------------- From: muts@compi.hobby.nl (Peter Mutsaers) Subject: Re: [ANNOUNCE] pwd for Linux Date: Thu, 26 Aug 1993 06:04:54 GMT >> On 25 Aug 1993 05:55:57 GMT, quinlan@crimson.cs.bucknell.edu >> (Daniel Quinlan) said: DQ> This is for all those people who always wanted a /bin/pwd of DQ> their own. It features an easy to understand command line, DQ> brevity, and a very short uuencoded format that I don't feel bad DQ> about posting. It is pretty much the 'standard' Unix pwd DQ> although I am not certain if it will work on non-Linux machines. DQ> The gzip'ed tar file contains a small Makefile, a manual page, DQ> and the source. What is wrong with the following /bin/pwd, which you see on several Unices:? ~> cat /bin/pwd #!/bin/sh pwd -- _______________________________________________________________ Peter Mutsaers, Bunnik (Ut), the Netherlands. Disclaimer: This reflects the official opinions of my employer. ------------------------------ From: dan@oea.hobby.nl Subject: Re: Linux and Corporate America Date: Thu, 26 Aug 1993 19:39:47 GMT Mark A. Davis (mark@taylor.uucp) wrote: : I doubt there will be a great commercial interest until Linux is binary : compatible (fully) with other 386 Unixes (COFF/ELF). At that point, much : business software will work under Linux. And when that happens, I can see : great market potential. Another approach is a VAR who can have their : key piece of software ported to Linux and then bundle Linux as the OS : for their product platform. Congratulations, you just won a prize for repeating yourself for the zillion'th time. -- |< Dan Naas dan@oea.hobby.nl >| +---------------------------------+ ------------------------------ From: dillon@moonshot.west.oic.com (Matthew Dillon) Subject: Re: High speed modems & Linux Date: 26 Aug 1993 19:11:37 -0700 In article <1993Aug26.203717.28580@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes: :In article <1993Aug26.131225.1559@mksol.dseg.ti.com> bmyers@dseg.ti.com writes: :[ ... Problems with sliding window protocols on serial ports ... ] :> :>I have a similar setup. However, I've been having problems with zmodem :>transfers. Due to other discussions, I'm thinking that it might be due to :>the way rz/sz software was compiled and/or changed as of late. : :I emailed the guy with the same problems with another sliding window :protocol and a Sun machine -- here's the gist of it: : :1) The input buffer is 128 bytes. :2) The amount of bytes in a "window" is larger than 128. :3) You get buffer overrun. :4) Flow control can't help unless your packet size is smaller than : your buffer size *and* smaller than the difference between the : high and low wather marks *and* smaller than the difference : between the high watermark and the end of the buffer. :5) The exception to #4 is devices which behave in such a way as to : suspend writes when flow-controlled. Very few modems and fewer PCs : and UNIX boxes do this because it means you can't have an interrupt : driven serial driver with "write buffer empty" interrupts to trigger : the next transmit -- the way most PC comms likes to implement fast : serial I/O. This is a common misconception. In fact, PC serial chips are the exception in their inability to do hardware flow control in hardware. Most modern serial chips such as the Signetics 68C94 (quad uart) have no problems doing hardware flow control in hardware. The 'transmit shift register empty' interrupt is simply inhibited on chip when CTS is negated. Hell, the old Commodore 6551A could even do that! With the right chip, you never have overrun problems. Any modern modem running V.42[bis] also implements end to end hardware flow control. -Matt : Terry Lambert : terry@icarus.weber.edu :--- :Any opinions in this posting are my own and not those of my present :or previous employers. Matthew Dillon dillon@moonshot.west.oic.com 1005 Apollo Way dillon@overload.berkeley.ca.us Incline Village, NV. 89451 ham: KC6LVW (no mail drop) USA Sandel-Avery Engineering (702)831-8000 [always include a portion of the original email in any response!] ------------------------------ From: dillon@moonshot.west.oic.com (Matthew Dillon) Subject: Re: 64K Vs 128K Cache:-is difference worth $40.00 Date: 26 Aug 1993 19:21:58 -0700 In article hhanemaa@cs.ruu.nl (Harm Hanemaaijer) writes: :In <1993Aug25.222312.15332@kf8nh.wariat.org> bsa@kf8nh.wariat.org (Brandon S. Allbery) writes: :>quantum. : :Most motherboards seem to be using a direct mapped cache. Isn't this in fact :a strategy not at all suited to a multi-tasking virtual memory OS? The kernel :page allocation doesn't know about the cache. If you are unlucky, processes :are trashing each others cached pages. Even in a single process, if the two :most used pages of a process happen to fall in the same cache 'page' (the :physical addresses of the pages modulo 256K are the same), things slow down. : :I've observed the speed of (benchmarked) programs change between runs. Can this :be due to page trashing? I wonder if a kernel page allocation routine can be :made to allocate pages for the sake of cache effiency. : :hhanemaa@cs.ruu.nl Your are right on the first count, and probably right on the second count. In fact, a two or four way set-associative cache is MUCH better then a direct-mapped cache. 8-way set-associative caches generally do not improve performance much above 4-way set-associative caches and can even slow things down due to design considerations. You see a lot of direct mapped caches in the PC industy because they are easy to design, even if they do not do all that much. I do not think going from 64K->128K in a direct-mapped cache would help all that much. Going from 64K->128K in an N-way associative cache would probably help quite a bit. You can't really tune direct-mapped caches with your physical page allocation scheme because programs all have different behavior... 'fixing' it for one program will probably break it for another. -Matt ------------------------------ From: dillon@moonshot.west.oic.com (Matthew Dillon) Subject: Re: High speed modems & Linux Date: 26 Aug 1993 19:28:51 -0700 In article <1993Aug26.131225.1559@mksol.dseg.ti.com> bmyers@dseg.ti.com (Bob Myers) writes: :In article 4IC@ars2.SeaSlug.ORG, briank@ars2.SeaSlug.ORG (D. Brian Kimmel) writes: :>In <25bkik$qim@news.bu.edu> heiser@bumetb.bu.edu (Bill Heiser) writes: :> :>>In article kfisher3@mach1.wlu.ca (Kevin G. Fisher) writes: :>>> Ok, this may be a dumb naiive question, but please bear with me. I :>>>just purchased a 14.4 modem (yay!). It works great on my 386-40 running SLS :>>>1.02...but one thing I've noticed. Whenever I'm doing a file transfer at :>>>14.4, if I do anything (ie start up XV or something) while the transfer is :>>>...... :>>Well I just tried a UUCP transfer of an 800kb file using a Hayes :>>14.4K modem ... and only averaged 700cps. Not good, since with he :>>same modem on a DOS machine (the same machine actually), I get 1600+ :>>... :>At home I run a worldblazer with my Linux box. I get 1950-2000 :>characters per second with compressed news feeds. I have a (lowly) :>386-16 with 4 megs of ram and a 16 meg swap space. I have a 2 serial, :>1 parallel, 1 gameport card with a chip on it that emulates 16550s. :>Paid all of $49 for it (list price - I was in a hurry). I run the :>interface at 38.4k and may move it up someday when I want to use a :>full v32bis/v42bis connection. I move 20-50 megs a day this way - day :>in and day out plus I use this same modem for logins to my system and :>also use it to log into several other unix computers. :> :>It works for me :-) :> :>Brian :>-- : :I have a similar setup. However, I've been having problems with zmodem :transfers. Due to other discussions, I'm thinking that it might be due to :the way rz/sz software was compiled and/or changed as of late. : :-bob I have a 486 DX2/66 box and am currently running a dedicated SLIP link at 38400 bps. When idle, there are virtually no packet errors. When there is hard disk activity, I get a whole hell of a lot of packet errors due to overruns. In terms of modems ... I would suggest the Zyxel U-1496E (around $300)... It's V.32bis, really solid, and has averaging modes to help with poor PC boxes that can't do hardware flow control in hardware (like all PC boxes with national serial chips?). I also have a Supra V.32bis modem but I would NOT reccommend anybody buy the Supra.. the Supra uses the Rockwell chipset and flakes out on a lot of connections... I can connect my Zyxel at 14.4KB dialing up one place where my Supra only works at 7200bps!!! Also, the Supra drops out sometimes whereas the Zyxel never has, and power glitches can 'crash' the Supra to the point where you loose the configuration and have to power cycle it. The Zyxel is much more reliable. -Matt ------------------------------ From: rlion@access.digex.net (crazy lion) Crossposted-To: comp.os.linux Subject: could someone please.. Date: 26 Aug 1993 22:34:41 -0400 could someone please send me a copy of any terminal program that they have compiled and running for linux or X. I can' get anything to let me call out, so if anyone could help me out, i'd be greatful. rl ------------------------------ From: eds@VFL.Paramax.COM (Ed Skladany) Subject: Bashing Peter MacDonald Date: Fri, 27 Aug 1993 02:45:17 GMT It's amazing that some people keep bashing Peter MacDonald for problems with SLS. SLS is not a perfect release, but it is the release responsible for getting thousands of people started with Linux, including me. For this, we owe Peter our gratitude. His product must have taken a lot of work, but it's effectively free for the asking. The simple installation of Linux is something that can always be improved upon, but Peter made it happen. Yes, I know SLS is sometimes slow to upgrade to new tools releases, and his distribution sometimes is lacking in completeness, but it's wonderful considering the price. I certainly appreciate Peter's work. 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. -- -- Ed Skladany | Internet: eds@vfl.paramax.com Paramax Systems, A Unisys Company | UUCP: ...!gvls1!eds Valley Forge Laboratories | Box 517, Paoli, PA 19301 USA ------------------------------ From: eds@VFL.Paramax.COM (Ed Skladany) Subject: Re: 800 meg core dump! Date: Fri, 27 Aug 1993 02:54:17 GMT [ Stuff about programs dumping huge core files deleted. ] Yes, Linux can produce disk-filling core files when tools are run with incompatible library versions. This happened to me trying to run an xpilot binary with an older library. This can be prevented in bash and tcsh. Here's the entry from the latest FAQ: Question 6.5. How do I stop producing core files ? If you use bash put ulimit -c 0 in your .shrc or .bashrc; if you use tcsh put limit coredumpsize 0 in your .cshrc. For other shells check the shell's manpage. -- -- Ed Skladany | Internet: eds@vfl.paramax.com Paramax Systems, A Unisys Company | UUCP: ...!gvls1!eds Valley Forge Laboratories | Box 517, Paoli, PA 19301 USA ------------------------------ From: dillon@moonshot.west.oic.com (Matthew Dillon) Subject: Re: 800 meg core dump! Date: 26 Aug 1993 19:50:43 -0700 In article MARK@ardsley.business.uwo.ca (Mark_Bramwell) writes: :I was 'talk'ing with someone a we had a core dump. It filled my disk which :had 800megs free. : :Just a note. I am running SLS from last week. 99pl12 : :=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= :Mark Bramwell, VE3PZR Located in sunny London, Ontario : :Internet: Mark@ARDSLEY.business.uwo.ca IP Address: 129.100.22.33 : Packet: VE3PZR @ VE3GYQ UWO Phone: (519) 661-3714 That happenned to me too... 600+ MB core dump from rlogin. It also crashed the system, but that turned out to be another problem. You can limit core dump sizes with 'ulimit' from bash and 'limit' from tcsh: tcsh: limit core 0 - disable core dumps entirely limit core 1m - 1M maximum size etc.. bash: ulimit -c 0 - disable core dumps entirely ulimit -c 1000 - limit to 1M (I think, I'm a tcsh user myself) NOTE: resource limits such as the core size limit are local to the process and inherited by children, but will NOT effect other shells unless you put the command(s) in the appropriate *rc file. -Matt ------------------------------ From: kutcha@clotho.acm.rpi.edu (Phil Rzewski) Subject: xtank: Anyone have working threads? Date: 27 Aug 1993 03:38:35 GMT As is a rather well-known fact by now, the only xtank program available for linux on the standard ftp sites is a binary that is wired into some archaic libraries. I have no idea if that version had working threads or not. Anyway, I got a fresh source copy of xtank-1.3f off of export and compiled it with minimal effort on my linux box. Unfortunately, whenever I tried to run it with the THREAD_MP enabled, it would core dump as soon as I tried to play it. So I was forced to compile without it and now the computer robots don't move at all. I asked someone in the #linux channel on IRC and they said that they knew people that had gotten the threads working for linux (either by tweaking THREAD_MP or by writing all new threads just for linux, they didn't specify) so I'm assuming that SOMEONE out there has the patches necessary. If you do, I'd like to ask that you mail them to me or make them publically available on an ftp site and mail me as to their location or post as to their location. I'm certain that many others are interested in this. If you're as interested in this as I am, it's probably not worth your time to mail me and say "mail me too when you find out". I promise I'll post about and put on ftp anything conclusive I find. :) Thanks all. -- Phillip Andrew Rzewski Internet: kutcha@acm.rpi.edu "Change what you cannot accept, do not accept what you can't change." -- c$c ------------------------------ From: gberg@netcom.com (Greg Berg) Subject: postscript labels Date: Fri, 27 Aug 1993 03:41:17 GMT What if... the remaining blank labels on set 3 included titles for: std boot disk, custom1 boot disk, custom2 boot disk... A box of labels costs ~$35.00. Why not print other labels on the sheet? What labels would _you_ like to see in the set? -Greg ------------------------------ From: tdavis@unocss.unomaha.edu (Thomas Davis) Subject: Re: High speed modems & Linux Date: Fri, 27 Aug 1993 03:50:59 GMT dillon@moonshot.west.oic.com (Matthew Dillon) writes: >In article <1993Aug26.131225.1559@mksol.dseg.ti.com> bmyers@dseg.ti.com (Bob > In terms of modems ... I would suggest the Zyxel U-1496E (around $300)... >It's V.32bis, really solid, and has averaging modes to help with poor PC boxes >that can't do hardware flow control in hardware (like all PC boxes with >national serial chips?). I also have a Supra V.32bis modem but I would NOT Nice? It's an understatement. I just finished putting a Linux box a (486/33, 8 megs of ram, 210 IDE, 2x16550, Orchid 1280) together, installed, and running in a powerplant in the California desert. It is talking over a 4 wire leased line, to a terminal server running SLIP. The Terminal server is talking 56k to the ZyXEL U1496PLUS modem, and the Linux box is talking to another U1496PLUS modem at 38.4k. Guess what it replaced? An AT&T PARADYNE 19.2k modem! What's great about this setup is the speed it gets between the two modems.. 19.2k, minimum between the two! And if the line quality goes down, it will cycle down, and then come backup when the line quality returns. Most HS modems don't come back up.. All this on 40 miles of desert phone line! The fun thing we did was when I had to replace a executable on the linux pc from Omaha NE.. ftp'd it up there, and then, to really blow the admin's mind, I decided to run it! We did a rxvt session over a 56k line, through the terminal server running SLIP, and it just flew.. Now, that's networking! The moral of the story? Cheap modems are just that! Cheap! Get a good heavy duty modem, and have zero, zip problems. -- Thomas Davis | Internet: tdavis@beeble.omahug.org Freelance Systems Consultant | UUCP: uunet!ivgate!beeble!tdavis Davis Engineering | Snail Mail: 8803 Webster Plaza | Omaha, NE 68114 ------------------------------ From: bsa@kf8nh.wariat.org (Brandon S. Allbery) Subject: Re: BACKUP: tar or cpio? Date: Fri, 27 Aug 1993 03:22:01 GMT In article MARK@ardsley.business.uwo.ca (Mark_Bramwell) writes: >I can't remember cpio off the top of my head. I am not sure if both would >give me everything... ie: empty directories, zero-length files, links and >not 2 separate files, etc... Both will give you this, at least with the correct options. Unfortunately, tar won't restore the right ownerships unless the password file is intact, because it records user and group names instead of uids and gids; and the only option I've seen to change this (in the SLS version of tar, at least) also prevents it from backing up device nodes. So if you boot from the a1 disk and restore yoru backup to the hard drive, everything ends up owned by root. :-( cpio uses the numeric uid and gid. It backs up everything. (Specifically: everything that you send to it with "find".) It *restores* everything, including ownerships. I've been using "cpio -H crc" to back up my system for several months. I did a restore *today* (trying Yet Again to track down the 16MB gremlin in my !@#$%&* motherboard) and it worked fine. Then again, I didn't need to restore from a boot floppy. But I've done that as well, and it works. ++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: ijackson@nyx.cs.du.edu (Ian Jackson) Subject: *** PLEASE READ THIS BEFORE POSTING *** (misc-2.01) Date: Fri, 27 Aug 1993 04:23:01 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: hedrick@geneva.rutgers.edu (Charles Hedrick) Crossposted-To: comp.os.ms-windows.advocacy Subject: Re: NT versus Linux Date: 21 Aug 93 16:51:55 GMT There's been enough discussion already about the errors in the original posting that I don't want to talk about that. I would however like to talk about what might be done to make NT more useful to people who have needs similar to those of most Linux users. Many people -- particularly in universities -- either need or want a software environment in which they can look at and change the source for the system software. Loadable device drivers may reduce the need for this, but they are unlikely to eliminate it. Furthermore, even if one can in principle write a loadable driver or file system, if source to all the existing ones is secret, it is much more difficult for people to write new ones. One of the big advantages of Unix has always been that you could look at the source. (I could never understand why anyone would want Unix without source. This is probably why it didn't spread very far outside the university community, where source has always been available.) This makes it much easier to figure out how to do new things. In principle it should be possible to build a Linux (or BSD, or whatever) subsystem under NT. It would have a full set of Unix-like utilities, and be distributed with source. Then you could do your hacking in that subsystem, and use the native NT subsystem for commercial applications. However this is a fairly large project. In practice it's unlikely that it will happen without Microsoft's help, as the expertise to build a new subsystem doesn't seem like something many people are going to have. I'd bet that in practice you'd need to look at code for parts of NT. It's even possible that something like this could be done by porting Gnu code to the existing POSIX subsystem, though descriptions of the POSIX subsystem don't sound all that encouraging. There are also architectural issues involved. For example, the Windows subsystem has a privileged position in NT that may (or may not) make it difficult to do X in a way that I think we'd want to do it. (I would certainly want my Windows windows to be under the control of the X window manager, not the reverse.) In the short run, the most helpful thing for NT would be to begin building up a body of system code whose source is available. Ports of the Gnu utilities would be one possibility. This certainly includes things like network drivers. I have a copy of NT. In some ways I like it. But I can't use it in any serious way until there's a SLIP driver for it. I've seen several public software repositories for NT. However so far I haven't seen source for the software that's there. I think the Linux community is unlikely to become interested in NT as long as the existing NT community is unwilling to share source. (I've also been chagrined to see that most of the software in these repositories doesn't work in the final release. I tried loading up a sample of it. The only program that worked was ls, and it was compiled recently enough that I think it may have been built on the final release.) Note that I am not a Gnu bigot -- I have no moral objections to companies producing commercial software and keeping their source secret. I'm even willing to use software from that realm to do my income tax. However I also see the need for the traditional Unix community, which operates by sharing knowledge and source. (I *do* have problems with universities producing software and not sharing source with other universities.) ------------------------------ From: hedrick@geneva.rutgers.edu (Charles Hedrick) Crossposted-To: comp.os.ms-windows.advocacy Subject: Re: NT versus Linux Date: 22 Aug 93 22:24:34 GMT Some of jwiegand@manny.eng.temple.edu (Don't Panic!)'s comments about NT are out of date. Just for background, let me note that I'm primarily a Linux user, and will probably stay that way. My experience with NT and OS/2 2.1 is brief, and in general I think I slightly prefer OS/2 to NT. (This is partly because none of the software I want to run is available for NT, whereas the OS/2 hacker community has been busily at work porting just about everything that's available under Linux. I'm really quite impressed. As usual OS/2's P.R. has been lousy. Also I slightly prefer the PM user interface to Windows. However each systems has its advantages, and I do see a number of good things about NT. A year from now I hope enough will have happened in the NT hacker community that my evaluation might be different.) >NT is vaproware. Where is the shrink-wrap version? Egghead? Not! NT is available commercially. It's been sighted in Egghead. I got a copy from an equivalent store (Software, Etc.). >The QIC-80 driver is loadable. You can install it today, along with >your new Diamond SpeedStar NT drivers (not). While this is true, one needs at least to point out that the ability to load drivers is not in the distributed kernel. While kernel patches are no problem for me, I believe a number of users would be reluctant to do it. >I don't know for sure how NT handles QIC-80. I do know that it is >tightly coupled to system timing (serial communication through >floppy select lines) and the best way to set up QIC-80 transfers >is to turn off the multitasking. That is the fool-proof way to meet the >timing specs. QIC-117 makes that abundantly clear. Read your copy. I had no problem backing up a 128 MB partition to a Colorado Memory Systems 250 drive under NT, while simultaenously doing other things. (The other things were not heavy computing. But I did use the serial line and look around at files.) I also had no trouble using the tape drive under OS/2 from a DOS session (using PCTools Deluxe pcbackup) while doing other things. (This is a far less attractive backup approach than having the system's backup utility understand the tape drive. The DOS software won't see files with long file names. I mention it simply to indicate that the system level problems may not be as bad as some had feared.) ------------------------------ From: hedrick@geneva.rutgers.edu (Charles Hedrick) Subject: SLIP success Date: 22 Aug 93 23:14:02 GMT Not surprisingly, posts here tend to be bug reports. Unfortunately this can give the wrong impression to people who are trying to decide whether it's worth trying something. Thus I thought I'd report that I'm reasonably pleased with the status of TCP/IP in 0.99pl11 and 12, for use with SLIP. I'm not able to comment on the reliability of Linux on Ethernets. I have some reason to think that there may still be problems there, particularly if you try to use the machine as a server, with lots of users using lots of different TCP/IP connections. But many of us aren't using our machines that way, and I think it's worth noting that many people will find the current SLIP implementation quite handy. Like some other people, I've seen problems with rlogin and talk, but these seem to be problems with the application, not the basic TCP/IP (and based on previous messages, there may be versions of rlogin and talk that are fixed). I have multiple telnet sessions going most of the time, and FTP substantial files regularly. Now and then I'll use an X application. (I don't do that regularly simply because X windows take so long to start up over a dialup. Rather than using xterm on the remote machine, I get similar results with much better performance by running telnet in a local xterm window.) I haven't seen any trouble, other than having to change my startup script for 0.99pl12 to get past the "network unreachable" problem. ------------------------------ From: hedrick@geneva.rutgers.edu (Charles Hedrick) Subject: Re: Linux Ftp site..... Date: 23 Aug 93 05:21:24 GMT shampoo@shell.portal.com (Daniel - Shsu) writes: > Hi all you linux users... > I want to install a sort of x-windows on my pc. I was wondering where >can I get a demo copy of linux. I want to see how is it. If there is a >ftp site where I can get this demo. > Thank You very much... > Dan Given that Linux is free, it's not clear that there's quite the same need for "demo copy" as with commercial software. You can try the real thing. If you want a way to try out Linux without freeing a partition on your disk, the packages/GCC/rootdisk or the first couple of disks in the SLS distribution (a1 and a2) might work. However if your goal is to test X, that's going to be hard without doing at least some level of real installation. Because of differences in monitors and display adapters (which the vendors handle for you under DOS, but Linux users have to deal with themselves), configuring X probably causes more trouble than the rest of the installation combined. ------------------------------ From: hedrick@geneva.rutgers.edu (Charles Hedrick) Crossposted-To: comp.os.ms-windows.advocacy Subject: Re: NT versus Linux Date: 23 Aug 93 05:27:45 GMT kevin@frobozz.sccsi.com (Kevin Brown) writes: >>>>linux user must constantly watch for memory useage, if linux needs a >>>>few more kilobytes than are available, it doesn't complain, it just >>>>crawls to a halt before dying a miserable death, taking down the whole >>>>system with it. >From looking at the code, it was true of pl10. Here's the relevant code: The code is different in pl12. There is a check to see whether it's safe to allocate more memory. The only thing that bothers me about the code is that it looks like if the expansion fails it simply returns the current break, rather than generating an actual error. Maybe I'm missing something... ------------------------------ ** 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 ******************************