Files
oldlinux-files/ftp-archives/tsx-11.mit.edu/1996-10-07/mail-archive/linux-devel/Volume2/digest109
2024-02-19 00:24:15 -05:00

546 lines
23 KiB
Plaintext

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