Dec 122017
 
Tips and traps about LinUX the freeware UNIX clone from Internet.
File INTLX004.ZIP from The Programmer’s Corner in
Category UNIX Files
Tips and traps about LinUX the freeware UNIX clone from Internet.
File Name File Size Zip Size Zip Type
INTLX004.TXT 41409 14143 deflated

Download File INTLX004.ZIP Here

Contents of the INTLX004.TXT file



From: [email protected] (Troy E Bull)

Subject: GCC Errors
Keywords: Help
Message-ID:
Date: 1 Mar 92 22:38:12 GMT
Sender: [email protected] (USENET News System)
Organization: Iowa State University, Ames IA
Lines: 14

I am having some troubles getting gcc installed. What is happening is,
I get errors like

stderr : trying to print from inside text segment, symbol not defined.

I would appreciate it is anyone knows what causes this and how I can fix
it.

Thanks in advance.

--
Does a machine that imitates human beings perform any useful service at all?
(We are not running short of human beings.)
-Bolter on Turing about AI


[next article]
From: [email protected] (Mark William Hopkins)

Subject: Elvis bug (was: Re: Killing init, shutdown, reaping zombies, anoying kernel messages)
Message-ID: <[email protected]>
Date: 1 Mar 92 23:15:21 GMT
References: <[email protected]>
Sender: [email protected] (USENET News System)
Organization: Computing Services Division, University of Wisconsin - Milwaukee
Lines: 27

In article <[email protected]> [email protected] (Drew Eckha rdt) writes:
>Shutdown :
>If you accidentally leave elvis running on a file, in another window,
>you end up with a permanantly busy file if you reset. A shutdown
>command / syscall which killed everything else off would be nice.

That's an Elvis bug, not a kernel bug. My reading of the Elvis source and
documentation is that Elvis uses only one temporary file (one temporary file
for EVERYTHING!). You can't really even edit two files at once (say, if you
have job control), as far as I can determine.

I think the author put a recover option in the latest version of elvis. That
can be used to bring the temporary file back into elvis. Otherwise, you can do
what I've always done: delete the temporary.

Even the UNIX vi runs into similar problems. On frequent occasions, due to the
limited number of possible names for temporary files, there will be a name clash
and vi won't start up. This is about a 1% frequency on this machine.

Why I don't like elvis: the screen-handling is abominable, and the temporary
file-handling thrashes and sometime even crashes the machine (on a DOS).
Usually, I just stick with a version of vi that memory-maps the buffer. More
generally, the editor really has no business messing with temporaries: that's
the OS's job. Let the editor do everything in memory only, and let the OS deal
with the swapping.

But the source is nice to look at (for educational purposes)!


[next article]
From: [email protected] (Mark William Hopkins)

Subject: Running linux in < 500kB
Message-ID: <[email protected]>
Date: 1 Mar 92 23:27:12 GMT
References: <[email protected]> <[email protected]>
Sender: [email protected] (USENET News System)
Organization: Computing Services Division, University of Wisconsin - Milwaukee
Lines: 10


If someone's got the time and inclination, please modify the kernel so that
it can run in < 500kB RAM. No UNIX has any business using more than that.
Maybe better algorithms (that's what Coherent prides itself on, justifiably)
or something need to be used. If I have to go out and buy memory extensions,
then I might as well just save the trip and spend money on a Coherent or the
like.
The idea of free public domain software is to get something that can run on
most machines without having to spend any money. Far too many machines are
being excluded by the 2MB limitation.


[next article]
From: [email protected] (Ron Pool)

Subject: Pcomm 1.2 ported to Linux
Message-ID:
Date: 1 Mar 92 19:37:37 GMT
Sender: [email protected]
Organization: Cornell University
Lines: 63
Nntp-Filt-2: Fenchurch version 0.3 by Uncle Mikey for Cornell University
Nntp-Posting-Host: aruba.nysaes.cornell.edu
Nntp-Auth: trusted
Errors-To: [email protected]

I've ported Pcomm 1.2 to Linux 0.12. I've placed two compressed tar archives
on tsx-11.mit.edu. I don't know if or when the archives will be moved into
a place on tsx-11 you can download them from. Appended below is a copy of
the file Readme.linux, which can be found in both of the tar archives I've
uploaded. I can also pack up my port of rzsz if there is interest.

-- Ron Pool, [email protected]

-------- Readme.linux --------

Pcomm 1.2 for Linux
Ported to Linux 0.12 by Ron Pool, [email protected]

[for Linux 0.12; compiled with newgcc (gcc 1.40); linked with a customized
libcurses (printw.c fixed to use vsprintf) and newlibc (newlibc with vsprintf
fixed to use va_list ap as last argument instead of ... varargs style last
argument)]

The binaries, documentation, and config files for this package are in
pcomm12b.tar.Z. Full source, documentation, and config files are in
pcomm12s.tar.Z.

General notes:

Screen display is occasionaly incorrect; I think this is due to an incorrect
termcap file in the Linux 0.12 distribution. If anyone knows what's wrong
with the termcap file, let me know. I've been ignoring the minor display
problems as I usually know what should be on the screen when they occur.

I thought I was just porting Pcomm to Linux for my own use, so I didn't keep
track of the changes I made. The other thing I didn't do was make note of
where I got Pcomm from; Pcomm sources can be found using archie. The only
reason you'll need to get the original Pcomm source is to compare this source
with the original to see how I mangled it.

I'm rarely using Pcomm on my Linux system now; the latest ka9q is fast
enough for my uses. I'm fortunate to have control of a terminal server
capable of running compressed SLIP. I find it nice to be able to start
ftp'ing a directory of files to my home Linux machine and then read
Usenet news in another ka9q session.

Installing:

The precompiled version of Pcomm 1.2 expects that the binaries for Pcomm
will go in /usr/local/bin. It also expects that some configuration files
will go in /usr/local/lib/pcomm. You can change the Makefile to install
the binaries somewhere else if you want. You cannot move the configuration
files elsewhere, unless you change the definition of DEFAULT_DIR in the
Makefile and rebuild all binaries first.

1. Type
make install
to install the binaries in /usr/local/bin (or wherever you've specified
in the Makefile).

2. Type
make install_config
to install the Pcomm configuration files and a sample script in
/usr/local/lib/pcomm (or wherever you've specified in the Makefile).

3. Customize the configuration files by running pcomm and using the
setup screen. Details can be found in documents in the Doc subdirectory
of the Pcomm distribution


[next article]
From: [email protected] (Rick)

Subject: Re: SCSI support
Message-ID: <[email protected]>
Date: 2 Mar 92 00:47:20 GMT
References: <[email protected]>
Organization: Telecom Australia, TNE Computer Support Services
Lines: 3

Anybody working on support for Future Domain SCSI controllers?

Rick.


[next article]
From: [email protected] (Jim Stewart)

Subject: Re: Running linux in < 500kB
Message-ID: <[email protected]>
Date: 2 Mar 92 01:43:03 GMT
References: <[email protected]> <[email protected]> <[email protected]>
Organization: BC News and Mail
Lines: 29

In article <[email protected]> [email protected] (Mark William Hopkins) writes:
> If someone's got the time and inclination, please modify the kernel so that
>it can run in < 500kB RAM. No UNIX has any business using more than that.

...SCO, Ultrix, BSD ...?

>Maybe better algorithms (that's what Coherent prides itself on, justifiably)
>or something need to be used. If I have to go out and buy memory extensions,
>then I might as well just save the trip and spend money on a Coherent or the
>like.

By all means, Coherent is an interesting product...

> The idea of free public domain software is to get something that can run on
>most machines without having to spend any money. Far too many machines are
>being excluded by the 2MB limitation.

The idea of *free* *public domain* software is to provide solutions to
common problems in the computing community. The size of the machine reflects
the size of the problem. X11 is essentially cost free, but it needs a lot
of resources. KCL and AKCL are cost free, and won't run in less than 4 Meg.

Be careful of the term *public domain* ... Linux is not in the *public domain*,
it is owned by Linus, who has been kind enough to let the rest of us use it.

ps. If you are asking other people to spend time and inclination on a
problem, a slightly less strident tone might be called for.

js


[next article]
From: [email protected] (Jim Stewart)

Subject: Re: Various problems and some solutions
Message-ID: <[email protected]>
Date: 2 Mar 92 01:48:57 GMT
References: <[email protected]>
Organization: BC News and Mail
Lines: 53

The libc.a for gcc-1.40 contains broken versions of vsprintf, vfprintf
and vprintf. These functions must be fixed before you rebuild
Libcurses.

The problem is that all three are declared to take, and use
a *varargs* style parameter list. This is just not the case. Each
takes a fixed number of paramaters, the last of which is a va_list pointer.

Here is a context diff for vsprintf.c -- the other v*printf.c files can be fixed
in the same way.

NOTE: you will have to fix the prototype declarations in stdio.h as well

js

*** /usr/src/lib/stdio/vsprintf.c Sun Feb 2 23:02:20 1992
--- vsprintf.c Sun Mar 1 01:58:27 1992
***************
*** 31,48 ****
#include

int
! vsprintf(char *str, const char *fmt, ...)
{
- va_list ap;
FILE f;
int len;

- va_start (ap, fmt);
f._flag = _IOWRT+_IOSTRG;
f._ptr = str;
f._cnt = 32767;
len = _doprnt(fmt, ap, &f);
*f._ptr = 0;
- va_end (ap);
return (len);
}
--- 31,45 ----
#include

int
! vsprintf(char *str, const char *fmt, void * ap)
{
FILE f;
int len;

f._flag = _IOWRT+_IOSTRG;
f._ptr = str;
f._cnt = 32767;
len = _doprnt(fmt, ap, &f);
*f._ptr = 0;
return (len);
}


[next article]
From: [email protected] (Kevin Brown)

Subject: Re: Elvis bug (was: Re: Killing init, shutdown, reaping zombies, anoying kernel messages)
Message-ID: <[email protected]>
Date: 2 Mar 92 01:44:39 GMT
References: <[email protected]> <[email protected]>
Sender: [email protected]
Reply-To: [email protected] (Kevin Brown)
Organization: Minimal.
Lines: 64

In article <[email protected]> [email protected] (Mark William Hopkins) writes:
>In article <[email protected]> [email protected] (Drew Eckh ardt) writes:
>>Shutdown :
>>If you accidentally leave elvis running on a file, in another window,
>>you end up with a permanantly busy file if you reset. A shutdown
>>command / syscall which killed everything else off would be nice.
>
>That's an Elvis bug, not a kernel bug. My reading of the Elvis source and
>documentation is that Elvis uses only one temporary file (one temporary file
>for EVERYTHING!). You can't really even edit two files at once (say, if you
>have job control), as far as I can determine.

It has to do with the naming convention elvis uses for the temp file, more
than anything else. If I recall correctly, it uses the inode number of the
file being edited as part of the temp file name. You can't edit a given
file more than once at a time because the temp file will already exist on
the second try.

When the system crashes, the temp file is not removed (unless you clean up
/usr/tmp upon startup). When you go to edit the file, elvis complains that
the file is busy (because it sees the temp file).

This is on a file by file basis, however. You can edit multiple files with
elvis (just as you can with vi), both with one session and with multiple
sessions (for example, it's possible to shell out of elvis, then edit
another file with it). The *only* limitation that I've seen is that you
can't have multiple elvis sessions going at the same time on the same
file.

>I think the author put a recover option in the latest version of elvis. That
>can be used to bring the temporary file back into elvis. Otherwise, you can do
>what I've always done: delete the temporary.

I don't know about the latest version. In version 1.4 and earlier, there
existed a separate program that would recover your file from the temporary
for you. It was called "virec" or "virecover".

>Even the UNIX vi runs into similar problems. On frequent occasions, due to the
>limited number of possible names for temporary files, there will be a name clas h
>and vi won't start up. This is about a 1% frequency on this machine.

Fascinating. I've never seen this happen, but I don't doubt it.

>Why I don't like elvis: the screen-handling is abominable, and the temporary
>file-handling thrashes and sometime even crashes the machine (on a DOS).

Why would anyone even think of using DOS? ๐Ÿ˜‰

>Usually, I just stick with a version of vi that memory-maps the buffer. More
>generally, the editor really has no business messing with temporaries: that's
>the OS's job. Let the editor do everything in memory only, and let the OS deal
>with the swapping.

I don't know what the original justification for the temp file in vi was.
I suspect it was originally there to overcome the 64k data space limitations
inherent under BSD 2.1 (or something like that) on the PDP-11.

However, one of the goodies you get with a temp file is the ability to
recover your editing session if it dies for some reason (e.g., the system
goes down, or your session gets disconnected). So it's not *all* bad...



Kevin Brown ([email protected])


[next article]
From: [email protected] (S3679988)

Subject: Re: Running linux in < 500kB
Message-ID: <[email protected]>
Date: 2 Mar 92 01:27:44 GMT
References: <[email protected]> <[email protected]> <[email protected]>
Sender: [email protected] (USENET News System)
Organization: University of Massachusetts at Amherst
Lines: 46
In-Reply-To: [email protected]'s message of Sun, 1 Mar 1992 23:27:12 GMT
X-News-Reader: VMS NEWS 1.20

In <[email protected]> [email protected] writes:

> If someone's got the time and inclination, please modify the kernel so that
> it can run in < 500kB RAM. No UNIX has any business using more than that.
> Maybe better algorithms (that's what Coherent prides itself on, justifiably)
> or something need to be used. If I have to go out and buy memory extensions,
> then I might as well just save the trip and spend money on a Coherent or the
> like.

This would be nice, but, IMHO, the amount of time spend using virtual memory
would be almost absurd, its bad enough in 2MB.


> The idea of free public domain software is to get something that can run on
> most machines without having to spend any money. Far too many machines are
> being excluded by the 2MB limitation.

Please don't take this as a flame, i don't intend on it being that.
I feel that if we restrain the operating system form being able to take
advantage of some of the newer technologies that have come about over
the last few years (of note, the i386, and cheaper RAM).

I personally like hearing that the 8088, and 286 are finally being
acknowledged as being 'obsolete' -- IBM and Microsoft are making
their own operating systems, NT, and OS/2 -- which i am *sure*
will require more than 512K.

I feel that the time that would be spend hacking linux down to being
able to run in 512K would be better spend making it run X11,
distributed processing, or maybe do something we all haven't though
of. If we make it run in 512K, why not make it run on an 8088?
After all, countless amounts of those have been sold. Even if the kernel
were to run in 512K, what would you be able to use it for? emacs
loves memory, and gcc chews it like popcorn. In fact, windows doesn't
like 512K all that much. In then end, you would probably end up
upgrading your RAM (if not your cpu, also).

I agree with your point about using more efficient algorithms, but,
Linux is currenlt 0.12, and _anything_ at 0.12 that works is pretty
impressive (give yourself a pat, linus!). I would hope that by 1.0,
things start to settle down, and people start debating about which
algorithm should be used, as opposed to "[email protected]#$ !! we need ??'s to
run X-cows".


Craig Hagan


[next article]
From: [email protected] (Drew Eckhardt)

Subject: SCSI drivers : revisited
Summary: First known bug fixed.
Message-ID: <[email protected]>
Date: 2 Mar 92 03:03:50 GMT
Sender: [email protected] (The Daily Planet)
Organization: University of Colorado at Boulder
Lines: 33
Nntp-Posting-Host: kinglear.cs.colorado.edu

When compiling the SCSI drivers, I got them working, copied files to and from
my SCSI partition, did binary and text diffs that worked fine - with
information out of buffer cache and really coming off of disk.

Not long after, I noticed that I could binary diff things fine, but that
a more didn't work, and later I discovered tail would EINVAL. Off of disk
or buffer cache.

Turns out
I had overlooked a single macro (IS_SEEKABLE()) in fs.h. The net result was
my SCSI disk was being treated as a sequential device. I went back, fixed that,
bumped the SD major number up to eight to make way for unnamed pipes,
ST number up to 9, and all works perfectly (on my system - one other user
gets the INQUIRY command through safely and then crashes on a
READ CAPACITY with extended sense of ILLEGAL REQUEST) -


The new binary has been uploaded to nic.funet.fi and tsx-11.mit.edu,
under bootimage.seagate.tar.1.Z, source scsi.shar.1.Z and docs user.docs.1.Z .

Note that this still tries to mount root of of /dev/hd1 - you'll want to
change that and avoid the fatal kernel panic if you are a SCSI-only
system.

Like I said, it works on my system perfectly, and I need other seagate
ST0x SCSI owners to try it out, try and crash it, and get it working
on everyone's systems.

Also, I need signatures for BIOS revision !=
2.00 - ie the first ASCII string that shows up in the ROM, and the offset
from the begining of the ROM, so the whole thing can be 100% self configuring,
letting us send out a single distribution kernel for everyone, adaptec,
dtc, seagate SCSI, normal IDE or MFM.


[next article]
From: [email protected] (Linus Benedict Torvalds)

Subject: Re: Linux 0.13?
Message-ID: <[email protected]>
Date: 2 Mar 92 01:31:47 GMT
References: <[email protected]>
Organization: University of Helsinki
Lines: 101

In article <[email protected]> [email protected] (Derron Simon) writes:
>When is version 0.13 scheduled to be released? I don't want to hassle with
>all the patches and updates to 0.12 so I'd like to wait until 0.13 if it is
>not going to be long from now.

I'm putting in the finishing touches this week: 0.13 should be out next
weekend at the latest (unless some new bug shows up), and I hope to get
it ready by Thursday. I'll definitely call it 0.95, making clear that
version 1.0 isn't that far away.

0.95 will have these features:

- faster floppy (based on cdiffs by entropy (Lawrence Foard), but I
didn't patch in the formatting code). Untaring from a floppy is no
longer a pain.

- VFS-stubs (based on cdiffs by proven (Chris Provenzo), but again my
version does not contain all of his code, and I added some changes of
my own too.)

- Better VC handling (works on other cards that EGA/VGA), thanks to
pmacdona (Peter McDonald). I think 0.13 finally contains most of the
VC code things: screen blanking, corrected vt100-codes etc.

- Swapon system call (swapping from files as well as block devices),
based on patches by Simmule Turner. This one needs some additional
work still.

- poe-IGL-1.2 (or close to it).

- ptrace (by Ross Biro) - not guaranteed, but I think we'll get gdb
working in 0.95.

- bugfixes and minor enhancements: file protections, nonblocking IO,
UK and Danish keyboards, rename etc.

Most of the patches have been heavily edited by me (indeed, very few of
them are patched in automatically with 'patch'), and not all of the
functionality of all the patches will be there. I've mostly written in
the patches by hand, so the author of the code will not necessarily even
recognize his own work. As with the VC patches, some of these patches
will probably evolve for a few releases before they get their final form
(especially VFS which was easily the biggest patch to date).


Changes that haven't been seen as patches that will be in 0.95:

- many minor corrections (rename corrected, ^S/^Q corrected, better (?)
buffer-cache handling, some corrected error-returns).

- lockup bugs (two of them) removed: I hope that was the last of them
(yeah, sure..).

- minor race-conditions with swapping removed (still not 100%, but
better, and I hope the "block already free'd" error should go away)

- TIOCxWINSZ works now.

- Harddisk changes: the second harddisk will be on minor numbers 64-127
instead of 5-9 as now. I also have some code there that hopefully
gets extended partitions right, but as I haven't been able to test it
I somehow doubt it works 100% ... The default harddisk names have
changed: here's a simple listing

new minor old minor

hda 0 hd0 0
hda1 1 hd1 1
hda2 2 hd2 2
hda3 3 hd3 3
hda4 4 hd4 4
hda5 5 (extended) - -
hdaX X -- "" -- - -

hdb 64 hd5 5
hdb1 65 hd6 6
etc

I'm guessing this will get some people confused, but the old naming
and numbering conventions were so bad as to be pretty unusable with
extended partitions. Fdisk currently doesn't understand extended
partitions: I'll try to get that corrected too.

Patches available now, but NOT in 0.95:

- printer port patch. I still haven't gotten around to this one, as I
haven't got a printer. So sue me.

- SCSI driver: didn't make it in time. I don't expect too many problems
applying the 0.12-patch to 0.95.

- mmap patch: not in time, and so specialized I felt there wasn't that
much of a hurry. Again, this patch should probably patch into 0.95
without undue problems.

So: I hope 0.13 should prove to be more stable, and more easily
extensible, but it will look mostly like 0.12 with a init/login. No
/major/ new features like in eariler releases: I hope that means linux
is getting more mature rather than stagnating ๐Ÿ™‚

Linus


[next article]
From: [email protected] (Lawrence C. Foard)
Newsgroups: alt.hackers,comp.os.misc,alt.os.linux

Subject: tubes for linux
Message-ID: <[email protected]>
Date: 2 Mar 92 06:52:03 GMT
Sender: [email protected] (News)
Organization: Worcester Polytechnic Institute
Lines: 52
Nntp-Posting-Host: wintermute.wpi.edu

I noticed the post about the faucet and drain commands and thought I would
post about the recent hacking I've been doing. I just added two new features
to linux (the worlds only real free OS).

I've always been annoyed by the recent trend toward having seperate name
spaces and commands for everything. So I decided to write IPC (tubes) so
that it you could write multiconnection demons using shell scripts.

For example:

tpair /tmp/end1 /tmp/end2
cat /tmp/end1 &
ls -al >/tmp/end2
#shows the output of ls
#the following also works
cat /tmp/end1 &
cat /tmp/end1 &
ls -al >/tmp/end2
ps >/tmp/end2
#unlike named pipes it creates a new connection when ever an open has
#been done on both sides.

I'm planning to do the same for TCP/IP but with a pseudo directory.
tar -cf - * >/dirs/inet/$/32.45.23.34/2000
#send output of tar to port 2000 on machine 32.45.23.34

and on the remote machine
tar -xf - #untar the next connection to local port 2000

One other neat command, you can "pin" a file handle to a file name, the
program opening that file has the file handle given to them.

tar -cf - * | pinin /tmp/here
tar -xf - or for an even weirder effect
(stty sane cs8 9600;pinout /tmp/here) >/dev/tty65
then
ls -al >/tmp/here
sends the ls out the terminal with sane,cs8 and 9600 set.

Ob hot food discussion:
One more vote for hackers liking hot food, I frequently need to ask for
extra hot oil on the side after asking for the food extra hot. This usually
gets a rather frightened look from the waiter/waitress. Who says those hot
peppers are just for seasoning munch munch munch ๐Ÿ™‚

--
Disclaimer: Opinions are based on logic rather than biblical "fact". ------
This is a mutated signature virus, if you don't put it in your .sig \ /
file you may lose your job, your dog may be run over, and you may die. \ /
If you repent and add the .sig you may win the lottery and get laid. \/


[next article]
From: [email protected] (D.Bolla)

Subject: Re: Various problems and some solutions
Message-ID: <[email protected]>
Date: 2 Mar 92 08:40:32 GMT
References: <[email protected]>
Reply-To: [email protected] (D.Bolla)
Organization: Computing Lab, University of Kent at Canterbury, UK.
Lines: 38

In article <[email protected]> [email protected] wr ites:
>Today I've applyed different patches on the kernel and features which arise in
>various problem
Nice fun to apply patches ๐Ÿ™‚
Anyway, the usual rule is :
Apply ONE patch at a time. Test the system as much as you can.
SAVE the current status. Go on with another patch....

>1) my env is:
>386Sx 4Mo VC, gcc-1.4, gnuemacs, uemacs, swapon and a 2Megs swap-file
>2) the patches and features I try to add
>mmap, dev/kmem, Peter init-1.2
Got mmap but I haven't added yet. BTW Is Linux going to include mmap
in the next release ?
I have init-1.2 and it seems to work ok..

>b) after dev/kmem of Diamano
>gnuemacs cannot anymore save files the error message is
>IO error writing : bad file nr
>[the only change i made was the -NR-reboot value]
My patch vas two bits. One was the reboot call and one was the access to
/dev/kmem. They are two distinct things and as I wrote in the article
you should try to understand what's going on while applyng them.

>Finally I've seen in a recent news someone try to mkfs a swap
>partition (or have I misread). A mkswap will cure the "cannot find
>swap signature"
What you need is to:
1) Create a partition for the swap using any tool you like.
2) Find what is the device of the partition using Linux fdisk
3) Use linux mkswap -c /dev/hdxx Block_num
where the block_num come from fdisk
4) In the kernel makefile set the right major and minor of the swap
partition
NOTE: You may have to CREATE (using mknod) the HD devices you need


Damiano


[next article]
From: [email protected] (D.Bolla)

Subject: Re: Running linux in < 500kB
Message-ID: <[email protected]>
Date: 2 Mar 92 08:47:22 GMT
References: <[email protected]> <[email protected]> <[email protected]>
Reply-To: [email protected] (D.Bolla)
Organization: Computing Lab, University of Kent at Canterbury, UK.
Lines: 20

In article <[email protected]> [email protected] (Mark William Hopkins) writes:

> If someone's got the time and inclination, please modify the kernel so that
>it can run in < 500kB RAM. No UNIX has any business using more than that.
Considering the price of ram I suggest you buy more ram instead of
Coherent. You can use the ram for DOS too ๐Ÿ™‚

>Maybe better algorithms (that's what Coherent prides itself on, justifiably)
>or something need to be used. If I have to go out and buy memory extensions,
>then I might as well just save the trip and spend money on a Coherent or the
>like.
Well... Yes old UNIX was running on 64k ram. Today you want more...

> The idea of free public domain software is to get something that can run on
>most machines without having to spend any money. Far too many machines are
>being excluded by the 2MB limitation.
I still think that 2MB is a fair number considered the price of ram today !
BTW: How much does Coherent cost ?

Damiano


[next article]
From: [email protected] (Steven Wilson)

Subject: Re: pcomm: has anyone ported it?
Summary: Pcomm port
Message-ID: <5_shz6#[email protected]>
Date: 2 Mar 92 15:36:06 GMT
References: <[email protected]>
Organization: Netcom - Online Communication Services (408 241-9760 guest)
Lines: 15

In article <[email protected]>, [email protected] ( Charles Carlson) writes:
> I'm wanting to get Pcomm working with Linux..
> Has anyone managed it?
>
> Charles
>

I'm working on it and have made some progress but it's a slow battle
cuz I'm fighting with curses as well as Pcomm. (There are some
subtle problems on both sides and I'm new to curses so....) Further,
I grapped the original release of PCOMM instead of a more recent
version... the code is that much simpler! If I get anything going
the even looks half stable I'll be sure to post it!

Steve Wilson


[next article]
From: [email protected] (Theodore Ts'o)

Subject: Re: Pcomm 1.2 ported to Linux
Message-ID: <[email protected]>
Date: 2 Mar 92 16:18:31 GMT
Sender: [email protected] (Mr Background)
Reply-To: [email protected]
Organization: The Internet
Lines: 26


From: [email protected] (Ron Pool)
Date: 1 Mar 92 19:37:37 GMT

I've ported Pcomm 1.2 to Linux 0.12. I've placed two compressed tar
archives on tsx-11.mit.edu. I don't know if or when the archives
will be moved into a place on tsx-11 you can download them from.

~ftp/pub/linux/{sources,binaries}/usr.bin/pcomm12.tar.Z


From: [email protected] (Drew Eckhardt)
Date: 2 Mar 92 03:03:50 GMT

The new binary has been uploaded to nic.funet.fi and tsx-11.mit.edu,
under bootimage.seagate.tar.1.Z, source scsi.shar.1.Z and docs
user.docs.1.Z.

The new versions of the files are now in ~ftp/pub/linux/SCSI on
TSX-11.MIT.EDU.

- Ted

P.S. Thanks for sending mail after dropping something in ~ftp/incoming;
it makes it much easier for me to figure out what something is, and
where it should go!



[next article]
From: [email protected] (Paul Richards)

Subject: tr
Message-ID: <[email protected]>
Date: 2 Mar 92 15:27:03 GMT
Sender: [email protected] (Network News System)
Organization: University of Wales College at Cardiff
Lines: 24
X-Mailer: Cardiff Computing Maths PP Mail Open News Gateway

Is there a version of tr around somewhere. There are a couple of
packages that use it during installation e.g. patch. Although I could
get by without it I'd really like to get the patch Configure shell to
work just to satisfy myself that linux really is fully equipped, so to
speak. SYSV also needs expr and echo routines in bin. I've just found a
expr prgram so I'll have a look at it. Have these little details been
done by someone else. We might as well tackle a few of the little tasks
while we're waiting for the big jobs to be finished.

Also, is the Berkeley VI in the public domain. Elvis is driving me mad.
Does anyone else have the habit of typing :0 to get to the top of the

file, I have and it doesn't work in elvis ๐Ÿ™

One last point, I remember some discusion about uncompress crashing on
corrupted files. Well, it just happened to me. If the file is corrupted
in some way then compress just hangs, taking the rest of the system down
with it. Is this being fixed, it should recognise corrupted files
shouldn't it!
--
Paul Richards at Cardiff university, UK.

[email protected] Internet: spedpr%[email protected]
UUCP: [email protected] or ...!uunet!mcsun!ukc!cf!thor!spedpr
+++


[next article]
From: [email protected] (Troy E Bull)

Subject: emacs
Keywords: help
Message-ID:
Date: 2 Mar 92 17:24:35 GMT
Sender: [email protected] (USENET News System)
Organization: Iowa State University, Ames IA
Lines: 9


Does anyone have a way to get the arrow keys to work in the non - micro
emacs version. The version I got is from tsx-11.mit.edu, and my arrow
keys don't work and I couldn't find a command to redefine them. Anyone
had any more luck????
--
Does a machine that imitates human beings perform any useful service at all?
(We are not running short of human beings.)
-Bolter on Turing about AI


[next article]
From: [email protected] (Rick Kelly)

Subject: Re: Running linux in < 500kB
Message-ID: <[email protected]>
Date: 2 Mar 92 16:47:55 GMT
References: <[email protected]> <[email protected]> <[email protected]> <[email protected]>
Reply-To: [email protected] (Rick Kelly)
Organization: The Man With Ten Cats
Lines: 54

In article <[email protected].edu> [email protected] (S 3679988) writes:
>In <[email protected]> [email protected] writes:

>> If someone's got the time and inclination, please modify the kernel so tha t
>> it can run in < 500kB RAM. No UNIX has any business using more than that.
>> Maybe better algorithms (that's what Coherent prides itself on, justifiably)
>> or something need to be used. If I have to go out and buy memory extensions,
>> then I might as well just save the trip and spend money on a Coherent or the
>> like.

>This would be nice, but, IMHO, the amount of time spend using virtual memory
>would be almost absurd, its bad enough in 2MB.

>> The idea of free public domain software is to get something that can run o n
>> most machines without having to spend any money. Far too many machines are
>> being excluded by the 2MB limitation.

>Please don't take this as a flame, i don't intend on it being that.
>I feel that if we restrain the operating system form being able to take
>advantage of some of the newer technologies that have come about over
>the last few years (of note, the i386, and cheaper RAM).

>I personally like hearing that the 8088, and 286 are finally being
>acknowledged as being 'obsolete' -- IBM and Microsoft are making
>their own operating systems, NT, and OS/2 -- which i am *sure*
>will require more than 512K.

>I feel that the time that would be spend hacking linux down to being
>able to run in 512K would be better spend making it run X11,
>distributed processing, or maybe do something we all haven't though
>of. If we make it run in 512K, why not make it run on an 8088?
>After all, countless amounts of those have been sold. Even if the kernel
>were to run in 512K, what would you be able to use it for? emacs
>loves memory, and gcc chews it like popcorn. In fact, windows doesn't
>like 512K all that much. In then end, you would probably end up
>upgrading your RAM (if not your cpu, also).

>I agree with your point about using more efficient algorithms, but,
>Linux is currenlt 0.12, and _anything_ at 0.12 that works is pretty
>impressive (give yourself a pat, linus!). I would hope that by 1.0,
>things start to settle down, and people start debating about which
>algorithm should be used, as opposed to "[email protected]#$ !! we need ??'s to
>run X-cows".

Coherent might run on a 512k machine. The docs seem to say that you must
have at least 640k. The kernel seems to allocated about 250k of memory for
buffers and drivers. When I am expiring news and doing compiling and data
transfers simultaneously, I get up in the 3 to 3.5 meg area of memory usage.
I guees a 512k machine could be used if swapping was enabled, but it would
be like watching paint dry.

--

Rick Kelly [email protected] unixland!rmkhome!rmk [email protected]


[next article]
From: [email protected] (Kevin Cummings)

Subject: Re: Easy video mode changes, nonstandard disk support, and v86 mode
Message-ID: <[email protected]>
Date: 2 Mar 92 18:20:58 GMT
References: <[email protected]>
Sender: [email protected] (Kevin Cummings)
Organization: Prime Computer R&D
Lines: 68

OK, time for me to get into this one, sorry folks ...

In article , [email protected] (Ian We lls) writes:
> In article <[email protected]> [email protected] (Joel M. Hoff man) writes:
>
> [ ... comments about nice DOS programs ... ]
>
> WordPerfect and Quicken come immediately to mind. While I don't
> actually use WP and more, I know many people that do, and I'd like to be
> able to use Linux without giving up such nice DOS programs. Most
> programs still run under a simple 8086. I also have several games for
> DOS that I simply cannot port to Linux. (Scrabble, Chess, etc.)
>
> Yes, so use DOS for them. It would make Linux unnecessariy complicated to
> add DOS. It's developing as a nice operating system in its own right, forcing
> support for another OS onto it is taking a step backward. If you want a good
> WP, game, etc. write your own for Linux or keep DOS on your disk.

I would like to use DOS for them. But I have a problem, I would like to run DOS
as a VC under LINUX. In that way, I could be doing a file transfer, or other us eful
work under LINUX at the same time! Don't tell me that its too hard to do! I ha ve
a SUN386i workstation at work, and even though it doesn't support graphics appli cations
(unless its a CGA application under SUN-View windows), it DOES support DOS utili ties
that run entirely in text mode! It can be done. We don't have to make every pr ogram
which writes to the E/VGA hardware work! This along with the mtools package wou ld
be a VERY complete intergration of DOS and LINUX. Under a VC, it should be suff icient
for most DOS text mode packages to work fine. I do NOT want to have to reboot
DOS and stop any other LINUX tasks that I might have going on, especially if I'm
running KA9Q in another process, or after SL/IP support is added to the LINUX
kernal!

I don't want to run DOS for the GAMES, I want to run DOS for the commercial
programs that just aren't or won't be ported to LINUX!

> >
> >Do you want DOS to hang in the middle of you wordprocessor ?
> >I don't
> >
>

> If the DOS emulator dies it's not nearly to critical as if the OS
> dies. Under Linux, everything else will keep running. Not SO bad....
>
> -Joel
>
> One point about this is that if DOS trickery has to be coded into the MM then
> it's a lot more likely to hang Linux at the same time. It's also a lot more
> likely that Linux will hang given the amount of bugs adding such code would
> produce.

DOS trickery shouldn't have to be coded into the MM. However, if DOS tasks
should need something special added, that should not be a reason not to do it.
espicially if its a simple thing to do! (I don't know, would it be a simple
change?) I don;t wish to force instability in the kernal, but I also
don't like some of the anti-DOS attitudes being aired around here here
lately. It IS possible for DOS to run nicely under UNIX, SUN proved it!

=================================================================
Kevin J. Cummings Prime Computer Inc.
20 Briarwood Road 500 Old Connecticut Path
Framingham, Mass. Framingham, Mass.

InterNet: [email protected]
UUCP: uunet!primerd.Prime.COM!cummings

Std. Disclaimer: "Mr. McKittrick, after careful consideration,
I've come to the conclusion that your new
defense system SUCKS..." -- War Games
=================================================================



 December 12, 2017  Add comments

Leave a Reply