Subject: Linux-Development Digest #797
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, 6 Jun 94 03:13:06 EDT

Linux-Development Digest #797, Volume #1          Mon, 6 Jun 94 03:13:06 EDT

Contents:
  Re: Let's rename v1.0.9! [Was: Frustrated with new kernels] (dan@oea.hacktic.nl)
  Re: Motif question (Gustaf Neumann)
  Keyboard: Handicapped access driver desired. (Alexander Williams)
  Re: Motif question (Chris Flatters)
  Re: Compile problems with stock kernel.. (Elaine Walton)
  Re: Let's rename v1.0.9! [Was: Frustrated with new kernels] (Jim Robinson)
  Re: AHRGH: I forgot: patch application problems? (Norbert J. Girardi)
  Re: Let's rename v1.0.9! [Was: Frustrated with new kernels] (Christian Henry)
  Re: Let's rename v1.0.9! [Was: Frustrated with new kernels] (Christian Henry)
  Re: Let's rename v1.0.9! [Was: Frustrated with new kernels] (Bjorn Ekwall)
  NTFS filesystem on disk layout (Thomas Vogler)
  Re: Let's rename v1.0.9! [Was: Frustrated with new kernels] (Matt Welsh)
  Re: ext2 IFS for OS/2 ? (Steve Whalen)
  SDCL DRIVER WANTED (Randolph Hill)
  Possible bug for kernel 1.1.18 (?) (Duen-Jeng Wang)
  Re: Let's rename v1.0.9! [Was: Frustrated with new kernels] (Ken Pizzini)

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

From: dan@oea.hacktic.nl
Subject: Re: Let's rename v1.0.9! [Was: Frustrated with new kernels]
Date: Sun, 5 Jun 1994 17:15:16 GMT

Bjorn Ekwall (bj0rn@blox.se) wrote:
: Let us rename 1.0.9 to 1.2.0!

: This way, those who haven't read the notices from Linus et al
: will go for that version, and stay away from 1.1.X...
: That would make everyone happy, wouldn't it?  :-)

I think Linus should make it a bit more difficult to get the development
kernels. A hidden directory advertised only on the kernel channel is a
good idea, IMHO. This way, if somebody goes to the trouble of getting the
latest kernel release, s/he can't claim ignorance.

-- 
|< Dan Naas        dan@oea.hacktic.nl >|
+--------------------------------------+

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

From: neumann@watson.ibm.com (Gustaf Neumann)
Subject: Re: Motif question
Date: Sun, 5 Jun 1994 21:34:10 GMT

In article <2sq4se$234@motif.hacktic.nl> from [4 Jun 1994 16:59:26 +0200] you wrote:
 |> MetroLink's Motif 1.2.2 does *not* work fine; it's shared version has problems
 |> with scrollbars and ScrolledTexts (core dumps when resizing windows). Sequoia
 |> 1.2.3 didn't have that problem.

MetroLink's Motif 1.2.3 does not have this problem either. At least on my system
it works like a champ.

-gustaf
--
Gustaf Neumann                     neumann@watson.ibm.com
Postdoctoral/Visiting Scientist    Tel: (914) 784 7086
IBM T.J.Watson Research Center, P.O.Box 704
Yorktown Heights, New York 10598


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

From: thantos@runic.mind.org (Alexander Williams)
Subject: Keyboard: Handicapped access driver desired.
Date: Sun, 05 Jun 1994 13:57:00 EST

I believe that I might need someone to actually craft a special driver for
my systems needs. Soon, I will be xlating this system over to Slackware 
Linux, and as such, will be needing the same functionality I get from my 
current DOS system under Linux. Being one of the handicapped users of the 
system, I can only use one finger to type with, and have a special TSR 
under DOS, and special keyboard drivers under Windows to cause the shift, 
ctrl, and alt keys to become toggles.

Has something of similar caliber been written for Linux?

--
thantos@runic.via.mind.org (Alexander Williams) | PGP 2.x keya avail
  Email is the right of the masses. So do it.   | DF 22 16 CE CA 7F
  Do What Thou Wilt Shall Be the Whole of the   | 98 47 13 EE 8E EC
  Law. Love is the Law, Love Under Will. -oOo-  | 9C 2D 9B 9B
===================================================================
"Democracy isn't just the best form of government; its the only one
   even remotely worth a damn. Only democracy guarantees people get
   what they deserve."
    -- Zeno Marley (Early 21st Century Mercenary-Philosopher)
                   [Dark Conspiracy RPG, pg 29]


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

From: cflatter@laphroaig.nrao.edu (Chris Flatters)
Subject: Re: Motif question
Date: 05 Jun 1994 22:50:02 GMT

>>>>> "Gustaf" == Gustaf Neumann <neumann@watson.ibm.com> writes:

    Gustaf> In article <2sq4se$234@motif.hacktic.nl> from [4 Jun 1994
    Gustaf> 16:59:26 +0200] you wrote: 
    Gustaf> |> MetroLink's Motif 1.2.2 does *not* work fine; it's shared 
    Gustaf> |> version has problems with scrollbars and ScrolledTexts
    Gustaf> |> (core dumps when resizing windows). Sequoia 1.2.3 didn't
    Gustaf> |> have that problem.

    Gustaf> MetroLink's Motif 1.2.3 does not have this problem
    Gustaf> either. At least on my system it works like a champ.

It was fixed by patch 1 to MetroLink's 1.2.2 (look in /vendor/MetroLink/LINUX
on ftp.uu.net).

When did MetroLink come out with 1.2.3 and why the heck didn't I get an
upgrade notice?

        Chris Flatters
        cflatter@nrao.edu

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

From: ewalton@magnus.acs.ohio-state.edu (Elaine Walton)
Crossposted-To: comp.os.linux.admin
Subject: Re: Compile problems with stock kernel..
Date: 5 Jun 1994 23:41:40 GMT

In article <1994Jun5.070716.5804@clark.dgim.doc.ca>,
root <root@orion.docwhitehorse.doc.ca> wrote:
>Greetings again from Whitehorse!...
>
>I just downloaded the stock version 1.1 kernel from sunsite.unc.edu, and am
>having more than a few problems getting it to compile. The file
>netdevices.c, and a few others appear to be missing.. To ensure that I was
>using a STOCK kernel, I toasted the entire source tree, and reinstalled the
>kernel from scratch.. Has anyone heard of any problems like this before, and
>if so do they have the solutions?.. For the record, I tried applying the
>various patches from 1 to (at the time current) 15, and that appeared to
>make the problems worse.. <sigh>..
>
>Thanks in advance..
>
>                   Cheers,
>                   Rich W.

Boy, does this sound familiar!  See gents, I'm not the only one with these
problems!  [I thought I had slipped into the FarSide...]
Okay, I found that tsx-11 had a faulty full 1.1.13 kernel.  It had some
things left out.  In fact, *.14 and *.15 also had other things left out.
You may have to get the real stuff from *.fi.  I got mine (1.1.17) from
linuxftp.caltech.edu.  It works great!
-Sean

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

From: jimr@shorty.cs.wisc.edu (Jim Robinson)
Subject: Re: Let's rename v1.0.9! [Was: Frustrated with new kernels]
Date: 6 Jun 94 00:53:47 GMT

In article <Cqxp9G.1qs@oea.hacktic.nl> dan@oea.hacktic.nl writes:
>I think Linus should make it a bit more difficult to get the development
>kernels. A hidden directory advertised only on the kernel channel is a
>good idea, IMHO. This way, if somebody goes to the trouble of getting the
>latest kernel release, s/he can't claim ignorance.

I think that's crazy.  Not to slight the kernel mail list or anything,
but I don't want yet another list cluttering my mail box just so I can
see the latest patch.  There are people without easy usenet access,
and there are people who don't have time/money to be on a large
mailing list; and it does not make sense to exclude them from being
able to find out where the patchs are if you move announcements to say
USENET or, as you say, a mailing list.  Should this be on c.o.l.m???

Jim

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

From: girardi@rniil.rni.sub.org (Norbert J. Girardi)
Subject: Re: AHRGH: I forgot: patch application problems?
Date: Sun, 5 Jun 1994 17:18:20 GMT

cps1@eccles.ee.ryerson.ca wrote:
: Thomas Boutell (boutell@netcom.com) wrote:
: : Forgive me, folks. I asked a month ago how to get the 1.1x patches
: : to apply properly when I was upgrading to 1.1.12. Now I'm trying
: : to upgrade to 1.1.18, I've forgotten what esoteric thing I
: : have to do to make patch work, and patch < patch13 (for instance)
: : fails to create new files.

: I usually do a "patch -s -p1 < patch18" from within the linux source directory
: (ie patch within  /usr/src/linux ).  Make sure all the patches leading up to
: patch18 are done in proper order otherwise you could end up with quite a mess.

I know what I'm doing is a overkill but .....
I am keeping all patches and an 1.1.0 kernal in a certain directory, renamed
all single digit patches ( like patch2 ) to double digit patches
( patch02 ) and *ALLWAYS* start from the clean 1.1.0 source.

This is my "patchme-1.1" script:

#! /bin/bash
cd /usr/src
rm -rf linux
rm patch.log
tar -xvzf /usr/spool/kernels/v1.1/linux-1.1.0.tar.gz
for i in /usr/spool/kernels/v1.1/v1.1/patch*
do
 echo "$i"
 patch -p0 < $i 2>>patch.log
done
# end of patchme-1.1
# ----------------------------------

After running the script I do a "grep fail patch.log" and if no "fail"
shows up, "cd/usr/spool/linux"

make config
make dep
make zlilo

and that's it.


- Norbert

PS: Why didn't the kernal gurus ( Hi, Linus ) start the patch numbering
    whit 2 digits in the first place? Didn't expect more than 9 patches
    for 1.1.0 <really *BIG* grin>

-- 
SSSSSS            SQUAREDANCE is FRIENDSHIP set to MUSIC.
S  QQSQQQ      Norbert J. Girardi < girardi@rniil.rni.sub.org >
SSSQSS  Q       Voice: +49 621 493417 (h) +49 621 381-3260 (w)
   QQQQQQ  If you know how to REPAIR YOUR SQUARE :-) drop me a line

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

From: henryc@reality.UUCP (Christian Henry)
Subject: Re: Let's rename v1.0.9! [Was: Frustrated with new kernels]
Date: 5 Jun 1994 19:17:20 -0400
Reply-To: henryc@io.org

In article <1994Jun3.143258.5919@ivax>, jonboy <jmmadiso@iupui.edu> wrote:

>why don't the directories that have 1.0 in it just rename the dirs
>stable-1.0.x
>and the patches say stable-[whatever]
>and others say ALPHA-1.1.x and patches
>say ALPHA (or BETA, whatever they are) [whatever]?

I tried suggesting that when the "split" was first suggested by Linus.  All
I received in response was an insult from one person against (basically)
anybody who hasn't been using Linux for at least 3 months.  :-/  That person
had the attitude that, since _he_ was comfortable with the x.x.x style of
version numbering, everyone else in the world must be (and, in a similar
manner, everyone else in the world will understand the "even second digit =
stable, odd second digit = not stable" version numbering better than "ALPHA,
BETA, STABLE (or RELEASE)).

I seem to recall this person referring to those less comfortable with this
scheme as "idiots" or "morons"; I should have flamed him when I had the
opportunity.  <grin>

-- 
 |  Christian Henry   //   North York, Ontario   |  e-mail:  henryc@io.org  |
 |  ``Justice is lost, Justice is raped, Justice is gone...''  - Metallica  |

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

From: henryc@reality.UUCP (Christian Henry)
Subject: Re: Let's rename v1.0.9! [Was: Frustrated with new kernels]
Date: 5 Jun 1994 19:21:29 -0400
Reply-To: henryc@io.org

In article <2spee9$sk8@harbinger.cc.monash.edu.au>,
Kevin Lentin <kevinl@bruce.cs.monash.edu.au> wrote:

>That's already how it works. 1.0.x are the stable kernels with bugfixes and
>1.1.x are the new kernels with new features and bug fixes.
>
>The argument here may be whether the odd or the even kernel should have the
>greater number so that people who do not know what is going on would
>automatically take the latest stable kernel (hence the call for 1.2.0). I
>find this a bit weird. It would be real strange to be developping a kernel
>with a version lower than the stable one. To be developping 1.1.x while
>1.2.x is out is wrong. And what happens when 1.1.x is declared stable? Make
>it 1.4.0 and then the next kernel after 1.4.0 is  1.4.1 for the stable ones
>and 1.3.0 for a new feature. It would cause far more confusion than there
>is now.

What _I've_ been trying to figure out is, why don't we simply append an
"ALPHA" or "BETA" (or even "UNSTABLE") keyword to the end of the version
number for the "Hacker's paradise" versions, and when the kernel is believed
reasonably stable for the time-being, replace the word with "STABLE",
"RELEASE", or nothing?

In my experience, people are more likely to understand that "1.2.0 ALPHA" is
less stable than "1.1.0" or "1.2.0" (with or without "RELEASE on the end of
those version numbers).

-- 
 |  Christian Henry   //   North York, Ontario   |  e-mail:  henryc@io.org  |
 |  ``Justice is lost, Justice is raped, Justice is gone...''  - Metallica  |

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

From: bj0rn@blox.se (Bjorn Ekwall)
Subject: Re: Let's rename v1.0.9! [Was: Frustrated with new kernels]
Date: 6 Jun 94 01:24:30 GMT

dan@oea.hacktic.nl wrote:
 ...
 > I think Linus should make it a bit more difficult to get the development
 > kernels. A hidden directory advertised only on the kernel channel is a
 > good idea, IMHO. This way, if somebody goes to the trouble of getting the
 > latest kernel release, s/he can't claim ignorance.

 > -- 
 > |< Dan Naas     dan@oea.hacktic.nl >|
 > +--------------------------------------+

My own experiences with hidden/private directories aren't all that
pleasant...  I think Linus wants all sources freely accessible for
everyone.  The "problem" comes mainly from people that hope that the
kernel with the highest "number" automatically is always the best and
safest for them, hence my suggestion of renaming the most "stable" kernel.

Cheers,

Bjorn Ekwall == bj0rn@blox.se

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

From: tvo@zaphod.swb.de (Thomas Vogler)
Subject: NTFS filesystem on disk layout
Date: 05 Jun 1994 17:26:03 GMT

i once posted this some time ago, but received no replies at all.
hopefully this one has some more success.

i intend to write a filesystem driver for linux supporting NTFS in order
to be able to access my NTFS formatted disks under Linux. In a first
attempt i plan to support read only access only, write access might follow
later.

in order to do this, i will need some informations how NTFS files are stored
on a disk.

does anyone know a source of information where such details can be found ?

i checked with all my local computer bookshops and the microsoft developer 
network cd's, but could not find anything except a few notes in the 
WindowsNT resource guide, which dont help much.

since i dont have access to compuserve, i hope some of you guys know if
something like this can be found there and (if permitted by Microsoft)
mail me either to specs or give me a pointer where to look and wether its
worth to look.

any help appreciated.

thomas
--
-- 
thomas vogler, sch"aferweg 25, 64354 reinheim, germany, tvo@zaphod.swb.de
phone: +-[49]-(6162)-83754. ein rabe geht im feld spazieren, da faellt der
weizen um (h.s.).

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

From: mdw@cs.cornell.edu (Matt Welsh)
Subject: Re: Let's rename v1.0.9! [Was: Frustrated with new kernels]
Date: Mon, 6 Jun 1994 02:16:39 GMT

In article <2sqjas$fi1@nwfocus.wa.com> ken@coho.halcyon.com (Ken Pizzini) writes:
>Perhaps a little odd, but consider: the naive user will pick up the 1.4.x
>kernel while the (presumably) clued-in kernel hackers/bleeding edge folk
>work on the 1.3.x series.  I really don't think the hackers will be
>confused by the inversion,

Except for the fact that it's an extremely dumb idea. Once you
start turning things backwards so that "naive users" can make
"correct" mistakes, you lose. 

Anyone who is that daunted by the kernel version numbering scheme
shouldn't be upgrading kernels themselves. Believe it or not,
there are some aspects of using Linux that require a clue.

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

From: swhalen@netcom.com (Steve Whalen)
Subject: Re: ext2 IFS for OS/2 ?
Date: Mon, 6 Jun 1994 04:41:59 GMT

Payne (rickp@dcs.qmw.ac.uk) wrote:
: ...Another issue is that of protection. I should imagine you'd need to
: produce a login program for OS/2 that would have to reference the
: /etc/passwd file etc.
...
: I think a better target would be (and this is what I wanted/want to do)
: to develop a OS/2 IFS that provided a method of mapping OS/2 calls to 
: Linux VFS calls, and also provided the remaining linux functions that
: file systems need. This way any current Linux file system could be
: ported to OS/2 with the minimum of porting to be done.
...
: If I get time (what with starting a new job and moving house etc.) I am
: definitely going to be looking at this. I started a while ago, but then
: ran out of time. Hopefully I'll get it finished this time :)

Hopefully you'll get to it before I do, because I KNOW I don't want
to "claim" this project ... it would be literally next YEAR before
I got seriously started...

I think you're right about it being easier to port the VFS layer, 
and would have the advantage of making it a lot easier to port 
the various other Linux file systems for those perverts <g> who
don't use ext2...  

I hadn't considered actually using ext2 as my OS/2 file system, but
you're right, from my experience, ext2 would probably be faster than
HPFS.  Of course it's hard to separate whether ext2 seems faster
that HPFS because Linux is faster than OS/2, or whether ext2 is
inherently that much faster than HPFS...

Re: protection and needing to access /etc/passwd:  I hadn't thought
about going that far, at least not in the first generation.  In my
environment, the OS/2 password/lockup facility would be adequate
for the superficial security I need, since I'm not directly on 
a network, etc....  But I suspect you're right that some future
iteration would replace any VFS security functions that were dummied
out, with the real thing...

Good luck with the job, move, and OS/2 Linux VFS file system!

-- 
{===----------------------------------------------------------------------===}
      Steve Whalen     swhalen@netcom.com     70156.320@compuserve.com
{===----------------------------------------------------------------------===}

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

From: bliff@phimai.corp.sun.com (Randolph Hill)
Subject: SDCL DRIVER WANTED
Date: 6 Jun 1994 04:50:40 GMT
Reply-To: bliff@phimai.corp.sun.com

Are there any public domain SDLC drivers available for Linux or SNA3274 gateway 
emulation packages ?



//Randy Hill




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

From: wdj@gcrca.biostat.wisc.edu (Duen-Jeng Wang)
Subject: Possible bug for kernel 1.1.18 (?)
Date: 6 Jun 1994 05:03:43 GMT

I have not seen a problem that I have experienced reported in *.linux.*
news group. I am wondering the following message after 4 hours running
of my kernel 1.1.18 is a bug or my mistake.


Jun  5 02:07:16 bowser kernel: Unable to handle kernel paging request at kernel address 0de2c0de
Jun  5 02:07:16 bowser kernel: current->tss.cr3 = 0082c000, Xr3 = 0082c000
Jun  5 02:07:16 bowser kernel: *pde = 00000000
Jun  5 02:07:16 bowser kernel: current->tss.cr3 = 0082c000, Xr3 = 0082c000
Jun  5 02:07:16 bowser kernel: *pde = 00000000


I have had no such message prior v.1.1.18. Besides, I have experienced
slip connection mysteriously disconnected for kernel 1.1.17 and 1.1.18.
The kernel was ftped from ftp.funet.fi (linux-1.1.13.tar.gz) and patched
with patch14-18.

Any information about the problems is much appreciated.


Duen-Jeng


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

From: ken@chinook.halcyon.com (Ken Pizzini)
Subject: Re: Let's rename v1.0.9! [Was: Frustrated with new kernels]
Date: 6 Jun 1994 06:26:00 GMT

In article <1994Jun6.021639.26906@cs.cornell.edu>,
Matt Welsh <mdw@cs.cornell.edu> wrote:
>In article <2sqjas$fi1@nwfocus.wa.com> ken@coho.halcyon.com (Ken Pizzini) writes:
>>Perhaps a little odd, but consider: the naive user will pick up the 1.4.x
>>kernel while the (presumably) clued-in kernel hackers/bleeding edge folk
>>work on the 1.3.x series.  I really don't think the hackers will be
>>confused by the inversion,
>
>Except for the fact that it's an extremely dumb idea. Once you
>start turning things backwards so that "naive users" can make
>"correct" mistakes, you lose. 
>
>Anyone who is that daunted by the kernel version numbering scheme
>shouldn't be upgrading kernels themselves. Believe it or not,
>there are some aspects of using Linux that require a clue.

But the users have to *see* the damn message about version
numbers.  What's the big deal that the hacker's paradise has to be
a larger number?  *Both* trees are being updated, albeit the
"stable" tree is updated much less frequently.  It really is not
all that difficult a proposition for a user experienced in
programming Unixoid systems to compile a new kernel and have it
work, _if_ the kernel is not an alpha-release.  Why do you want to
require, and expect (!) such folk to wade through FAQs, INFO
sheets, HOWTOs, and c.o.l.* disccussions to discover one of the
three places that it is mentioned clearly that 1.0.9 is a recent,
good, stable kernel and 1.1.x is a potential landmine?  Yes, there
are some aspects of using Linux that require having a clue, and
running an alpha kernel is one of them.  But simply recompiling
the kernel doesn't (or, rather needn't) require a Linux-specific
clue.

                --Ken  Pizzini

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


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