Subject: Linux-Development Digest #761
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:     Thu, 26 May 94 17:13:06 EDT

Linux-Development Digest #761, Volume #1         Thu, 26 May 94 17:13:06 EDT

Contents:
  Re: Virtual Consoles (Joey Gibson)
  bug on kernel 1.1.15 (Supat Faarungsang)
  1.1.15 breaks SCSI (Rene COUGNENC)
  Re: CORBA, OMG, Distributed Objects (Mark Little)
  Re: Alpha testers for BETA on Linux (Jacob Seligmann)
  Re: Why is Linux monolithic? (Bernard James Leach)
  Re: SIGHUP - Deep Kernal Guts question! (Colin Plumb)
  Re: verdict on the NCR 83c510 drivers? (E.C. Loyd)
  bug in 1.1.15 (Faarungsang)
  Floppy Driver with other sector size? (Ulrich Dessauer)
  Re: 32-bit Novell desktop OS combines Unix, DOS 7 (Alan Cox)
  Re: Virtual Consoles (Andries Brouwer)
  Motif question (Carl Price)
  Q: Should recompiling the kernel update /etc/issue? (Khan M. Klatt)
  Re: CORBA, OMG, Distributed Objects (Kaelin Colclasure)
  Re: SIGHUP - Deep Kernal Guts question! (Ken Pizzini)
  Big in Signal-Handling under Linux 1.1.15 (Wuensch)

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

Subject: Re: Virtual Consoles
From: wjg@Creeper.Atl.GA.US (Joey Gibson)
Date: Thu, 26 May 1994 11:00:34 GMT

Elaine Walton (ewalton@magnus.acs.ohio-state.edu) wrote:
: I can understand his question: will Linux recognize that when I set this 
: #define to a number >12 will it know to accept the ctrl-alt-F1...?  (Or is it 
: shift-alt-numlock-capslock-F1?)

: Seriously, how will Linux map the keys?  Also, I know how to go from Xterm to 
: term using ctrl-alt-Fn.  But, how does one go back to the Xterm?

When you fire up X, it uses the first available VC (i.e. the first one
with no getty on it). If you have 12 VCs defined, but only have gettys
running on VCs 1 through 4, X will start up on VC 5. In my case, it
would run on VC14.

Joey
-- 
"Never trust a man in a blue trenchcoat, never drive | wjg@Creeper.Atl.GA.US
 a car when you're dead." - Tom Waits                | wjg@aix2.EMA.com
"They got a lot of coffee in Brazil" - Frank Sinatra | PGP public key
____________________________________________________ |  available on request


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

From: supat@nuntana.animal.uiuc.edu (Supat Faarungsang)
Subject: bug on kernel 1.1.15
Date: 25 May 1994 22:01:24 GMT

I got this bug in 1.1.12 1.1.13 1.1.14 and 1.1.15
it work fine up to 1.1.11

here the bug

stty: TCGETS: Operation not supported on socket

could anyone fix this bug. Thanks,
supat

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

From: rene@renux.frmug.fr.net (Rene COUGNENC)
Subject: 1.1.15 breaks SCSI
Date: 25 May 1994 20:37:09 GMT
Reply-To: cougnenc@hsc.fr.net (Rene COUGNENC)


The kernel 1.1.15 does not work at all with my Adaptec 1540B.
I get "Unable to reset SCSI host 0, probably a SCSI bus hang."

And I can't boot.

I never had any problem with Linux and this SCSI card, it is the first
time it does not work...

1.1.12 + tty patches is hopefully still working fine...

--
 linux linux linux linux -[ cougnenc@renux.frmug.fr.net ]- linux linux linux 

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

From: M.C.Little@newcastle.ac.uk (Mark Little)
Subject: Re: CORBA, OMG, Distributed Objects
Date: Thu, 26 May 1994 12:40:18 GMT


>
>
>   From: krauss@charlie.igd.fhg.de (Jens Krauss)
>   Newsgroups: comp.os.linux.development
>   Date: 25 May 1994 11:20:42 GMT
>   Organization: Haus der Graphischen Datenverarbeitung, 64283 Darmstadt, Germany
>   Reply-To: igd.fhg.de
>   Keywords: CORBA, OMG, Distributed Objects
>
>
>   Hy all there!
>
>   I'm very interested in distributed objects, perhaps I would like to 
>   implement something like that. If sombody out there is working on
>   dostributed objects for linux, mail me.
>   If nobody is out there, is there interest for an "corba"???
>
>   The problem is, that I have no acces to the OMG documents. But I have some 
>   ideas how to implement such thing. But whats about the standards...???
>   Would it be a good idea to programm such thing???
>
>   If there is no interest, perhaps I#ll doing it for my own, without standards!!
>

The latest version of the Arjuna distributed system to be released soon runs on
Linux (and a host of other architectures). This provides you with tools for the
construction of distributed and fault-tolerant applications constructed in C++,
and is intended to be Corba compliant in the near future. If you are interested
in this then you can get a lot of information via anonymous ftp from
arjuna.ncl.ac.uk (or http://arjuna.ncl.ac.uk/), including papers, user manual,
and the old source (this does not run on Linux!) After reading this if you are
interested in the latest version then send me some email.

All the best,
Mark.

=========================================================================
SENDER  : Mark Little, PHONE : +44 91 222 8066, FAX : +44 91 222 8232
          Arjuna Project, Distributed Systems Research.
POST    : Department of Computing Science, University of Newcastle upon Tyne,
          UK, NE1 7RU
ARPA    : M.C.Little@newcastle.ac.uk
JANET   : M.C.Little@uk.ac.newcastle



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

From: jacobse@daimi.aau.dk (Jacob Seligmann)
Crossposted-To: comp.object
Subject: Re: Alpha testers for BETA on Linux
Date: 26 May 1994 14:05:20 GMT

Due to an overwhelming amount of response, we have established a new 
mailing address,

   alphatest@mjolner.dk

to be used for correspondence concerning the alpha release of the 
Mjolner BETA Linux System. We kindly request that you contact us at 
this address if you are interested in becoming an alpha tester, 
rather than support@mjolner.dk. [The latter is still available for 
support mail concerning the Mjolner BETA System on all platforms. 
For information on the Mjolner BETA System and the BETA language in 
general, please send mail to info@mjolner.dk.]

Note that it will take some time for us to catch up. All mails will, 
however, be answered as quickly as possible. If you have not heard 
from us within a week, please do not hesitate to contact us again.

Thank you for your interest,

Jacob Seligmann
========================================================================
Mjolner Informatics ApS             Phone:   (+45) 86 20 20 00 ext. 2754
Science Park Aarhus                 Direct:  (+45) 86 20 20 11 - 2754
Gustav Wieds Vej 10                 Fax:     (+45) 86 20 12 22
DK-8000 Aarhus C, Denmark           Email:   jacobse@mjolner.dk       
________________________________________________________________________
                             BETA is better                             
========================================================================

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

Subject: Re: Why is Linux monolithic?
From: leachbj@latcs1.lat.oz.au (Bernard James Leach)
Date: Wed, 25 May 1994 22:23:52 GMT

Mario Gutierrez (mgutierr@mentor.sdsu.edu) wrote:
: Having just completed my Operating Systems course, I'm wondering why
: Linux is a monolithic operating system?  Moreover, why not loadable 
: device drivers?  Don't get me wrong I like Linux very much, I'm just
: curious?  I think the device drivers being built into the system is a
: big drawback, especially when you have a driver which patches against
: a certain version of the Linux kernel.  And if you want to add another
: driver which patches against a different version of the Linux kernel
: don't you run into problems?  Can anyone shed some light on this?

Well my guess its simply the fact that, thats the way other Unices work.
Didnt your OS course study things like that!?

The SLS distribution of linux has loadable drivers, however they are
not a part of the standard distribution.  Word has it that Linus is
looking into loadable drivers though.

-- 
Bernard Leach - LaTrobe Uni Melb Australia
cscbl@lux.latrobe.edu.au


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

From: colin@nyx10.cs.du.edu (Colin Plumb)
Subject: Re: SIGHUP - Deep Kernal Guts question!
Date: 25 May 1994 16:39:09 -0600

In article <2rj9pu$ec6@senator-bedfellow.mit.edu>,
Theodore Ts'o <tytso@ATHENA.MIT.EDU> wrote:
> As for programs going beserk and eating up lots of CPU --- they're
> broken.  And, I suspect, there are relatively few of them.  Perhaps your
> favorite version of "less" is broken that way, so you see a skewed
> version of the world.  But Unix programs all over the world have to work
> under the same rules, and so they tend to get fixed over time.

You could stick in a kludge so that the thousandth time a process tries
to read from a nonexistent /dev/tty, it gets something more to the
point than EIO, like SIGHUP or SIGPIPE.

Most emphatically a kludge, of course.
-- 
        -Colin

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

From: ecldco@ultb.isc.rit.edu (E.C. Loyd)
Subject: Re: verdict on the NCR 83c510 drivers?
Date: Thu, 26 May 1994 12:29:53 GMT

In article <2rqeft$sss@linus.mitre.org> jwagner@mental.mitre.org (John Wagner) writes:
>
>Well is there any? I've heard anything from weeks to months, and
>that was several weeks ago, anyone care to state a progress report?
>
>John

There are also three people at my work place (minimum) that are waiting for
an update on this driver, although we're a little less push-e (I deleted that
bit) than John.  :-)

-- 
Eric C. Loyd                        "I've got a [Roland U-110 preset 2] to prop
Operations Coordinator II           up my mortal remains."
ISC/Data Center Operations                                      -Pink Floyd
Rochester Institute of Technology   Phone:  (716) 475-7320

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

From: supat@meishan.animal.uiuc.edu (Faarungsang)
Subject: bug in 1.1.15
Date: 26 May 1994 13:32:42 GMT

When I type the following command then it work:

rsh -l supat meishan 'xterm -display 128.174.78.37:0'&

but when I save this command as "meishan"
and type meishan then it has following error:

stty: TCGETS: Operation not supported on socket

This error start in 1.1.12
Up to 1.1.11 the command work fine.

Could you fix this problem?

Thanks,
supat


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

From: ud@nitmar.muc.de (Ulrich Dessauer)
Subject: Floppy Driver with other sector size?
Date: 26 May 1994 11:30:07 GMT

Hello!

        I tried to read a floppy disk with an other sector size than the
typical PC floppies (256 bytes vs. 512 bytes.) The read failed and I had
a look into the floppy driver. As I understood the code it is possible
to switch to 256 bytes sector size. So I changed this in the driver and
tried again to read this disk. The driver had been able to access the
disk but the data seemed to be corrupted (i.e. the first sector read is
the physical 2.nd sector, the 2.nd sector read appears again in the 4.th
sector ...) Does anyone see a chance to implement this in the driver?
This would be a great enhancement for Linux, because then one is able to
read much more different formats and so can handle other file formats.
To write a (at least) read-only filesystem using userfs should not be
that problem at all.

                        Best wishes, U//i
--
        Ulrich Dessauer - +49 89 8417811 - ud@nitmar.muc.de

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

From: iiitac@uk.ac.swan.pyr (Alan Cox)
Subject: Re: 32-bit Novell desktop OS combines Unix, DOS 7
Date: Thu, 26 May 1994 12:44:52 GMT

In article <NELSON.94May25141928@crynwr.crynwr.com> nelson@crynwr.crynwr.com (Russell Nelson) writes:
>You don't understand -- Corsair is a desktop system, not a server
>system.  It's IPX support is going to be as a client, not a server.
>You'll still need your netware server.
>
Russ - NCP the layer the client would need to talk is a Novell trade secret
and fairly well guarded. If they give out a client source it'll only be a
month before someone knocks out a clone server (at least for file services)
as it is it might take 6 months to deduce from documents and ethernet traces

Alan


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

From: aeb@cwi.nl (Andries Brouwer)
Subject: Re: Virtual Consoles
Date: Wed, 25 May 1994 22:54:27 GMT

ac3slh@sunc.sheffield.ac.uk (Stuart Herbert) writes:

: Ideally, I'd like to have up to 24 :) (ALT F1-F12, and SHIFT-ALT F1-F12 if
: possible).  I've located the #define for setting the number of consoles,
: but I don't know what else I need to do to make it recognise the keypresses.

Nothing.
(That is, except for changing the #define, recompiling and installing.)

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

From: pricec@holmes.ece.orst.edu (Carl Price)
Subject: Motif question
Date: 26 May 1994 17:43:29 GMT

I have been seeing a lot of people asking about Motif, but no replies on
the net.  Well I need to know who has a good Motif for Linux and what the
price of it is, and the number to call to order.  Any experiences with one
package over another would also be appreciated.  I am hoping to port some 
apps and I need to get started soon, so all replies will be appreciated.

Reply to the net if you think it will be of interest to others or e-mail me

If you are with a company that makes one of the packages, e-mail me and let
me know why your package is better than the others.

--Carl W. Price
pricec@holmes.ece.orst.edu



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

From: n9044144@rowlf.cc.wwu.edu (Khan M. Klatt)
Subject: Q: Should recompiling the kernel update /etc/issue?
Date: 26 May 94 18:23:02 GMT

Recently I upgraded my kernel from version 0.99.15 to 1.1.0. I sync'd and 
rebooted, and was greeted by

Welcome to Linux 0.99.15 (or whatever)...

What's wrong? Did I miscompile? So I recompile a couple more times. 
Finally, I see 'version 1.1.0' on the bootup, but the login greeting is 
still 0.99.15. Being a Linux/UNIX newbie, I decided it wasn't the kernel.

So I started doing cat's and greps in /etc/rc.d looking for 'Welcome'. 
Then I recursed back into /etc. Finally, I found that message in /etc/issue.

After that brief intro, shouldn't recompiling the kernel be 
designed to modify /etc/issue? I edited the file myself, but am I really 
running version 1.1.0? What else do I need to do to run 1.1.0?

I guess I'm asking a simple question about 'what _exactly_ does version 
1.1.0 refer to?' I assumed it was the kernel... I'm asking in c.o.l.d. 
because with that above assumption, the kernel source code would have to 
be modified to update /etc/issue, or it should be included in the 
instructions on how to (re)compile the kernel to a different version...

* dons flame retardant clothing *

-K
-- 
-Khan M. Klatt---n9044144@henson.cc.wwu.edu---Western Washington University
        "If you ever fall off the Sears Tower, just go real limp,
         because maybe you'll look like a dummy and people will try
         to catch you because, hey, free dummy."
                                -Deep Thoughts by Jack Handey

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

From: kaelin@bridge.com (Kaelin Colclasure)
Subject: Re: CORBA, OMG, Distributed Objects
Date: 26 May 1994 17:49:00 GMT

In article <2rvcaa$io1@korfu.igd.fhg.de> krauss@charlie.igd.fhg.de (Jens Krauss) writes:

   I'm very interested in distributed objects, perhaps I would like to 
   implement something like that. If sombody out there is working on
   dostributed objects for linux, mail me.

Xerox Parc has a freely available system called ILU in beta test right
now, and I have successfully built and exercised it under Linux.  It's
not CORBA, but it's fairly close and it can use IDL for interface
descriptions.

Here's the original announcement from comp.lang.clos:

Version 1.6.4 of the Xerox PARC Inter-Language Unification (ILU)
system is now available for general use.

WHAT'S ILU?

ILU (pronounced eye'-loo) is a system that promotes software
interoperability via interfaces.  Interfaces between what?  Whatever
units of program structure are desired; we call them by the generic
term "modules".  They could be parts of one process, all written in
the same language; they could be parts written in different languages,
sharing runtime support in one memory image; they could be parts
running in different memory images on different machines (on different
sides of the planet).  A module could even be a distributed system
implemented by many programs on many machines.  Calls across ILU
interfaces involve only as much mechanism as necessary for the calling
and called modules to interact.  In particular, when the two modules
are in the same memory image and use the same data representations,
the calls are direct local procedure calls -- no stubs or other RPC
mechanisms are involved.

ILU modules are known by their interfaces.  A module interface is
specified once in ILU's object-oriented Interface Specification
Language (called, simply, ISL).  For each of the particular
programming languages supported by ILU (currently Common Lisp, ANSI C,
C++, and Modula-3; Python, Tcl, and GNU Emacs-Lisp are in the works),
a version of the interface in that particular programming language can
be generated.  The ILU kernel library provides services which may be
used by the language-specific interface to overcome intermodule
language or address space differences.

Many existing RPC systems, such as Xerox XNS Courier, ONC RPC, and OSF
DCE RPC, have strong notions of interfaces.  ILU allows binding to
such services provided by such systems if their interfaces can be
described in ISL.  ISL has been designed to facilitate such
description (currently, only for ONC RPC; Courier and DCE RPC are in
progress).  The binding to such RPC services is done in such a way as
to be indistinguishable from binding to other ILU modules.  In fact,
properly constructed ILU modules can appear as native RPC services,
and can be manipulated by non-ILU tools designed to work with those
RPC services.

Similarly, the Object Management Group's (OMG) Common Object Request
Broker Architecture (CORBA) defines modules with explicit interfaces.
ILU allows modules that can be described with a safe subset of OMG
CORBA IDL to be used as ILU modules, as well, though the ILU object
model is not quite the same as the OMG CORBA object model.  In fact,
people wishing to experiment with CORBA may find ILU a useful
experimental platform, as it does allow module specification with OMG
IDL, and does generate ANSI C support as specified in Draft 1.2 of the
OMG CORBA specification.  As the OMG specification for a C++ mapping
is agreed upon, we intend to provide that mapping for our C++ support,
as well.

Release 1.6.4 is intended as a beta release.  Major efficiency
improvements and some usability improvements are planned for the next
release.  It has been tested lightly on SunOS 4.1.3, Sun's Solaris
2.3, and SGI's IRIX 5.2.  It is designed to be highly portable, and a
port to the Macintosh has been done (but is not included in this
release).


GETTING THE RELEASE

The release is only available via FTP from the PARC ftp server.
Perhaps the simplest way is to go through our World Wide Web home
page, ftp://parcftp.parc.xerox.com/pub/ilu/ilu.html.  It has links to
everything else, and may help answer any questions you might have.

The release notes are available as an HTML document,

  ftp://parcftp.parc.xerox.com/pub/ilu/1.6.4/announce.html.

The full source code, including documentation, is available
as a 3 MB compressed tar file as

  ftp://parcftp.parc.xerox.com/pub/ilu/1.6.4/ilu-1.6.4.tar.Z

The 1.6.4 ILU manual is also available separately, either in
Postscript (231 KB) as

  ftp://parcftp.parc.xerox.com/pub/ilu/1.6.4/ilu-manual-1.6.4.ps.Z

or via World Wide Web at

  ftp://parcftp.parc.xerox.com/pub/ilu/1.6.4/manual-html/manual_toc.html.


CONTRIBUTORS

Antony Courtney, Doug Cutting, Bill Janssen, Denis Severson,
Mike Spreitzer, Mark Stefik, Farrell Wymore


COPYRIGHT RESTRICTIONS

ILU is Copyright (c) 1991, 1992, 1993, 1994 Xerox Corporation.
All Rights Reserved.

Unlimited use, reproduction, and distribution of this software is
permitted.  Any copy of this software must include both the above
copyright notice of Xerox Corporation and this paragraph.  Any
distribution of this software must comply with all applicable United
States export control laws.  This software is made available AS IS,
and XEROX CORPORATION DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING WITHOUT LIMITATION THE IMPLIED WARRANTIES OF MERCHANTABILITY
AND FITNESS FOR A PARTICULAR PURPOSE, AND NOTWITHSTANDING ANY OTHER
PROVISION CONTAINED HEREIN, ANY LIABILITY FOR DAMAGES RESULTING FROM
THE SOFTWARE OR ITS USE IS EXPRESSLY DISCLAIMED, WHETHER ARISING IN
CONTRACT, TORT (INCLUDING NEGLIGENCE) OR STRICT LIABILITY, EVEN IF
XEROX CORPORATION IS ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

Here're the release notes for the current (beta) version:

This is release 1.6.4 of the Inter-Language Unification (ILU) system.

=================
Release Notes
=================

Features:

This release includes supports for all ILU types except pipes, and
most features including multiple inheritance, threads, garbage
collection and across-the-wire polymorphism.  This release
specifically does not include support for pipes, multiple languages
in the same address space, or authorization/authentication.

Languages:

The supported languages in this release are C++ (tested with several
C++ compilers, GNU g++ among them), Common Lisp using Franz Allegro
Common Lisp 4.1, Modula-3 with the DEC SRC compiler and environment
v2.8, and ANSI C (tested with several compilers, including 2.5.8 "gcc
-Wall -D_POSIX_SOURCE").

Documentation:

This release includes documentation on ILU, ISL, and the bindings for
the various supported languages.  It does not include documentation on
the ILU runtime kernel exported procedures, or adding new language
support to ILU.

See the document INSTALLATION for more information on installing this
release.
--
// Kaelin Colclasure ---------------------------------------------------------
// EMail: kaelin@bridge.com            Mail: Bridge Information Systems, Inc.
// Voice: (314)567-8463                      717 Office Parkway
//   Fax: (314)432-5391                      St. Louis, MO 63141

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

From: ken@chinook.halcyon.com (Ken Pizzini)
Subject: Re: SIGHUP - Deep Kernal Guts question!
Date: 26 May 1994 18:27:50 GMT

In article <2rvvr5$gls@paperboy.osf.org>,
Dan Swartzendruber <dswartz@pugsley.osf.org> wrote:
>Despite the fact that POSIX is supposed to be a standard, I would
>venture to guess that the majority of Unix systems out there are
>not POSIX-compliant.  Given this, not checking for an error condition
>or a signal or whatever because it can never happen on a POSIX system
>strikes me as somewhat like the pedestrian being run over by a car -
>technically he's in the right, but he's still dead...

That sounds like a realy stupid idea, because POSIX only specifies
a certain *minimum* of error conditions that must be recognized
by the system.  The standard explicitly states that an implementation
may recognize other error conditions not explicitly stated in the
standard.  A common example is EFAULT -- POSIX does not require
this to be detected, but any reasonable unixoid implementation
will return an error with errno set to EFAULT if you pass it
a bad address in, for example, a call to read().

If you understand what it means to write a POSIX compliant application,
it is a reasonable baseline to write to.  Most of POSIX.1 is usable
on traditional Unix systems either directly or with a little interface
glue.  Some things, like reliable signals, may not be workaroundable
on broken historical systems, but in the large it is pretty easy to
do things like write a tcgetattr() wrapper around an old ioctl() call
in a OS specific glue module.

                --Ken Pizzini

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

From: hn324wu@unidui.uni-duisburg.de (Wuensch)
Subject: Big in Signal-Handling under Linux 1.1.15
Date: 26 May 1994 20:44:09 +0200

There seems to be a new bug in the signal handling in Linux 1.1.15.

When I call 
  stty int ^c 
in my login script the program gets suspended, and when I
draw it back into the foreground it complains about a wrong pgroup
several times before it kills my shell. Similar things happen
when I'm starting an emacs-like editor (which uses a signal-handler on
SIGINT).

The error didn't show up under Linux 1.1.14, so it's fairly certain,
that it's linked to the new kernel, since I didn't change anything 
else. 


        Happy linuxing 
        Karl Guenter Wuensch
        hn324wu@unidui.uni-duisburg.de


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


** 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
******************************
