Subject: Linux-Development Digest #864
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:     Mon, 27 Jun 94 20:13:07 EDT

Linux-Development Digest #864, Volume #1         Mon, 27 Jun 94 20:13:07 EDT

Contents:
  Re: Frustrated with new kernels (Kevin Lentin)
  Re: OpenGL implementation (sravet@bangate.compaq.com)
  Re: Quirky idea: Remote Virtual Consoles (Brian Stoler)
  Re: linux-1.1.20 breaks dosemu0.52 (Mike Heidt)
  Re: Quirky idea: Remote Virtual Consoles (David Wright)
  [Q] Partitioning 1.2G SCSI disk; AKA fdisk eats start of partition. (Kevin Greiner)
  Re: Quirky idea: Remote Virtual Consoles (Whay S. Lee)
  Re: Quirky idea: Remote Virtual Consoles (Leslie Mikesell)
  Re: bad blocks (David A. Ranch)
  Re: 1.1.18->1.1.21 new hd.c "feature" (Rob Janssen)
  Re: Disk-compression for Linux (Rob Janssen)
  Re: Disk-compression for Linux (Rob Janssen)
  Re: DOSEMU and Novell (Andrew Anderson)
  Re: Quirky idea: Remote Virtual Consoles (Byron A Jeff)

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

From: kevinl@bruce.cs.monash.edu.au (Kevin Lentin)
Subject: Re: Frustrated with new kernels
Date: 26 Jun 1994 04:14:57 GMT

David Miller (davem@eden.rutgers.edu) wrote:

>       If you join the kernel mailing list at niksula.hut.fi, Linus
> usually announces what has been added or changed in the patch he is
> putting up. He does this if he has the time, which is the main point,
> these guys are working so feverishly to code this stuff togeather that
> they have little or no time to write down every change they make.
> Also, just reading most of the posts on the kernel mailing list will
> give you a very good idea of where the changes are mainly directed in
> the latest kernel patches.

Your latter point is a good one but if you are referring to the KERNEL
channel of the Linux Activists mailing list then I have not seen an
announcement of the contents of a patch in AGES. Maybe 2 such announcements
since 1.1 development started. If that.

>       Any problem I have had with alpha kernels was fixed real quick
> because it usually was a problem for others and thus Linus released
> the next patchlevel the next day.

Yup. Recent problems I had with shells exiting when stty exitted were fixed
so quickly that I still am not sure what was wrong. Nor am I worried. Even
when there is no official patch from Linus, you'll often see the suggested
fix on the mailing list.

> p.s. try to get that kind of response from SUn/Solaris/DEC!

:-)

-- 
[==================================================================]
[ Kevin Lentin                   |___/~\__/~\___/~~~~\__/~\__/~\_| ]
[ kevinl@bruce.cs.monash.edu.au  |___/~\/~\_____/~\______/~\/~\__| ]
[ Macintrash: 'Just say NO!'     |___/~\__/~\___/~~~~\____/~~\___| ]
[==================================================================]

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

From: sravet@bangate.compaq.com
Subject: Re: OpenGL implementation
Date: Mon, 27 Jun 1994 15:03:32 GMT

In article <2u4me1$hu9@news.uni-c.dk> hwj@henrik.igk.dth.dk () writes:
>Has anyone implemented OpenGL or a subset of OpenGL for Linux/X11
>that is available on the net.
>

This was on c.o.l.a some time ago....


vogl/vogle are graphics libraries that allow GL like graphics programming
on non SGI systems. A discussion on vogl/vogle can be read in the May issue
of the german iX magazine. I have uploaded the sources (ready for linux)
into /pub/Linux/Incoming on sunsite.unc.edu. The linux software maps for
both packages are shown below.

Fred Hantelmann (w_mf@unibw-hamburg.de)

Begin
35:PkgName    = vogl.tar.gz
35:Title      = Library of C routines similar to GL (Silicon Graphics)      
25:Version    = 1.0
65:Desc1      = Designed for writing programs which can be moved to
65:Desc2      = GL capable machines. The graphics library can be called
65:Desc3      = from C or Fortran programs.
65:Author     = Eric H. Echidna
65:MaintBy    = Eric H. Echidna, IP address: 
65:MaintAt1   = eric@munnary.oz.au
65:PathFile1  =
65:MaintAt2   =
65:PathFile2  =
65:Required1  = Unix (most machines are supported), X11R5             
65:Required2  = MSDOS, MS Windows
65:Required3  =
65:CopyPolicy = 
65:Keywords   = Graphics GL X11
15:ApproxSize = 336000
65:Last3Rel   = 1.0
65:Comment1   = Adapted to run under linux.
65:Comment2   =
65:Comment3   =
30:CheckedBy  = Fred Hantelmann, Internet: w_mf@unibw-hamburg.de
 8:Date       = 22APR94
End

Begin
35:PkgName    = vogle.tar.gz
35:Title      = Library of C routines similar to GL (Silicon Graphics)      
25:Version    = 1.0
65:Desc1      = Designed for learning GL like graphics programming.
65:Desc2      = The graphics library can be called
65:Desc3      = from C, Pascal or Fortran programs.
65:Author     = Eric H. Echidna
65:MaintBy    = Eric H. Echidna, IP address: 
65:MaintAt1   = eric@munnary.oz.au
65:PathFile1  =
65:MaintAt2   =
65:PathFile2  =
65:Required1  = Unix (most machines are supported), X11R5             
65:Required2  = MSDOS, MS Windows
65:Required3  =
65:CopyPolicy = 
65:Keywords   = Graphics GL X11
15:ApproxSize = 350000
65:Last3Rel   = 1.0
65:Comment1   = Adapted to run under linux.
65:Comment2   =
65:Comment3   =
30:CheckedBy  = Fred Hantelmann, Internet: w_mf@unibw-hamburg.de
 8:Date       = 22APR94
End

--
Mail submissions for comp.os.linux.announce to: linux-announce@tc.cornell.edu
Be sure to include Keywords: and a short description of your software.



Steve Ravet     sravet@bangate.compaq.com
"Baby you're a genius when it comes to cooking up some chili sauce...."

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

From: sto2@netaxs.com (Brian Stoler)
Subject: Re: Quirky idea: Remote Virtual Consoles
Date: 27 Jun 1994 01:31:03 GMT

Byron A Jeff (byron@gemini.cc.gatech.edu) wrote:
: I've noticed that there are bunches of PC's that cannot run Linux.
: Mostly 286's and early 386's with insufficient memory.

: They don't have enough memory or horsepower to be used as remote X terminals.

: However I find that having a remote console for a Linux box an interesting
: idea.

...

: So I was thinking if it were possible to write a application that acts as
: an additional virtual console for a Linux box that I could press the low
: memory, low CPU machines I have access to into service. 

Sounds like a great idea .. but how about making it support MULTIPLE 
remote VCs on one remote PC? This would make the remote PC into another 
complete monitor/keyboard set. Now, go write it! :)


- Brian Stoler
- sto2@netaxs.com


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

From: heidt@mikey.jsc.nasa.gov (Mike Heidt)
Subject: Re: linux-1.1.20 breaks dosemu0.52
Date: 24 Jun 1994 21:01:26 GMT

I also had problems with dosemu0.52 and linux 1.0.20. Dosemu would report no
problems, then blank the screen and hang. I was using an ATI ultra 
mach 8 card. I replaced the mach 8 with an et4000 card and everything
works fine, so I conclude that the problem is in the video drvers. The
mach 8 was hanging during execution of the onboard bios. Turning graphics
off worked mostly, but no cursor. I would like to go back to the mach 8
if the problem ever gets fixed because it is faster in X windows. BTW, the
mach 8 worked fine in dosemu0.49.

        Mike Heidt
        heidt@aio.jsc.nasa.gov

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

From: dmw@prism1.prism1.com (David Wright)
Subject: Re: Quirky idea: Remote Virtual Consoles
Date: Mon, 27 Jun 1994 13:25:37 GMT

>>>>> "BAJ" == Byron A Jeff <byron@gemini.cc.gatech.edu> writes:

  BAJ> So I was thinking if it were possible to write a application that acts as
  BAJ> an additional virtual console for a Linux box that I could press the low
  BAJ> memory, low CPU machines I have access to into service. 

        How is this any different than running "screen" or similar on the Linux
side and using a normal terminal emulator? If you want graphics you could run
MS-Kermit on the 286 machines, as long as the software knows how to do
tektronix graphics (WordPerfect does). Of course, what would be neat would be
an "AlphaWindows" driver for DOS machines. I'm not sure why such a thing
doesn't exist, as it would be pretty usefull.

        It's too bad Linux can't run FacetTerm. I think it would do exactly
what you want, plus give you cut & paste, pop-up menus, etc.

                                                Dave
--
  ____________________________________________________________________________
 |        /\ /          | Prism Computer Applications        |  David Wright  |
 |      -/--\--         | 14650 Detroit Ave, Suite LL40      | dmw@Prism1.COM |
 |      /____\          | Lakewood, OH 44107  USA            |  216-228-1400  |

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

From: greiner@NeoSoft (Kevin Greiner)
Subject: [Q] Partitioning 1.2G SCSI disk; AKA fdisk eats start of partition.
Date: 26 Jun 94 02:22:01

The following is from a recent post.  A followup would have taken the subject
too far from the original topic.

>A) You must not have a primary partition extending beyond cylinder 1023
>or the start of your disk will get eaten
>B) Your kernel must fall within a partition below cylinder 1024 so that
>LILO can load it.

I've been bitten by rule (A) yet I've been unable to find any documentation
concerning it.  The SCSI howto describes rule (B) but not (A).

I have a 1.2G disk which, after I lost a 650M file system, I've partitioned 
as a 1G disk.  The partition in question is NOT my boot partition so rule (B) 
does not apply. The idea of throwing away 1/6 of my disk is unacceptable.  
Does anyone have a solution?

RTFM is fine so long as you ID the M.

For those interested, my mistake was not rerunning fdisk after rebooting with
the new partition table. 

When I created my partitions, fdisk issued a warning (logical address != 
physical address) on the partition ending at cylinder 1170.  I figured that
it would take several months to fill up the first 500M in the partition (i.e.
cylinders < 1024) so I'd have that long to resolve the problem. WRONG!
Fdisk, when it saved the partition table, moved the start of the partition
such that it overlapped the preceeding partition by 6 cylinders.  That
preceeding partition was my swap partition so I lost my file system's 
superblock when I ran low on swap space.  During recovery, fdisk's verify
command detected the invalid partition start (See why you should rerun fdisk
after the reboot).

Kevin



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

From: wslee@ai.mit.edu (Whay S. Lee)
Subject: Re: Quirky idea: Remote Virtual Consoles
Date: 27 Jun 94 16:45:14


In article <2ula4n$m0c@netaxs.com> sto2@netaxs.com (Brian Stoler) writes:
>
> Byron A Jeff (byron@gemini.cc.gatech.edu) wrote:
> : I've noticed that there are bunches of PC's that cannot run Linux.
> : Mostly 286's and early 386's with insufficient memory.
> : They don't have enough memory or horsepower to be used as remote X terminals.
> : However I find that having a remote console for a Linux box an interesting
> : idea.
> : So I was thinking if it were possible to write a application that acts as
> : an additional virtual console for a Linux box that I could press the low
> : memory, low CPU machines I have access to into service. 

> Sounds like a great idea .. but how about making it support MULTIPLE 
> remote VCs on one remote PC? This would make the remote PC into another 
> complete monitor/keyboard set. Now, go write it! :)

        Can't you already do that by:

            1. hook up the low-end machine to the linux 
               box via a serial port
            2. run "iscreen" or "pcucp"

                ?? 


[       pcucp can be found on ousrvr.oulu.fi:                   ]
[               /pub/msdos/pcucp                                ]
[       iscreen can be found on  unix.hensa.ac.uk:              ]
[               /pub/sunsite/pub/Linux/apps/comm/iscreen.tar.z  ]
[

whay.

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

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

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

From: dranch@ecst.csuchico.edu (David A. Ranch)
Subject: Re: bad blocks
Date: 27 Jun 1994 20:36:35 GMT

In article <Cruyw2.8xv@pe1chl.ampr.org>, Rob Janssen <pe1chl@rabo.nl> wrote:
>In <2uaabh$327@dockmaster.phantom.com> rpritz@phantom.com (richard) writes:
>
>>does linux test for bad disk sectors on installation or disk formating? 
>
>It depends.  You can pass the "-c" option to mkfs to have it check the
>disk for defects while it builds the filesystem.  


We had a ESDI 170MB disk that was having serious i/o errors due to bad blocks.
We had tried the '-c' option of mkfs but it didn't help.  Eventually we found
the command to clean up /dev/hda3:

        badblocks -w -o badmap.dev.hda3

Then when making the fs, use:

        mke2fs -c -l badmap.dev.hda3 /dev/hda3

Using this, we found over 2000 bad blocks on the disk but no more i/o errors!

Good luck!

--
David


-- 
--
David


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

From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: 1.1.18->1.1.21 new hd.c "feature"
Reply-To: pe1chl@rabo.nl
Date: Fri, 24 Jun 1994 16:29:55 GMT

In <2udtdl$p3l@panix3.panix.com> stimpson@panix.com (S. Joel Katz) writes:


>       Howdy.

>       I just upgraded from 1.1.18 to 1.1.21 and I get an interesting error
>message during bootup:

>----------------------------

>Partition check:
>  sda: sda1 sda2 sda3 sda4 < sda5 sda6 sda7 sda8 >
>  sdb: sdb1 sdb2 sdb3
>hd.c: ST-506 interface disk with more than 16 heads detected,
>  probably due to non-standard sector translation. Giving up.
>  (disk 0: cyl=21072, sect=57, head=186)
>VFS: Mounted root (ext2 filesystem) readonly.

>----------------------------

>       sda and sdb are my two SCSI drives connect to an aha1542. They are
>the only hard drives in my system. I have no other hard drive controller and
>my BIOS is set for no hard drives. Apparently hd.c thinks I have a weird
>drive connected to a controller I don't have.

>       (I believe at this point hd.c has not even looked at the hardware
>yet and is only looking at the BIOS, but don't quote me on that)

>       This isn't causing me any problems so it's not a big deal, but I
>hate error messages and I prefer to keep standard hard drive support in my
>kernel because I use the same kernel on two other machines that have IDE
>drives.

An upgrade to 1.1.22 should fix that.
(reading the news before posting would also help :-)

Rob
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   rob@pe1chl.ampr.org           |
| e-mail: pe1chl@rabo.nl     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

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

From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: Disk-compression for Linux
Reply-To: pe1chl@rabo.nl
Date: Fri, 24 Jun 1994 16:33:07 GMT

In <2udflp$ork@chaos.dac.neu.edu> wdoyle@hilbert.coe.northeastern.edu (William Doyle) writes:

>3rd point:
>       Would it be possible to modify /bin/ld to produce a
>self-uncompressing executable?  (Of course, I know it's possible --
>with computers, everything is virtually possible! :-))  Perhaps
>someone who is looking for a summer project my consider this.  This
>could be an alternative to the reportedly unreliable gzexe approach.

Please note that Linux uses demand paging.  That means an executable
is not first read in memory where it can be conveniently uncompressed,
like under some other operating system.
The gzexe approach first uncompresses the executable into file from where
it can be paged in.
(I don't know about unreliability with this)

Rob
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   rob@pe1chl.ampr.org           |
| e-mail: pe1chl@rabo.nl     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

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

From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: Disk-compression for Linux
Reply-To: pe1chl@rabo.nl
Date: Fri, 24 Jun 1994 16:34:58 GMT

In <WAYNE.94Jun23205101@backbone.uucp> wayne@backbone.uucp (Wayne Schlitt) writes:

>Well, I have not actually seen it in use, but there are compressed
>file systems for Unix (SVR4, SCO, etc).  They _claim_ that they are
>faster than non compressed filesystems, unless you have a lot of CPU
>bound jobs.  

Probably only for sequential reading.  How about writing and/or nonsequential
access?

>I once timed it.  Even gzip can compress stuff faster than most disks
>can transfer, so it is quite believable that if you have disk bound
>jobs, that using compression could actually speed things up.

You probably mean "uncompress".  I don't think gzip compresses fast
enough on my 486/33 to saturate the (2 MB/sec) disk.

Rob
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   rob@pe1chl.ampr.org           |
| e-mail: pe1chl@rabo.nl     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

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

From: andersoa@news.db.erau.edu (Andrew Anderson)
Crossposted-To: comp.os.linux.help
Subject: Re: DOSEMU and Novell
Date: 27 Jun 1994 03:15:40 GMT

barryl (barryl@xs4all.hacktic.nl) wrote:
I had an idea on getting 2 ethernet cards to work with DOSEMU so that it
can access a Novell *Netware* (for the picky person who keeps pointing that
out! ;) file server without triggering the intruder lockout.  I have
to wait until tomorrow to test this for sure, but I'll let you know what
I find out.

Ok, with all that said, how about enableing the ports that the second 
ethernet card uses so that DOSEMU can access it directly, bypassing
linux entirely?  Is there any reason that I shouldn't be able to do this?
I had previously tried compiling DOSEMU with all references to eth0 changed
to eth1 so that it could co-exist with linux, but with no success.

I think I'll have to play with the NET.CFG and try to figure out how to
get the odi drivers to load (had trouble with it before, but I'll try 
again).  This method should be akin to enableing port 0x378 so that
DOSEMU can access the printer port, right?

I'd appreciate hearing from anyone using the odi drivers already,
because I hate having to re-invent the wheel! :)

Cheers,
Andrew
--
|===========================================================================|
|  Andrew Anderson                              andersoa@erau.db.erau.edu   |
|  Novell Network System Administrator          andersoa@bart.db.erau.edu   |
|  Linux System Administrator                   andrew@wilbur.db.erau.edu   |
|                                                                           |
| I don't speak for ERAU, and God knows I don't want them to speak for me!  | 
|===========================================================================|

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

From: byron@gemini.cc.gatech.edu (Byron A Jeff)
Subject: Re: Quirky idea: Remote Virtual Consoles
Date: 27 Jun 1994 03:12:10 GMT

In article <2ula4n$m0c@netaxs.com>, Brian Stoler <sto2@netaxs.com> wrote:
:Byron A Jeff (byron@gemini.cc.gatech.edu) wrote:
:: I've noticed that there are bunches of PC's that cannot run Linux.
:: Mostly 286's and early 386's with insufficient memory.
:
:: However I find that having a remote console for a Linux box an interesting
:: idea.
:
:
:Sounds like a great idea .. but how about making it support MULTIPLE 
:remote VCs on one remote PC? This would make the remote PC into another 
:complete monitor/keyboard set. Now, go write it! :)

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.

As for writing it: not a chance. I'm doing PhD work this summer and trying
to put together the Linux WordProcessing System. It's an overfull plate.

Later,

BAJ
-- 
Another random extraction from the mental bit stream of...
Byron A. Jeff - PhD student operating in parallel - And Using Linux!
Georgia Tech, Atlanta GA 30332   Internet: byron@cc.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-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
******************************
