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:     Sat, 3 Sep 94 03:13:10 EDT
Subject:  Linux-Development Digest #109

Linux-Development Digest #109, Volume #2          Sat, 3 Sep 94 03:13:10 EDT

Contents:
  Re: Linux - my first impressions (Warner Losh)
  Re: Linux for DEC Alpha platform? (Donald Becker)
  Installation, Support, Testing [Was: Future of Linux] (Dan Connolly)
  Re: Linux Inside T-Shirts, Now Printing! (pana@phoenix.phoenix.net)
  Re: What on earth is happening to the stabilit (Steve DuChene)
  Re: Does really Linux uses RAM efficiently? Undelete ability? (John Saunders)
  Re: Does really Linux uses RAM efficiently? Undelete ability? (John Saunders)
  Re: Acid (was: Simple ac (Lau)
  Re: Future of linux -- t (Lau)

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

From: imp@boulder.parcplace.com (Warner Losh)
Subject: Re: Linux - my first impressions
Date: Fri, 2 Sep 1994 22:25:44 GMT

In article <345inv$mo6@bmerha64.bnr.ca> Hamish.Macdonald@bnr.ca (Hamish Macdonald) writes:
>Rather than containing code to read partition tables and Linux
>partitions, lilo figures out which disk blocks the kernel file is on,
>and puts the block number data in a place it can find on bootup.

The lilo way of doing it is a hack.  The boot code should know enough
to know where to find the kernel by name, and not by a list of blocks
that may change in the future.  That is LILO's big shortcoming.  Heck,
FreeBSD and NetBSD grok file systems in their boot code and it is nice
to have that.  Lilo does work, until that one time you upgrade your
kernel and forget to run lilo....

The EEPROMS on Solbourne machines can read the boot blocks and the
file system.  The EEPROMs on Sun machines, at least older ones, need
to be told where the bootblocks are.  The Sun's bootblocks understand
the file system.

Warner

-- 
Warner Losh             imp@boulder.parcplace.COM       ParcPlace Boulder
"... but I can't promote you to "Prima Donna" unless you demonstrate a few
 more serious personality disorders"

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

From: becker@cesdis.gsfc.nasa.gov (Donald Becker)
Subject: Re: Linux for DEC Alpha platform?
Date: 3 Sep 1994 00:05:31 -0400

In article <33u1fh$9ej@bmerha64.bnr.ca>,
Hamish Macdonald <Hamish.Macdonald@bnr.ca> wrote:
>>>>>> On 29 Aug 1994 08:14:02 EST,
>>>>>> In message <33smuq$mkq@scotty.waldorf-gmbh.de>,
>>>>>> ralf@resi.waldorf-gmbh.de (Ralf Baechle) wrote:
>
>Ralf> Expect Linux to be available for all major CPU families in the
>Ralf> near future.
>
>Ralf, you and I both know that the big work in a Linux port is not so
>much the CPU specific stuff, but the device drivers.
>
>As such, only expect Linux to work on PC clones (powered by various
>ALPHA, x86, MIPS chips) in the *near* future.

Both the PowerPC/PREP and the Alpha are promoted as using the PCI bus.
Picking the three major devices I consider necessary for a system: disk,
network, and video controllers, I see that x86 Linux is close to supporting
PCI bus versions of all three.  I'm only intimately familiar with network
device driver, but I don't think it would take very long to convert it to a
different processor once I know I knew a few details, such as the I/O space
mapping.  Perhaps most of the changes will be just converting the ASM
in*()/out*() functions to memory operations, and checking for byte-sex
problems.

The remaining essential device drivers to be written are for the
keyboard/mouse port, PCI bus bridge/controller, and perhaps a PCMCIA bus
bridge.  None are trivial, but getting close to having something working is
highly motivating...

-- 
Donald Becker                                     becker@cesdis.gsfc.nasa.gov
USRA-CESDIS, Center of Excellence in Space Data and Information Sciences.
Code 930.5, Goddard Space Flight Center,  Greenbelt, MD.  20771
301-286-0882         http://cesdis.gsfc.nasa.gov/pub/people/becker/whoiam.html

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

From: connolly@hal.com (Dan Connolly)
Subject: Installation, Support, Testing [Was: Future of Linux]
Date: 02 Sep 1994 16:17:39 GMT


There has been a lot of talk about word processors, spreadsheets,
and such.

I am curious to know what the state of the art in installation,
support and testing techniques is.

The stone age:
        grab the 15 parts of the shar file from comp.sources.*,
        splice them together with a text editor, unshar them,
        edit the Makefile, fix the direct/dirent and other
        BSD/sysVisms, do "make install," add something to
        everybody's $PATH, edit a few ~/.foo files, and you'r
        all set. If you have root privilege, install it
        in /usr/local/*

        Upgrading: download the patch, apply it, rebuild, make
        intall again; hope that there are no obsolete files
        lying around in places.

        Support: Read the FAQ, troll the archives,
        mail the developers, post to USENET.

A little evolution:
        surf for a while with xarchie, xgopher, Mosaic, etc., find
        the .tar.gz file, download it, and unpack it.
        Run ./config or imake, and if you're using a sun4 or a few
        other supported platforms, you're in luck. make install,
        change $PATH, edit ~/.foo, and you're done.

Binary distributions:
        Surf as above. Locate binary distribution for your machine,
        with the right combination of compile-time switches for
        debugging, security, SOCKS, term, etc. Hope it's got a PGP
        signature from somebody you know.
        Install in /usr/local, send mail to your local consituency
        telling them about the new app and where the documentation
        lives.

        Support: FAQ, email, USENET, plus perhaps evolving online
        documentation via WWW.

Consumer Technology:
        Pay money.
        Open the package. Stick the "Install" disk in the floppy
        drive. Double-click the icon that shows up on the desktop.
        Double-click the README file if you're curious, or just
        double-click the "INSTALL" icon. Choose an installation
        destination. Follow the instructions
        about inserting other diskettes. Double-click the app icon.
        Open the "preferences" dialog. Save your configuration. Done.

        Support: call long distance, call 1-800, FAX, BBS, Compu$erve.

        (I've never seen _any_ UNIX platform with software installation
        that I'd call "consumer technology". But then I haven't dealt
        with SVR4 packages much. AIX's strategy is well-intentioned,
        but in practice, it's a nightmare. Perhaps it will mature.)

What I'd like to see:
        Identify the programs/products/projects that might do the
        job. (Using archie, WWW, USENET news, mail, etc.)

        Locate the relavent "lsm" entries (or whatever. Perhaps
        it's the holy-grail URC that the URI WG is discussing...)
        Choose between:
                full development source
                full documentation source (TeX, TeXinfo, SGML, nroff, ...)
                pre-built documentation (ASCII, postscript, gnu info)
                binaries for platform x/y/z, compile-time options a/b/c
                contributed options
        Submit the completed form (via e-mail or via HTTP POST with,
        for example, Mosaic or super-FTP).
        The compressed archives come back (via email (using MIME
        base64 encoding and message/partial, with automatic reassembly),
        or via HTTP or some super-FTP server).

        (The above form transaction could happen locally if the
        archives are distributed on CD-ROM, for example)

        For binaries, you can install them on a :
                per-user basis, in ~/...
                per-group basis, in /some/dir/shared/by/the/group
                per-host basis, in /usr/local (or /opt, or ...)
                per-site basis, in /some/nfs/exported/dir
                                or /some/afs/exported/dir

        Also, you can install it on a per-user basis, test it out,
        and then promote it to a per-group, per-host, or per-site
        installation without a lot of pain.

        The applications should support online hypertext help,
        (how do we integrate this with man/whatis?)
        with some FAQ, and a pointer to the home of the up-to-date FAQ,
        and an automated problem reporting facility that searches
        out the relavent configuration information, recent errors,
        etc., and allows the user to edit a description. The problem
        gets mailed to the relavent developers and/or mailing lists.
        An associated gnats-style database is available for browsing.

        A regression test suite would allow binary distribution customers
        to test their installations. And it would allow developers
        who port to other platforms to check their work. (And folks
        who provide patches...). Even a minimal "sanity check" test suite
        would provide a lot of warm fuzzies. And eventually, the
        test suite would grow...

So I'm curious:

        Is there a regression suite that the Linux developers will
        use to qualify the 1.2 release? How do we know that new
        developments haven't re-introduced old bugs? Or do we believe
        it's more cost-effective to just release it and fix the
        remaining problems in 1.2.x patch releases? (a distinct
        possibility)

        As the number of combinations and permutations of kernel configuration
        options, hardware configurations, and (soon) processor options
        increases, I believe it will become cost-effective to
        maintain regression test suites. (Yes, I'm willing to do my
        part... eventually. No time to contribute just now.)

        Are the various companies offering tech-support for Linux
        maintaing problem reporting databases? Any chance these
        databases can be shared between companies? Shared with
        the community? Do they use gnats?

        Does anybody know how software installation works in the
        proposed COSE standard? I'm encouraged by the evolution of
        support for iBCS and ELF binaries. Linux has benefitted greatly
        from the fact that gnu software adheres to and supports the
        POSIX standards. I think that -- in many cases -- support
        of existing standards and practices will grow the Linux
        applications base and hence the customer base and hence
        the developer base and ...

Dan



--
Daniel W. Connolly        "We believe in the interconnectedness of all things"
Software Engineer, Hal Software Systems, OLIAS project   (512) 834-9962 x5010
<connolly@hal.com>                   http://www.hal.com/%7Econnolly/index.html

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

From: pana@phoenix.phoenix.net
Crossposted-To: comp.os.linux.misc,comp.os.linux.help,comp.os.linux.admin,aus.computers.linux,alt.os.linux,alt.linux.sux
Subject: Re: Linux Inside T-Shirts, Now Printing!
Date: Sat, 03 Sep 94 00:29:19 PDT


In article <348pgt$if@Venus.mcs.com>, <daver@MCS.COM> writes:
> Path: 
dolphin.phoenix.net!news.sprintlink.net!redstone.interpath.net!dds
w1!not-for-mail
> From: daver@MCS.COM (Dave Rossow)
> Newsgroups: 
aus.computers.linux,alt.linux.sux,alt.os.linux,comp.os.linux.admin
,comp.os.linux.development,comp.os.linux.help,comp.os.linux.misc
> Subject: Re: Linux Inside T-Shirts, Now Printing!
> Date: 2 Sep 1994 22:11:25 -0500
> Organization: MCSNet Services
> Lines: 15
> Message-ID: <348pgt$if@Venus.mcs.com>
> References: <33q3co$q0l@garion.it.com.au> <CvAy09.BB3@dfw.net>
> NNTP-Posting-Host: venus.mcs.com
> Xref: dolphin.phoenix.net aus.computers.linux:1320 
alt.os.linux:208 comp.os.linux.admin:14185 
comp.os.linux.development:15558 comp.os.linux.help:55264 
comp.os.linux.misc:25362
> 
> jhs@dfw.net (Justin Scott) writes:
> 
> 
> >Any type of JPEGs, etc we can see of the shirts before we 
order?
> 
> >I would love to have the "Linux Inside" as will as the "GNU 
Generation" 
> >shirts, but only if I can see pics before purchase
> 
> >Justin
> 
> Likewise!
> 
>       dave
>       daver@mcs.com
> 
Yep same here.
Chuck

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

From: s0017210@cc.ysu.edu (Steve DuChene)
Subject: Re: What on earth is happening to the stabilit
Date: 1 Sep 1994 09:35:08 GMT

        Apparently there are some problems with floppy formatting/e2fsck
        on certain kinds of floppy drives (those that report as the following
        at bootup: FDC 0 is a post-1991 82077) causing some corruption in
        data written to a floppy when running with some new kernels (1.1.4*).
        If you don't have a floppy drive that has this characteristic you won't 
        see any of these problems. "So lets be careful out there"
-- 
| Steven A. DuChene   sduchene@cis.ysu.edu  or  s0017210@cc.ysu.edu      
| Youngstown State University  | Computer Science / Math / Mech. Eng.
|They all laughed at Albert Einstein. They all laughed at Columbus. 
|Unfortunately, they also all laughed at Bozo the Clown. 

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

From: john@odin.apana.org.au (John Saunders)
Subject: Re: Does really Linux uses RAM efficiently? Undelete ability?
Date: Wed, 31 Aug 1994 13:51:53 GMT

Anthony J. Stuckey (stuckey@mrcnext.cso.uiuc.edu) wrote:

>       You can.  Or you can make a file system that takes a useful strategy
> towards block re-use.  It's not hard to place newly-freed blocks at the
                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> *END* of the free-list, for instance.  It's my understanding, though, that
  ^^^^^^^^^^^^^^^^^^^^^^
> strategies like this lead to fragmentation and performance loss.

How would this work with bit maps? With a bitmap filesystem design, any
concept of order is lost. Once a block is freed it becomes part of the
pool. With a list design you can put recently freed blocks at the end of
the free list.

However adding a list to what is already a bitmap filesystem would make
the overhead, both space and time, too large (at least for me).

I think that any filesystem that supports undelete must be designed
with this facility from the start. A simple patch to the current ext2
filesystem is asking for problems.
-- 
--     .   +----------------------------------------------+
   ,-._|\  | John SAUNDERS - Home  john@odin.apana.org.au |
  /  OZ  \ |               - Work  johns@rd.scitec.com.au |
  \_.-\__/ | "Mmmmmmmm beer..." - Homer Simpson           |
        v  +----------------------------------------------+

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

From: john@odin.apana.org.au (John Saunders)
Subject: Re: Does really Linux uses RAM efficiently? Undelete ability?
Date: Wed, 31 Aug 1994 14:00:14 GMT

Anthony W. Kay (tkay@crl.com) wrote:

> Undelete is a feature you can build on by replacing the rm command with
> a program that moves the file to some sort of "trashcan (a directory
> like /tmp)". Then write a program (call it unrm if you wish), that 
> searches the "trashcan", and moves the file(s) back.  Remember to add
> a program to your crontab that "times out" these files and actually
> removes them. (you might also add a rmtrash command).

One idea would be to have a "disk space" daemon that periodically checks
the disk free space. When it finds resources becoming low it starts
deleting the the oldest "deleted file". If you wan't to get fancy you
could have the file system sending messages to the daemon for example,
"out of space" or "running low", etc. This would mean the daemon wouldn't
use resources by polling the free space. The daemon could also remove
files after a certain time period. The options are limitless.

The point is with Linux (or Unix) there are lots of ways to to things.
Sometimes adding bloat to the kernel isn't the best way.

Just think, if we need undelete added to every filesystem type we could
be booting 1 Meg kernels before long, like some of the other Unix's.
-- 
--     .   +----------------------------------------------+
   ,-._|\  | John SAUNDERS - Home  john@odin.apana.org.au |
  /  OZ  \ |               - Work  johns@rd.scitec.com.au |
  \_.-\__/ | "Mmmmmmmm beer..." - Homer Simpson           |
        v  +----------------------------------------------+

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

From: gabe@io.org (Lau)
Subject: Re: Acid (was: Simple ac
Date: 3 Sep 1994 00:19:30 -0400

To: goer@quads.uchicago.edu
On 09/02/94, Was: wrote:                      

>Subject: Re: Acid (was: Simple acid test)
>
>>>> A simple test of true multilinguality is this:  Can you mix languages 
>>>> inside the application in question - languages with drastically different
>>>> scripts.  And can you do it in arbitrary spots...
>>>
>>>MULE does this.  Do your DOS applications support this *and* multiple
>>>input methods?
>>>
>>I must point out that those awful glorified terminal Macintoshes have
>>multiple language support built into the operating system.
>
>Right.  So you don't need to graft on all of these ridiculous hacks to
>get nice multilingual software like Nisus.  I'm constantly frustrated
>by Unix developers who tell me their product is fully internationalized,
>only to find that it's, at best, hacked for a language here or there.
>They nearly always fail my simple acid test, namely let me quote Shakes-
>peare and the Quran in the same paragraph or message.  Typically what
>they mean when they say "internationalized" is "capable of being local-
>ized to support a language other than English."
    
    Yes, MULE and other XTerms will do this...not sure about Arabic but 
Chinese, Japanese, Korean and Cyrillic is supported.  Meaning you can have 
multiple languages all in the same sentence (assuming the codes don't 
clash, see below).
>
>Being an American, I realize that it's hard for us to understand a
>multilingual environment like India, Canada, much of Russia, etc.; or
>a culture like Iran or Turkey, where Arabic has a certain standing as
>a religious language, though the populace speaks a non-Semitic vernacu-
>lar.  What I don't understand is why foreign markets are putting up
>with the whole mess by permitting single-language localizations.  If
>everyone just said, "Give me a fully internationalized OS that sup-
>ports wide characters and has a script manager built into the GUI,"
>then, well, a lot of goons would be out of work.  But we'd be that
>much closer to Nirvana.
    
    You are completely missing out on what makes a internationalize OS so 
hard to make.  There are already hundreds of standard formats for different 
languages,  Chinese alone has at least dozen different coding schemes and 
50 different methods of input...in other words, its not that easy to 
determine what coding to use, since most of them clash.  The same sequence 
of bytes used to represent one word/character in one language will mean 
something totally different in another...how can you tell.
>
>Incidentally, what is this Mule?  Is this a truly internationalized
>product, or a hack to get the OS to work with some specific non-western
>language like Japanese?
    
    While MULE was principly developed in Japan, it can handle various 
coding schemes for different languages assuming they can coexist.
    
    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?
    
    Kin Lau (gabe@io.org)
    

---
* UniQWK v3.0 * The Windows Mail Reader
                                                                                                  

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

From: gabe@io.org (Lau)
Subject: Re: Future of linux -- t
Date: 3 Sep 1994 00:19:36 -0400

To: pyeatt@cervesa.cs.colostate.edu
On 09/02/94, Larry wrote:                     
>In article <346dki$g5d@news.u.washington.edu>, 
mike@wavelet.apl.washington.edu (Mike Kenney) writes:
>|> In article <3456g5$1ekr@yuma.acns.colostate.edu>,
>|> Larry Pyeatt <pyeatt@CS.ColoState.EDU> wrote:
>|> >
>|> >Compare the price/performance of processors and Intel comes out to
>|> >make the worst processors in existence.  PowerPC chips provide twice
>|> 
>|> I have to disagree here.  The price/performance of a Pentium PC is
>|> quite good (especially if you're running Linux :-).  
>
>You are talking at the system level.  I was talking at the processor level.
>What makes Pentium SYSTEMS cost effective is:
>1) volume and vendor independence
>2) Pentium systems in general:
>a) have lower resolution/slower video hardware
>b) have smaller hard disks
>c) have less RAM
    
    If you're running RISC, you NEED more RAM and STORAGE simply because 
the same C code when compiled is going to be 30% large on the RISC than on 
the Pentium.
>
>Do not confuse processor with system.  The Power Macintosh
>uses a totally new and different processor from any of its
>predecessors and yet runs the SAME software and OS, and
>delivers much greater price/performance.  The same can be
>done with the IBM style PC, although vendor independence 
>may turn out to be a hindrance.
    
    No, the Power Mac is not any faster w/ the SAME software & OS.  It's 
slower until native PPC apps available.
>
>Configure a Pentium system which is identical to an SGI
>Indy and they will have very similar price/performance,
>even though the Pentium PROCESSOR is more expensive
>than the MIPS processor.
>
>Here is a Pentium Machine which is configured similar to a
>$6500 Indy:
>
>99MhZ Pentium PCI bus motherboard      $2500 ???     $1500CDN ($1000US)
>32Meg RAM                              $1000 OK
>#9 GXE Level 12 video card             $ 500 OK
>ViewSonic 17 Monitor                   $1000   what? $1000CDN ($700US)
>Keyboard, 1.44M floppy, mouse, serial  $ 300   These three look more like
>400Meg SCSI disk                       $ 350   Canadian prices (40% exchange)
>BusLogic SCSI controller               $ 350 Crazy, the PCI NCR is only $100
>Soundblaster                           $ 100 ok
>Case and Power Supply                  $ 100 ok
>Ethernet adaptor                       $ 200 Huh?  Less than $100-
>CCD camera                             $ ???
>Operating system                       $ ???
>                                       -----
>                                       $6400 minumum <- wildly overestimated
>
>Note that, at the price shown, the PC will not do full motion video or
>capture images, nor will it be as fast overall as the SGI.
    
    Time to check back w/ your suppliers.
    
    Kin Lau (gabe@io.org)
    
---
* UniQWK v3.0 * The Windows Mail Reader
                                                                             

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


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