Subject: Linux-Development Digest #127
From: Digestifier <[email-masked]>
To: [email-masked]
Date: Tue, 6 Sep 94 07:13:19 EDT

Linux-Development Digest #127, Volume #2          Tue, 6 Sep 94 07:13:19 EDT

Contents:
  Re: News Spool File System - new filesystem type?? (Albert D. Cahalan)
  Re: how to do shared C libraries (was Re: nvi 1.34, curses and the new Linux C library) (David Barr)
  Re: Acid (Lau)
  Re: Future of linux -- t (Lau)
  Re: WARNING about shadow-mk package (Joe Zbiciak)
  Booting 1.1.46 boots CD as root,not disk-Help! (Sam Gentile)
  Re: IDE Hard Drives w/ over 1024 cylinders (Dougal Campbell)
  Re: IDE Hard Drives w/ over 1024 cylinders (Daniel Quinlan)

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

From: [email-masked] (Albert D. Cahalan)
Crossposted-To: news.software.b
Subject: Re: News Spool File System - new filesystem type??
Date: 06 Sep 1994 03:17:39 GMT

In article <[email-masked]> [email-masked] (Michael Dillon) writes:
   > This is actually an argument for compressed filesystems, particularly
   > when data is write-rarely, read mostly.  There are compression
   > methods that compress relatively slowly, but decompress so fast that
   > it's much faster to read one block and decompress it than to read 2 or 3
   > non-compressed blocks.

   Hmmm.... I can see it now, the NSFS (News Spool File System).

   1. This is a compressed file system using LZ technology
   2. Since LZ compression replaces repeated strings with a dictionary
      reference and since news postings tend to have a lot of the
      same words over and over, the NSFS uses a two part dictionary.
      The first part of the dictionary is applied to all files in the
      NSFS and contains words that are likely to occur in many news postings.
      This includes headers and common English words and phrases. The
      second part is a file specific dictionary as is normally found in
      LZ compression systems.
   3. A utility is included to replace the common dictionary with
      your own specifications. This utility will only run on an
      unmounted file system.
   4. An analysis program will do statistical analyses of the contents of
      your NSFS to determine what repetaing strings appear most frequently.
      You can use this analysis to provide a different common dictionary.

   I wonder if message-id's could be worked in there somehow?

5. Reduced set of permissions
--

Albert Cahalan
[email-masked]

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

From: [email-masked] (David Barr)
Subject: Re: how to do shared C libraries (was Re: nvi 1.34, curses and the new Linux C library)
Date: 6 Sep 1994 00:09:34 -0400

In article <[email-masked]>,
Mitchum DSouza <[email-masked]> wrote:
>In article <[email-masked]>, [email-masked] (David Barr) writes:
>|> Okay, I'll spell it out.  In Solaris, the filename of the shared
>|> libraries to load are stored at compile-time.  There's also
>|> run-time directory search list which is built from ld's -R flag and
>|> LD_LIBRARY_PATH, if set.
>
>I had patches to ld/ld.so to implement this for linux, but it is not really
>worth the extra binary bloat by recording paths at compile-time. Having a
>sensible cache in place is usually enough to satisfy the linking procedure.

Huh?  A cache is only good for speed-up purposes.  A cache does you no
good if you have two incompatible libraries around of the same name
that you need simultaneous access to.  (Oh, like say X11R5 libX11.so and
X11R6 libX11.so)  In fact a cache needlessly randomizes and obscures
the process.  Having compile-time library paths (and filenames) is in
no way "binary bloat".

It's funny that you're hung up on the "Slowaris" moniker here, since
Solaris's shared library loader is significantly faster than SunOS 4.x's.
(and all else being equal, as fast or faster than Linux's)

--Dave

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

From: [email-masked] (Lau)
Subject: Re: Acid
Date: 5 Sep 1994 23:48:16 -0400

On 09/03/94, Michael wrote:                   

>Subject: Re: Acid
>
>>     Again, "truly internationalized" is something that will take a while in 
>> any OS.  Can you think of ANY OS or app that will allow you to write from 
>> left to right(English & most European languages), right to left(Hebrew) AND 
>> top to bottom from the left to right (Chinese), all in the same document?
>
>Yep, two. One is NAPLPS which is an ANSI/CSA/ISO standard for representing
>graphics and text that was originally developped for TV videotext but is
>now used in distance education (with Thai, and Inuktitut and Korean
>and Chinese), and by BBSes (Lakota Sioux, Japanese, Cyrillic).
    
    This still only uses bitmapped graphics, not character coding.  You 
can't edit the text, only view it (I know, I only said 'write' above). 
 Also, you can't search the text.  In the context of a "truly 
internationalized" OS/app, NAPLPS still falls short of the mark.
>
>The other one is Postscript although I'm not sure that there is any
>frontend application or very many fonts that let you access the full
>power of Postscript for this kind of thing.
    
    Postscript would come very close but having to incorporate 
bitmaps/glyphs w/ each file would be a pain (not to mention outrageously 
huge...have also yet to see non-European language fonts for less than an 
arm and a leg).
    
    Actually, TeX/LaTeX would come closest...and its available for several 
languages.
>
>cruisin' down the information highway, lookin' for a blast
>breakin' all the speed limits as I come zoomin' past!
>--
>Michael Dillon                 Internet: [email-masked]
>C-4 Powerhouse                  Fidonet: 1:353/350
>RR #2 Armstrong, BC  V0E 1B0      Voice: +1-604-546-8022
>Canada                              BBS: +1-604-546-2705

    Kin Lau ([email-masked])
    
---
* UniQWK v3.0 * The Windows Mail Reader

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

From: [email-masked] (Lau)
Subject: Re: Future of linux -- t
Date: 5 Sep 1994 23:48:28 -0400

[email-masked]
On 09/05/94, Joachim wrote:                   

>Subject: Re: Future of linux -- the sequel
>Date: 5 Sep 1994 10:41:32 GMT
>In article <[email-masked]>, [email-masked] (Rob Janssen) 
writes:
>> In <[email-masked]> [email-masked] 
(Larry Pyeatt) writes:
>> 
>> >In article <[email-masked]>, 
[email-masked] (Donald Becker) writes:
>> >|> >                                        $6400 minumum
>> >|> 
>> >|> That's just way more than a reasonable Linux box will cost.
>> 
>> >Define "reasonable."  I defined reasonable to be "something similar to
>> >SGI Indy.  You can't get that sort of performance with cheap parts.
>> 
>> Hey come on, he explained how all prices that added up to that $6400
>> were way above current street-price for PC parts.
>
>Yeah, but he used $33 Ethernet cards (I assume NE2000s) and explained
>that 4MB is enough to run Linux+X and compared these parts to
>respective workstation equipment. IMHO that disqualified him.
    
    I missed some of what Donald wrote but you should take a second look at 
who Donald Becker is before making the above statement.  Donald wrote most 
of the ethernet code...and is more familiar w/ ethernet than you or I will 
probably ever be!
>
>As an example, I'm currently thinking about upgrading my 16MB to 32MB
>since it's not enough for serious work. The AIX system at work is
>already short at memory with 32MB, 64 or 128 MB would be fine. How
>can I put 128 MB in my VLB PC? That's the reality I'm living in, and
>I suppose Larry has a similar environment. I was even astonished that
>he listed only a 400 MB disk, I wouldn't buy anything below 1 GB.
    
    Reality is you'll likely never NEED 128 MB in your VLB PC.  Again, 
pound for pound, RISC code is going to be about 30% larger than CISC code. 
 If you NEED 128 MB, get a newer motherboard w/ 72pin simms...4 32MB simms 
= 128 MB.  I've seen quite a few MB's w/ 6 72pin simm slots, max 196 MB!!!
>
>On the other hand, might be that peripherie prices in the US are
>really as low, I would love to have a `nice' 17" monitor (i.e.,
>one that has ca. 80 kHz, 135 MHz, Trinitron if possible) for $ 850.
    
    No problem!  The prices here are really that low.
    
>But I suspect that Donald's term `nice' is simply a different one than
>mine.
>
>Cheers,
>       Joachim

    Kin Lau ([email-masked])
---
* UniQWK v3.0 * The Solution for Multilingual Messages

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

From: [email-masked] (Joe Zbiciak)
Subject: Re: WARNING about shadow-mk package
Date: 5 Sep 1994 23:24:43 -0500

In <[email-masked]> [email-masked] (Bauke Jan Douma) writes:

>In article <[email-masked]>, bjdouma <[email-masked]> wrote:

>>Here's the snippet from the Makefile where login is installed:
>>
>>      install -m4755 login $(LOGINDIR)/_login
>>      install -m4711 login.secure $(LOGINDIR)/login
>>      
>>So how secure can it be that there are no sources.
>>Just asking.

I apologize.  I am the author of the /bin/login replacement that is included
in the shadow-mk package.  Mohan Kokal, the author of the shadow-mk package,
is not to blame.  I had asked him not to distribute my (ugly) source.  :-)

>Ok, I will now follow up on my earlier post about the shadow-mk
>package.

>I would advice anyone that has installed this package to remove it.

This is not necessary.  The source for the binary in question will be
posted later this evening.  I need to return to my linux box in order
to upload it.  I do not have it readily available at the moment.

>I have received an email from someone who also noticed the
>installation of the login.secure binary, for which no source is
>provided.

I will post the source to the /bin/login replacement that I wrote, and trust
on my own system.  I did not realize that the net would grow so suspicious.
I should have known better.  :-)  After all, it could be snake oil, for
all the net knows.  I realize now, especially after reading the files 
focusing on security issues that were included with PGP, that it is *very*
important to make the source available to public scrutiny.  Indeed, for
similar reasons, I do not trust Clipper encryption (aside from the gov't
back-door).

I will also post the version of GCC with which is was compiled, the version
of libc with which it was compiled, and the compilation flags, so that
each person make verify that it is indeed the source from which that 
binary was created.  I will also have Mohan Kokal include the source in
future versions of the shadow-mk package.

In the meantime, I will detail how my patch works, and how it closes the
now well known hole:

My patch simply forces all argv[] elements beginning with a - to be no
longer than 2 characters long, by writing a 0 into the third position
after the dash.  Thus, if a user tries login -froot, the "r" in root
would be overwritten, and the remainder, "oot", would be affectively
truncated.

Furthermore, my patch addresses another security issue, the misuse of
the semi-documented -h switch, by disallowing anyone with a real uid greater
than 100 from using it.

Once all paramters have been patched, and the absence of -h is assured if
UID>100, all parameters are passed to an unmodified /bin/_login.

The new /bin/login is statically linked, using maximum optimizations,
and is stripped, to make the smallest possible binary.

Again, as I said, the source will be posted later this evening, along with
GCC version, libc version, optimization flags, and so on.

>In his correspondence with the author of this package, that author,
>in his helpfulness, asked for a temporary account on his machine, and
>having been denied that, asked for the password file. The emailer
>also told me he has observed the author of this package to be
>bragging about violating computer security.

To whom are you referring?  Mohan Kokal may have a number of accounts on
various Linux boxes, for various reasons.  If you are referring to one
of these accounts, please make known the circumstances in greater detail
than you have.  This is an accusatory statement based on heresay and 
circumstantial evidence. 

Furthermore, "bragging about violating computer security" may be something
as simple as "whoa... on an older Linux box, I noticed a hole in crontab
that allowed such and such..."  or "yeah, I used rlogin to gain root--that
old /bin/login was a joke."

I, as well as some others, I am certain, would like to see a factual basis
for this outright character assassination that you are making.  I have no
reason to doubt that you may be able to support your statements.  However,
I also have NO reason whatsoever to believe any of your closing statements.

--Joseph R. M. Zbiciak, System Administrator, Texas Networking Systems, Inc.

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

From: [email-masked] (Sam Gentile)
Subject: Booting 1.1.46 boots CD as root,not disk-Help!
Date: Tue, 6 Sep 1994 02:54:46 GMT

I have finally gotten 1.1.46 to build with the soundcard stuff correctly. 
However, back in the first attempt at building I was unsuccessfull in 
setting up LILO so that I could boot the old Linux 1.1 kernel as a backup 
and lost that ability. So I had to use my summer 94 Yggdrasil boot disk 
and CD, mount my /dev/hda1 as /mnt, and then build 1.1.46 on that disk. 
It was painful and took a long time because it was using the CD as root. 
After a few attempts it is now built. I couldn't do LILO to set up to 
boot this off the hard disk because it tries to do something with /tmp 
which is on the read-only CD, so I created a boot disk. It boots 1.1.46 
fine but then it mounts the CD as root and not /dev/hda1 and I can't run 
LILO and I can't edit the files in /etc. How do I fix this? Why is it 
even booting off the CD? Help please.

Thanks,
Sam

-- 
============================================================================
Sam Gentile                     Mitakuye Oyasin - All My Relations
[email-masked]               Live in balance with Mother Earth and
[email-masked]                 all of Creation
=============================================================================

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

From: [email-masked] (Dougal Campbell)
Subject: Re: IDE Hard Drives w/ over 1024 cylinders
Date: 5 Sep 1994 22:26:17 -0500

From [email-masked] Sun Aug  7 12:41:48 1994
Date: Sat, 6 Aug 1994 17:08:54 -0400
From: "Patrick J. LoPresti" <[email-masked]>
Reply to: [email-masked]
To: Dougal Campbell <[email-masked]>
Subject: Re: Ack!!! Please HELP ME install on Dell Pentium with EIDE drive

======================================================================
                Everything I Know About Linux and EIDE
                --------------------------------------

Introduction
============

It is possible to use Linux on a large EIDE drive with no restrictions
on where anything resides.  I only deal with DOS and Linux here, but
the approach I suggest should be compatible with other operating
systems as well.

I presently use version 1.0.9 of the kernel, but everything here
applies to kernels at least through 1.1.34.  Sometime in the future,
Linux will probably support EIDE gracefully and transparently, at
which point all of this will be moot.  Everything I suggest, however,
should continue to work with these future kernels, although most of it
will become unnecessary.

Background and Terminology
==========================

Sectors on an ATA (IDE) drive are 512 bytes long.  There are two ways
to address sectors.  Logical Block Address (LBA) form, or logical
form, numbers the sectors linearly starting with 0.
Cylinder-Head-Sector (CHS) form, or physical form, addresses each
sector with a (cylinder, head, sector) triplet.  To convert addresses
from logical to physical form, it is necessary to know how many heads
per cylinder and how many sectors per head the drive has.  If the
total number of cylinders is known as well, the size of the drive can
be determined.  The number of cylinders, heads per cylinder ("heads"),
and sectors per head ("sectors") is called the "disk geometry".

Old controllers and BIOSes require sectors to be addressed in physical
form; all controllers and BIOSes allow sectors to be addressed in
physical form.  Linux uses logical addresses everywhere except at the
lowest possible level, when it translates to physical form to talk to
the controller.  Linux does not use the BIOS for anything except to
determine the disk geometry.

The partition table records the start and end of each partition in
*both* logical and physical form.  Both DOS fdisk and Linux fdisk
expect these values to agree.  DOS fdisk obtains the disk geometry by
querying the BIOS; Linux fdisk obtains the geometry by querying the
kernel.

Now for the fun part.  MS-DOS and the BIOS interface use a 10-bit
field to hold the cylinder number, so they only allow cylinders 0-1023
to be accessed.  This is not sufficient for modern drives, which tend
to have 63 sectors/head, 16 heads/cylinder, and many cylinders.  The
"solution" is a complete hack: An EIDE BIOS will *lie* when queried
for the disk geometry by halving (or quartering) the number of
cylinders and doubling (or quadrupling) the number of heads.  Then
whenever a physically addressed I/O request arrives, the BIOS will
assume the request is based on the bogus disk geometry, and will
convert it appropriately to talk to the controller.  This process is
called "address translation".

The Problem
===========

When the Linux kernel queries the BIOS (actually, it just reads the
CMOS settings) to determine the disk geometry, it will get the bogus
values which claim more than 16 heads.  Linux knows that this is
impossible, so the code in hd.c gives up and skips the drive.  (Note
that even though the BIOS is reporting a bogus geometry, requests to
the controller still need to be based on the real geometry.  Thus
merely eliminating the test in hd.c won't work.)

The Wrong Solution
==================

One fix is to use the BIOS "setup" program to turn off address
translation completely.  You may have to manually set the
cylinder/head/sector values to the real geometry, or it may be
possible to simply turn off the translation, depending on how your
setup works.

Then you can repartition your drive with DOS and/or Linux fdisk,
install both operating systems, and things will work, provided you
observe certain restrictions.

The problem is that the BIOS still can't be used to access cylinders
above 1023.  So all of your DOS partitions will have to be below that
limit, as will anything which needs to be accessed through the BIOS.
For example, LILO uses the BIOS to do its dirty work; so if you want
to use LILO to boot Linux, you will have to make sure the kernel
(read: entire root partition) lies below the 1024 cylinder limit.
Linux itself, however, will happily access the entire drive.

The Right Solution
==================

Restrictions are annoying, so we will avoid them.  This obviously
requires leaving address translation on and dealing with the remaining
problems in a different way.

To fix the kernel's problem, simply feed the real geometry to the
kernel with a boot-time option line.  You can do this from the LILO
boot prompt by typing "<image name> hd=<cylinders>,<heads>,<sectors>".
You can also have LILO feed the options automatically by using an
"append=" directive in your lilo.conf file.

Now the kernel will be able to recognize and access the drive, but
when a user mode program (e.g., fdisk or the LILO installer) queries
the kernel for the disk geometry, the kernel will return the real geometry,
not the bogus one.  So Linux fdisk (which queries the kernel) and DOS
fdisk (which queries the BIOS) will disagree about how the partition
table should look.  Also, the LILO installer will be computing
physical addresses which are incompatible with what the BIOS (and
therefore the LILO runtime) requires.

The fdisk problem is easy to fix:  Go to expert mode, and set the
number of cylinders and number of heads to the bogus (BIOS-compliant)
values.  Then edit the partition table and write it out, confident
that Linux fdisk and DOS fdisk are seeing eye to eye.

The LILO problem is just as easy to fix: Add the "linear" directive to
your lilo.conf file.  This will cause LILO to use logical addresses
instead of physical to store its data, forcing LILO to compute
physical addresses at run time instead of at install time.  This will
use the geometry supplied by the BIOS instead of that supplied by the
kernel, and everything will "just work".

Example / Summary
=================

I have a 1 Gig EIDE drive on which I recently installed Linux.  Here
is the procedure I used.

1) Ran setup and examined the (bogus) disk geometry.  It said 505
cylinders, 64 heads, 63 sectors.  More than 16 heads is impossible, so
the real values must be 2100 cylinders, 16 heads, 63 sectors.

2) Booted DOS boot disk, ran fdisk, created a DOS partition.

3) Booted Slackware boot disk.  Typed "ramdisk hd=2100,16,63" to boot
the kernel.  Ran Linux fdisk, typed "p" to see lots of errors, typed
"x" to access expert mode, set cylinders to 505, set heads to 64,
returned to normal mode, typed "p" to see my DOS partition and no
error messages.  Created partitions to heart's content.  Saved
partition table and rebooted from Slackware disk (not sure why I had
to do this).

4) Installed Slackware normally, creating an ordinary lilo.conf file.

5) Edited lilo.conf (in this case, /mnt/etc/lilo.conf) to add these
lines to the top:

append="hd=2100,16,63"
linear

6) Ran "lilo -r /mnt".  I expected to need the "-P ignore" option, but
didn't.  Go figure.

7) Installed DOS and Windows, much to my chagrin.

Good luck to all.

- Patrick LoPresti
  [email-masked]

-- 
Dougal Campbell          | Check out the interQuest home page:
System Administrator     | http://www.iquest.com/
[email-masked]        | interQuest:  "We can hook you up!"

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

From: [email-masked] (Daniel Quinlan)
Subject: Re: IDE Hard Drives w/ over 1024 cylinders
Date: 06 Sep 1994 05:38:54 GMT
Reply-To: [email-masked]

Dougal Campbell <[email-masked]> writes:

> From [email-masked] Sun Aug  7 12:41:48 1994
> Date: Sat, 6 Aug 1994 17:08:54 -0400
> From: "Patrick J. LoPresti" <[email-masked]>
> Reply to: [email-masked]
> To: Dougal Campbell <[email-masked]>
> Subject: Re: Ack!!! Please HELP ME install on Dell Pentium with EIDE drive
>
> ----------------------------------------------------------------------
>                 Everything I Know About Linux and EIDE
>                 --------------------------------------

Ack!  This isn't needed any more.  Linux kernel versions after 1.1.40
(or thereabouts) support EIDE drives directly.

Yggdrasil's Fall revision includes that support.

-- 
Daniel Quinlan  // [email-masked] // "Free software for the rest of us"

In the times of great chaos, and when evil demons ruled the lands, there was a
great revolt.  Several warriors banded together and fought many creatures and
tried to restore peace in the land.  Many great warriors died.  Unfortunately,
all of them died a painful death, and their revolt was a failure.

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

** 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: [email-masked]

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

    Internet: [email-masked]

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