> This may have already been discussed, but I can't find it:
quoted text
> uncompress gives me "out of memory" "segmentation violation"
> errors on some files, for instance uniq.Z as found on tsx-11.
> I am running .11 on a 386sx-16.  Anyone have any ideas?  I had
> no problems with compress under .10...

As already has been noted, this can be (and in this case seems to have
been) due to corrupted Z-files.  However, if anybody else sees the "out
of memory" error, even though there should be enough memory there is
always another possibility: if your "/etc/passwd" (or possibly
"/etc/group") files are not in the right format, it triggers a bug in
the old library which will use up all your memory.  Great fun.  Check
that all entries in your "/etc/passwd" have the right nr of colons (even
if there is no shell name, the last colon is supposed to exist).  This
same bug shows up in all programs that use the "getpwent()" library call
with the old lib: ls -l, chown et.al.  Easy to correct the /etc/passwd
file, and then this should go away. 

Then on to a /real/ bug, which needs kernel recompilation, but isn't
very noticeable: the execve system call incorrectly clears all signal
handler addresses. It should leave the "SIG_IGN" addresses as is: nohup
etc programs depend on that. The fix is easy:

linux/fs/exec.c: do_execve(), right after the comment "point of no
return" there is the for-loop that clears the sa.sa_handler entries.
Change it from (something like)

	for (i=0 ; i<32 ; i++)
		current->sa[i].sa_handler = NULL;

to

	for (i=0 ; i<32 ; i++)
		if (current->sa[i].sa_handler != SIG_IGN)
			current->sa[i].sa_handler = NULL;

Additionally you need to include signal.h at the top of the file. (Note
that this "patch" may not be exact - this is from memory).

quoted text
> [ kermit send/receive binary ]

I use kermit to receive files, and even for terminal emulation, now that
linux correctly handles the ISIG flag. I always "set filetype binary" in
both ends, but don't know if it's really necessary (but it's easy to
make a ".kermrc" file in your home-directory to do these kinds of setups
automatically). I'd suggest you do likewise: then I know it works.

quoted text
> Has anyone tried bringing up g++ on linux? [ gcc2 and c386 ]

I've been thinking about this (hi tytso :), and I will port gcc-2.0 (or
1.99) as soon as it is available.  That should contain g++.  Probably in
january-february says tytso.  During the holiday, I will implement VM
(real paging to disk): I've been going over the algorithms in my head,
and I think it can be done relatively easily, so hopefully we can scrap
the c386 compiler (sorry, blum).  The paging algorithm will at least in
the beginning be extremely simple: no LRU or similar, just a simple "get
next page in the VM-space".  Note that VM isn't (even with a good
algorithm) a "holy grail" - I don't want to be on the same machine when
someone uses gcc in 2M real mem.  Slooooowww.  4M will definitely be
recommended even with VM, and 1M machines won't work with linux even
with the VM (you /do/ need some real memory too :-).

I have this small question when it comes to the swap-space setup - two
different possibilities:

1 - a swap-device of it's own (ie own partition)

2 - file-system swap-area.

There are a number of pros and cons: (1) is faster, easier to implement,
and will need no changes when the filesystem eventually is changed to
accept >64M etc.  (2) has the good side that it means that it would be
easy to change the size of the swap-area, but if something bad happens,
it could probably trash the filesystem easily.  I'll probably implement
only (1) for now, but I'd like to hear what you say (and ignore it :-). 

		Linus