Subject: Linux-Development Digest #870
From: Digestifier <Linux-Development-Request@senator-bedfellow.MIT.EDU>
To: Linux-Development@senator-bedfellow.MIT.EDU
Reply-To: Linux-Development@senator-bedfellow.MIT.EDU
Date:     Wed, 29 Jun 94 18:13:07 EDT

Linux-Development Digest #870, Volume #1         Wed, 29 Jun 94 18:13:07 EDT

Contents:
  Re: Disk-compression for (Brett Coon)
  Re: I've found a bug in tcsh (Stuart Cunningham)
  Re: Floppy code broken w. 1.1.23 [FIXED] (Dennis Henriksen)
  Re: Quirky idea: Remote Virtual Consoles (James B. MacLean)
  Re: Dedicated SCSI swap drive? (Brandon S. Allbery)
  tcsh bug: more information (Stuart Cunningham)
  Re: 1.1.23 floppy driver broken on my notebook (Klaus Schneider)
  Re: Disk-compression for (Jim Graham)
  Re: Quirky idea: Remote Virtual Consoles (Michael P. Lepore)
  NetBEUI (Rogon the Fateless)
  Re: computer science (Frank Lofaro)
  Re: problems with 386SX (Wolfgang Koehler)
  No autoirq to depca under 1.1.23 (Thomas Roehl)
  Re: Kenrel hacking tips (Miguel de Icaza)

----------------------------------------------------------------------------

From: brett@iit.com (Brett Coon)
Subject: Re: Disk-compression for
Date: Mon, 27 Jun 1994 23:37:34 GMT

hoeij@sci.kun.nl (Mark van Hoeij) writes:

>In <1.9600.2382.0N27D133@dscmail.com> john.will@dscmail.com (John Will) writes:

>Brett> Compressed file systems are not inherently unreliable.  By its very
>Brett> nature, compression eliminates redundancy, which makes it harder to
>Brett> recover from disk errors.  However, a well-designed system with error
>Brett> control built-in could be more reliable than an uncompressed system.

>>HUH?  While I disagree that compression automatically makes a file system
>>unreliable, I have even more trouble with your statement that it could
>>somehow make a filesystem more reliable!  You want to try to expand on
>>that idea, it sure seems foreign to me!

>A compressed file can be checked if it has errors because of the included
>CRC check. An uncompressed file can not be checked for correctness, so in
>this way the compressed file is more reliable.

Actually, there's more to it than that.  Your ability to recover from
disk errors is based on the amount of redundancy in the data.  For
example, if a linked list has both forward and backward pointers, you
can always search the list in one direction and recreate all the
pointers in the opposite direction.  Uncompressed filesystems typically
have a lot of this type of redundancy, but it is very uneven.  Some
information is effectively recorded multiple times, but other data
(such as the actual contents of your files) is not.  By adding explicit
error correction data, you can provide whatever levels of redundancy
you want, at the cost of the addition error correction data and
processing time.  Compressing first and then adding error correction
fields will typically result in smaller files than before compression,
with more uniform redundancy to allow _any_ corrupted data to be
recovered, within the bounds of the type of error correction chosen.

Of course, as someone else pointed out, adding compression to a
filesystem increases its complexity, and thus the likelihood of
problems.  This too can be compensated for with additional error
correction, but at some point the error correction data takes more
space than you gain from compression, leaving you with a filesystem
whose only benefit is greater reliability (at the cost of more
computation for file accesses).  Maybe promoting such a filesystem
on this reliability aspect alone would make it more appealing...

-Brett

--
+------------------------------------------------------------+
| Brett Coon  -  brett@iit.com or brettc@leland.stanford.edu |
| Integrated Information Technology Inc. (408) 727-1885 x367 |
+------> finger brettc@leland.stanford.edu for PGP key <-----+

------------------------------

From: shcun1@aurora.cc.monash.edu.au (Stuart Cunningham)
Subject: Re: I've found a bug in tcsh
Date: 28 Jun 1994 00:12:53 GMT

Stuart Cunningham (shcun1@aurora.cc.monash.edu.au) wrote:
:   I have a script which makes makefiles.  It occasionally appends a
: space, backslash, newline to the makefile so dependency lists can be
: split up over many lines.  It does this by the following csh command:
:       echo ' \' >>! $Makefile

: surprisingly, when I ran this script under linux's tcsh (from the
: slackware distribution), instead of appending " \", it appended a space
: then ASCII zero.  When I changed the line to:
:       echo ' \ ' >>! $Makefile
: the result was as expected (space, backslash, space). 
:   Has anyone noticed this before? Who should be notified about fixing
: it?

:   Stuart Cunningham

------------------------------

From: duke@diku.dk (Dennis Henriksen)
Subject: Re: Floppy code broken w. 1.1.23 [FIXED]
Date: Wed, 29 Jun 1994 11:21:01 GMT

The problem was of temporary character. It is gone with 1.1.24

DH

------------------------------

From: jmaclean@fox.nstn.ns.ca (James B. MacLean)
Subject: Re: Quirky idea: Remote Virtual Consoles
Date: 27 Jun 1994 21:15:52 -0300

In article <2umq0k$37u@Venus.mcs.com> les@MCS.COM (Leslie Mikesell) writes:
>From: les@MCS.COM (Leslie Mikesell)
>Subject: Re: Quirky idea: Remote Virtual Consoles
>Date: 27 Jun 1994 10:08:04 -0500

>In article <2umk5f$fu9@blackbird.db.erau.edu>,
>Andrew Anderson <andersoa@news.db.erau.edu> wrote:

>>: >I meant for it to support multiple VC's. In fact if it worked properly
>>: >it would look and act exactly like the Linux console.
>>
>>: A suggestion to prevent re-writing the wheel... 
>>: grab any of the avialable Telnet packages available for DOS.
>>
>>Yeah, but you don't get the Alt key and most function keys...
>>
>>Although I think the NCSA does distribute the source code, so this
>>might be a skeleton to start with...I might start looking into this,
>>because this would make DOSEMU more telnet-friendly, with colors
>>and such. 

>Better yet: start with MS-kermit and write a scan-code keyboard driver
>for it.  Then we'll have something that works the same via dial-up
>or network links.  Kermit already does multi-session network connections,
>but you might run into copywrite problems distributing a modified version.

>If someone is fiddling with kermit or one of the telnet programs, I'd
>like to see the ability added to handle pass-through connections to
>the serial/parallel ports at the same time the terminal emulation is
>running.  That is, make them look like HP's jetdirect port 9100
>connections.  Then you can set an old PC near some remote printers and
>use it both as a remote terminal to control the spooler and as the
>network interface to drive the printers.

>Les Mikesell
>  les@mcs.com

Interesting to listen in on this thread as it reminds me of an IRC session 
that the DOSEMU team had not so long ago. It included all the above wishes 
plus grpahics and remote mouse support, plus plus...

For my 2 cents and to take from the teams' discussion, we are dreaming of 
creating such an open client/server based product where different clients 
would be built for different OS's.

In the end, this totally open type of app could be boot on xn XT and run a 
graphics session from a remote Linux with mouse support, and... be open to 
sharing local peripherals with the session like drives and printers and so 
on and so on.

Of course this was based mainly on the premise of running DOS remotely, but 
as an open interface could connect to anything :-). 

Sure a few will retort with things like use X... but X is not freely 
available for PC's(DOS based), especially small ones:-). Some will say get 
pc-anywhere or the likes, but again, this is to be totally open from every 
angle. Others have suggested SCREEN, KERMIT, TELNET and the likes, but as 
already shown, the emulation is not complete, especially with regards to 
being ready for remote mice, and strong graphics.

At this time it's still just a dream, but so was having a free UNIX like OS 
to run power hungary apps on until Linus et al made it happen :-)

Later,
JES
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
James B. MacLean                    jmaclean@fox.nstn.ns.ca
Department of Education
Nova Scotia, Canada (902) 424-8438

------------------------------

From: bsa@kf8nh.wariat.org (Brandon S. Allbery)
Subject: Re: Dedicated SCSI swap drive?
Date: Wed, 29 Jun 1994 11:14:34 GMT

In article <davem.772866490@extro>, davem@extro.ucc.su.OZ.AU (David Monro) says:
+---------------
| komarimf@craft.camp.clarkson.edu (Mark 'Enry' Komarinski) writes:
| >Would I get better performance getting an additional 40-50MB SCSI
| >drive and use that as swap space, or just make a 32MB partition out 
| >of the 1G drive?
| 
| even though the small drive is rather slower. Even two drives on the
| same controller card (meaning only one is active at a time) is better
| than only one drive, since the heads don't have to seek all over the
+------------->8

SCSI, unlike IDE, can have commands active for multiple drives simultaneously.
I don't advise an ST01/ST02 controller, though, if you want to take full
advantage of SCSI.  (The Adaptec 154x controllers are fine.)

++Brandon
-- 
Brandon S. Allbery         kf8nh@44.70.4.88               bsa@kf8nh.wariat.org
Friends don't let friends load Windows NT (tnx Sun)    A Linux iBCS2 developer
  The Witness (the Universe's biggest practical joker) is at it again... who
  else would pit the U.S. soccer team against Brazil on the Fourth of July?!

------------------------------

From: shcun1@aurora.cc.monash.edu.au (Stuart Cunningham)
Subject: tcsh bug: more information
Date: 28 Jun 1994 00:21:07 GMT

  I've now realised that there is an important difference between csh
and tcsh from the point of view of someone who writes alot of scripts.
Under csh the single quote chracter ' quotes all characters, including
the backslash \, (except for ! which must be escaped with a \).  Under
tcsh the single quote does not quote the backslash - an important
difference when you have many scripts written for the csh which won't
run under the tcsh. I thought the tcsh was designed to support all csh
scripts.
  Anyway, putting the difference between csh and tcsh aside, I still say
there is a bug in tcsh. I believe that it should not be possible to put
an ASCII zero (the character 0x00) in a file by the following echo
command:
 echo '\' > test

(under csh this puts a single quote in the file)
under tcsh I would expect a Unmatched ' error, but no error is reported
and the 0x00 character in put in the file.  This needs to be fixed!

  Stuart Cunningham

------------------------------

From: uk0q@rzstud1.rz.uni-karlsruhe.de (Klaus Schneider)
Subject: Re: 1.1.23 floppy driver broken on my notebook
Date: 29 Jun 1994 12:45:33 GMT

Bill Broadhurst (bbroad@netcom.com) wrote:
: In article <2upls4$sgs@nz12.rz.uni-karlsruhe.de>,
: Klaus Schneider <uk0q@rzstud1.rz.uni-karlsruhe.de> wrote:
: >Andrew Gallatin (gallatin@duke.edu) wrote:
: >: I just built & installed 1.1.23 and noticed that the floppy driver is
: >: broken.
: >
: >Although I have different symptoms than Andrew mentioned, it seems the
: >floppy driver is broken in 1.1.23 for me, too.

: First patch to 1.1.24 and see if it fixes your problem.

Upgrading to kernel 1.1.24 definitely fixed the problem for me.  Thanks!

Klaus
===============================================================================
Klaus Schneider                         Email: root@ks1i486.dialup.xlink.net
Student of Informatics                         uk0q@rzstud1.rz.uni-karlsruhe.de
University of Karlsruhe, Germany               klsc@delphi.com
===============================================================================

------------------------------

From: jim@n5ial.mythical.com (Jim Graham)
Subject: Re: Disk-compression for
Date: Tue, 28 Jun 1994 00:42:45 GMT

In article <CrunwL.30w@sci.kun.nl> hoeij@sci.kun.nl (Mark van Hoeij)
writes:

>A compressed file can be checked if it has errors because of the included
>CRC check. An uncompressed file can not be checked for correctness, so in
>this way the compressed file is more reliable.

Stop...hold on a minute!  Data compression and error control are two
entirely different beasts....  Data compression basically requires error
control (you'd be crazy not to use some type of error control), but the
reverse is *NOT* true.

I'm going to switch gears into data communications mode, primarily because
that's my field, but what I'm about to type can be applied equally to the
use of a compressed and/or error controlled filesystem under UNIX.

Think about ITU-T Recommendations V.42 and V.42bis.  V.42 is a standard
(well, actually it's a recommendation...but we treat it like a standard
in virtually every respect except for the name) for error control in
modems.  V.42bis is a standard for data compression, and is currently
only standardized for operation on top of V.42 (in V.42's primary mode of
operation, LAPM, or Link Access Procedure for Modems).  There is absolutely
nothing to stop you from connecting two modems using V.42 for error control
without having any type of data compression active at all (and you could
use either its standard LAPM mode or its alternate mode, which is basically
an MNP2--4 clone).

In other words, where you say ``An uncompressed file can not be checked
for correctness,'' you should have said something along the lines of
``uncompressed filesystems are not usually checked for correctness
[errors].''  Just don't assume that because it isn't generally there, it
*CAN'T* be there.

Later,
   --jim

--
73 DE N5IAL (/4)                           < Running Linux 1.0.9 >
      jim@n5ial.mythical.com                 ICBM: 30.23N 86.32W
  ||  j.graham@ieee.org          Packet:  N5IAL@W4ZBB (Ft. Walton Beach, FL)
E-mail me for information about KAMterm (host mode for Kantronics TNCs).


------------------------------

From: leppa@garden.WPI.EDU (Michael P. Lepore)
Subject: Re: Quirky idea: Remote Virtual Consoles
Date: 29 Jun 1994 15:25:18 GMT

In article <2uq2vp$9nd@solaria.cc.gatech.edu>,
Byron A Jeff <byron@gemini.cc.gatech.edu> wrote:

>
>I don't want to telnet into the machine. I want my alt and ctl keys to act
>exactly the same way on the RVC as on a real VC. I want selection.
>
>When I sit down at the RVC it should look and act exactly the same as the
>console attached to the Linux box.
>
>NCSA telnet isn't close.
>
>Thanks for the suggestion.
>

Ok, I used to work for a company that ran SCO Xenix.  They didn't use
terminals.  They used products from different companies that were just
what you're looking for, remote consoles.  I know that some of the
brands were SunRiver, or UnTerminals.  Basically these were ACTUAL
consoles (Video Card, Monitor and Keyboard) that ran over 25-wire
lines and acted EXACTLY like a console (ie, if you had a VGA SunRiver
station, you could run V/Pix (The DOSEMU Equilivant) and run a VGA
Game, (Simcity or the like).  I've often wondered about something like
this for Linux.  The only thing would be writing the drivers, and I
don't know how difficult that would be.  You could try contacting one
of the above companies, and I can see if I can get a phone number for
you to try.

Just a sugestion.
        Mike

-- 
Things are not  |    "I refuse to engage in     | leppa@wpi.wpi.edu 
always as they  |     a battle of wits with     |      CS '97       
  appear...     |     an unarmed person..."     |


------------------------------

From: rogon@doom.tromsomh.no (Rogon the Fateless)
Subject: NetBEUI
Date: Wed, 29 Jun 1994 13:08:04 GMT

I have always wondered how Windows for Workgroups v. 3.11
works, apparently it uses some sort of protocol called 
NetBEUI for communication.  

Where can one find documentation on this? Is it free or
proprietary? Has anyone thought of making a driver of some
sort to incorporate this for Linux?

I would really like to be able to use our orginazation's
file-servers, since most of them use WfW3.11.

Is this a topic for the DosEMU and/or Wine team?

Any help is appreciated.

Roggie the Root.

------------------------------

From: ftlofaro@unlv.edu (Frank Lofaro)
Subject: Re: computer science
Date: Tue, 28 Jun 94 17:33:15 GMT

In article <2uo4v3$mni@mercury.interpath.net> ctwilson@mercury.interpath.net (Tom Wilson) writes:
>In article <cairnss.772540878@ucsu.Colorado.EDU>,
>Queenie <cairnss@ucsu.Colorado.EDU> wrote:
>> "UNIX is a trademark of AT&T."
>
>not any more....try USL
>

not any more....try X/Open

(until next week ;)


------------------------------

From: wolfgang.koehler@wu-wien.ac.at (Wolfgang Koehler)
Subject: Re: problems with 386SX
Date: 29 Jun 1994 13:37:02 GMT

In article <2up9gq$t2@email.tuwien.ac.at>, cwolf@track.cslab.tuwien.ac.at (Christian Wolf) says:
>
>       
>I am using linux and X on a 386SX with 20Mhz and 5 MB RAM for 6 months, and i have problems over problems. (not performance, but bugs). So my question is:
>
>
>Christian Wolf                                  cwolf@cslab.tuwien.ac.at
>Duernbachgasse 2
>A-3252 Petzenkirchen 

Which problems? I was using linux and X on a 16MHz SX with 5 Meg and 80MB HD (20MB swap),
and it worked fine. Perhaps you could specify your problems more precisely, as well as
the brand of the computer.

Wolfgang Koehler (wolfgang.koehler@wu-wien.ac.at)

------------------------------

From: thomas@troehl.hanse.de (Thomas Roehl)
Subject: No autoirq to depca under 1.1.23
Date: Tue, 28 Jun 1994 20:07:15 GMT

Hi,

I just compiled the 1.1.23 patch and observed the following prop.:
my depca ethernetcard is no longer recognized. At bootup the kernel
logs that it found a depca using Interrupt 6 ! That def. false.
The card uses Int. 5 !.
I think this has to do with the new floppy driver, as this uses int 6.
Even if I tell the kernel to use int 5 and not to autoprobe, the 
problem remains.

Switched back to 1.1.22 and will investigate more if this happens to
other ethernet cards too.

ciao  ,Thomas


-- 
Thomas Roehl      * thomas@troehl.hanse.de            * DATA / FAX :
Hamburg, Germany  * bbs: login "gast" no passwd       * +49 40 792 99 61
                  * nuucp: login "nuucp" pass "nuucp" * v32.bis  

------------------------------

From: miguel@sphinx.nuclecu.unam.mx (Miguel de Icaza)
Subject: Re: Kenrel hacking tips
Date: 29 Jun 1994 19:31:39 GMT

= code is SUPPOSED to do... Am looking for any tips where to find more
= information about Linux's operation; what header files to read first, what
= parts to ignore at first, etc...

Read 'The Design of the Unix Operating System', Bach, Prentice-Hall. 


------------------------------


** 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-Development-Request@NEWS-DIGESTS.MIT.EDU

You can send mail to the entire list (and comp.os.linux.development) via:

    Internet: Linux-Development@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-Development Digest
******************************
