Linux-Development-Sys Digest #778, Volume #6 Fri, 4 Jun 99 15:14:29 EDT
Contents:
Re: the ultimate OS ("Tim Doffing")
Booting 2.2.9 problems ("Robert Williams")
Re: RAID-1 and 5 broken in 2.2.9? (bill davidsen)
Re: TAO: the ultimate OS (Jeremy Crabtree)
Block devices / drivers ("Tamas Rudnai")
Re: select() vs. poll() ("G. Sumner Hayes")
Re: the ultimate OS (Vladimir Z. Nuri)
Re: TAO: the ultimate OS ("G. Sumner Hayes")
Re: TAO: the ultimate OS ("G. Sumner Hayes")
Re: 2.2.9 kernel too big? (IanP)
Re: TAO: the ultimate OS (Vladimir Z. Nuri)
----------------------------------------------------------------------------
Reply-To: "Tim Doffing" <[EMAIL PROTECTED]>
From: "Tim Doffing" <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: the ultimate OS
Date: Fri, 4 Jun 1999 11:25:08 -0500
Vladimir Z. Nuri <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Tim Doffing ([EMAIL PROTECTED]) wrote:
> : Blah, blah, blah. I intend on inventing cold fusion, and a pill that
will
> : extend your life indefinitely. No Code=No OS. We all have dreams!
>
> the tiresome hacker position/canard/harangue that without code, you
> have nothing. "design is bull****" .. which btw I have some
> sympathy for.
It looks as if your post has generated allot of traffic. I think this
demonstrates the degree of frustration we all feel with modern operating
systems. None of them work the way we work, or think others should work. We
all have the vision of what the perfect OS would be, which is the one that
would suit our individual needs the best. If I sat down today and composed
an "OS Manifesto", I would expect that many of the elements in that document
would echo some of the design concepts in your document, and we would differ
in some areas. The areas of difference is where most debate occurs, as this
is where I would like the OS to compliment the way I work and think.
> excuse me, but I am both a hacker & a designer. and sometimes
> design logically comes before hacking. want to overtake win95?
> you have to have a vision. you can't just keep writing code
> blindly.
I too have written a design template to code my own OS from. It is based
on many other kernal ideas that have been proven effective over time. I
believe that planning and design are critical to the outcome of a successful
coding project, no matter what it is. You need a map to get where you are
going. I think we would all like to see Windows products fall back to the
areas where they belong, instead of spread around for lack of a better
choice.
> I agree, writing code is hard work, and writing design is less
> difficult. but there are many hackers with no vision. arguably
> linux has very little vision. what is it, a copy of a
> OS that existed two decades ago? you want "world domination"?
> you think that you will get there by endlessly tweaking the
> performance of the kernel?
I do agree with you somewhat on Linux. I fully support the open source
movement. I also believe that in order to be a competitor in the commercial
software arena, you must adopt commercial software development practices.
(Now that I am securely within my flame-proof suit). In order to adopt these
practices, the open software movement would effectively have to sell it's
soul to Microsoft. This is why I believe that although important, it is not
the solution for putting Windows in its place. I would like to see the open
software stay where it is, grassroots cutting edge development for the
masses. Many people working together to devise better ways of doing things.
I equate this most other technologies out there. You look at colleges, they
have allot of cutting edge breakthroughs, but no commercial interests.
(Aside from the funding dependencies). The technology is out there for
implementation and improvement. They share their information with other
colleges, and businesses. In the business environment, it is refined and
repackaged as a consumer product.
I'm going to cut myself off at this point, as I could go on and on about
this. Just remember...
--
I welcome and respect all opinions,
I don't however, agree with all of them.
------------------------------
From: "Robert Williams" <[EMAIL PROTECTED]>
Subject: Booting 2.2.9 problems
Date: Fri, 4 Jun 1999 10:50:46 -0600
I just downloaded kernel 2.2.9 and compiled it. But now I can not get COL
2.2 to boot from the HD. I created a boot disk with 'make zdisk' and the
machine boots fine from floppy. I ran lilo -v to make sure that the MBR was
set and it appears to have been.
Is it possible to transfer the boot sector from floppy to the HD?
Please help.
--
--
Robert Williams [EMAIL PROTECTED]
Jarob Consulting [EMAIL PROTECTED]
Provo, Utah
------------------------------
From: [EMAIL PROTECTED] (bill davidsen)
Subject: Re: RAID-1 and 5 broken in 2.2.9?
Date: 4 Jun 1999 16:24:04 GMT
In article <[EMAIL PROTECTED]>, Az0th <[EMAIL PROTECTED]> wrote:
| Hi Bill,
|
| : I guess the answer is that the RAID-[145] stuff in the 2.2.9 kernel
| : doesn't work at all with anything any more (why is it there?). The md
| : stuff got broken somewhere along the line, and the raidtools stuff only
| : works after adding about 200k worth of patches (not a typo), and those
| : are alpha and only available for a few kernels, 2.0.36 and 2.2.6.
|
| : Shame to see stuff which worked broken.
|
| The good news is: what works, works better now than it ever did before,
| if you can stand to use a 2.2.6/7 kernel (efficient, threaded resync is
| a wonder to behold.)
I appreciate your reply and your candor, but the problem is that what
works appears to be absolutely nothing, at least if you want any
redundancy from RAID-[145]. I really need only a few GB mirrored, and
was hoping to use bits of a few more robust drives, but I think I see
hardware RAID coming.
I will test 2.0.36 and see if memory serves that RAID-1 worked there, I
can throw together a file server if it does.
It sounds like we are about a year from working RAID (six months after
all known bugs are fixed is about right for a critical system). I'm not
complaining, I just want to be realistic.
When software RAID is really in I will have a great test case, a
database with high read load. I want to try no mirror, one mirror and
two mirror. In proper RAID-1 the mirror drives will be used when the
primary is busy as well as when it fails.
Of course I will try pulling a drive and checking for stability,
rebuild on the spare, etc. I have a hardware RAID which rebuilds on the
spare, then copies back to the failed drive when it is replaced. It
sure would be nice to have an option to just make the replaced drive
the spare (not desirable default behavior in my mind, but useful).
One more issue (I should join the list!), it is past time for /proc to
handle more than four drives gracefully. I would really like stats on
all drives and a way to know which values go with what physical devices.
I hope that can go into 2.3, I hope it does NOT go in 2.2, I really
believe in stable meaning no new features.
I am dropping this topic, thanks to all who posted and mailed. I really
think that 2.0 md or hardware RAID is the way to go for production
machines.
--
bill davidsen <[EMAIL PROTECTED]> CTO, TMR Associates, Inc
The Internet is not the fountain of youth, but some days it feels like
the fountain of immaturity.
------------------------------
From: [EMAIL PROTECTED] (Jeremy Crabtree)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: 4 Jun 1999 17:27:32 GMT
Reply-To: [EMAIL PROTECTED]
Keith Peterson allegedly wrote:
>>Where is your code? Talk is cheap - unless you can demonstrate a code your
>>words are worth nothing. Sorry, but you sound like a cross between manager
>and
>>salesweasel and those animals are, erm, not too good in producing things.
>>Write something that would work and demonstrate it.
>
>
>Geez... and, "When project X is done, it'll be terrific!" isn't the rallying
>cry of most linux projects?
Difference being, those project almost always have ACTUAL CODE to back
them up.
--
"Being myself a remarkably stupid fellow, I have had to unteach myself
the difficulties, and now beg to present to my fellow fools the parts
that are not hard" --Silvanus P. Thompson, from "Calculus Made Easy."
------------------------------
From: "Tamas Rudnai" <[EMAIL PROTECTED]>
Subject: Block devices / drivers
Date: Fri, 4 Jun 1999 18:35:01 +0100
Hi,
Do you know how can I ask a list about all _active_ blockdevices from the
kernel? I mean all drivers wich compiled directly to the kernel or to a
module but only those block devices, which are present (for example if a
system has an EIDE driver, but only one IDE interface is installed and only
one drive is installed to that interface, I would like to know only that
drive only, but if a special CD-ROM drive is attached to the system [e.g. 2x
speed Panasonic -- sbpcd] I would like to know about it as well). I do not
want to try to open every device from /dev (as fdisk do), and I do not want
to parse /proc/devices file, because I am not sure, that all Linux
installation offers me this file, and it's does not contain all information
I need.
There is a block device driver list within the kernel (gendisk_head), which
would be useful, but I can not access it from a normal application (or can
I?). It also contains some useful information, such as the shift count
number for the Major/Minor numbers -- that also I would like to ask from the
system.
So, any ideas?
Thanks, Tamas
------------------------------
From: "G. Sumner Hayes" <[EMAIL PROTECTED]>
Subject: Re: select() vs. poll()
Date: Fri, 04 Jun 1999 13:30:10 -0400
[EMAIL PROTECTED] wrote:
> I was wondering what is the practical difference between the functions
> 'select()' and 'poll()'? I've used the former quite a lot, but stumbled
> over the latter today. poll() seems to have entered Linux quite
> recently, and I think the interface it provides is nicer then select().
poll() has been around at least since 1.3.x kernels, so for a few
years anyway.
> Is there something I should be aware of if I intend to use poll()
> instead of select()? Performance?
poll() is moderately more efficient than select() on Linux.
> Thread-safety (I use threads)? Stability?
Both are thread safe and stable. select() is somewhat more portable.
If performance with large numbers of fds is important then you
probably want to use autoconf to check for poll() and use it if
possible; otherwise go with select(). Neither is highly scalable,
so schemes that fork multiple process and divide up fds between them
are used in large servers. The real-time queued I/O completion
signals available in Linux 2.2 with glibc 2.1 are an effort to
improve matters. Richard Gooch has some patches to old kernels that
can increase poll/select performance by a factor of 3 or more in case
you can't change to use the signals -- I believe they're planned for
inclusion in the 2.3.x development series of kernels.
Thread safety is there, but efficiency in SMP setups is not. All
processes that are polling (or selecting) on an fd are woken when
it's available -- that can lead to a thundering herds problem if
you have a ton of processes polling on one fd (common in some thread
models). The wake-one accept() in the early 2.3.x kernels is there
to help deal with this, and further wake-one semantics are planned
for other interfaces in the 2.3.x kernels.
select() on linux (since 2.0.x) is implemented as a wrapper around
poll(). So if poll is broken then select is broken, but the
converse is not necessarily true. And select obviously can't be
more efficient than poll.
In older (some 1.3.x, possibly 1.2.x and earlier) Linux kernels,
poll() was a wrapper around select(). This was inefficient and I'm
not sure it was possible to get the semantics right.
--Sumner
------------------------------
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
From: [EMAIL PROTECTED] (Vladimir Z. Nuri)
Subject: Re: the ultimate OS
Date: Fri, 4 Jun 1999 01:35:51 GMT
G. Sumner Hayes ([EMAIL PROTECTED]) wrote:
: The problem, though, is that we see a new design for a new ultimate
: OS here every 3 months or so. They're often nearly identical to
: what you propose. Almost none of them go on to write a single line
: of code, and not a single one has reached the "usable OS" state, let
: alone even come close to a "as good as MS-DOS" state (yikes!).
hmmm, maybe it makes sense to ignore people like that.
: Enough people have cried wolf that we're tired of hearing it. We
: obviously can't jump on board a new OS every 3 months and expect to
: get somewhere, so you need to convince people that your design is
: workable, better than what exists, better than the last 20 proposals,
: and will actually get done. You don't need mathematical proof of
: that, but you do need to convince enough developers that they want
: to work with you. The best way to do that is to show them the code.
: If you want to try to do it by proposing design documents, that's
: fine -- just don't be surprised when they ignore you.
"cry wolf"? give me a break.
I am not proposing rewriting an OS from scratch; I'm suggesting
a new point B that is different from where we are at, point A,
and a rough way to get there a bit at a time. I'm building
memes, not code. memes are the source of all code, no matter
how much supposedly "manly" hackers wish to deny/obfuscate
this issue.
I am prepared to be ignored. in fact I posted this identical
essay perhaps 6 months ago with far less response. in fact I think
I handle rejection quite well.. I am patient and can wait
for the world to catch up<g>
: Aside: If you want to use design documents to convince people, you'll
: need to demonstrate a firm understanding of the field. Your paper
: doesn't address a lot of problems that object-system researchers
: encountered and solved 5-15 years ago -- that doesn't instill
: confidence in the design. There are a ton of great papers out there
: on the subject, and you really should read at least the surveys and
: some of the in-depth ones before you try to jump in and design an
: object system.
I challenge you to name a single OO problem the essay glosses over.
and btw, if they were solved, then whats the "problem"??
--
~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
"in theory, there's no difference [EMAIL PROTECTED]
between theory and practice, mad genius research lab
but in practice there is!" http://www8.pair.com/mnajtiv/
------------------------------
From: "G. Sumner Hayes" <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: Fri, 04 Jun 1999 13:17:25 -0400
Keith Peterson wrote:
> Geez... and, "When project X is done, it'll be terrific!" isn't the
> rallying cry of most linux projects?
But there's a _start_ to project X, which gives people something to
work with and a framework in which to evaluate the general approach.
If you're into Internet anthropology, Eric Raymond has a paper
discussing how open development works -- one key point he makes is
that you have to start with enough code to get people excited before
you start the "release early and often" cycle.
I can remember exactly one project (KDE) that started with a post
to Usenet proposing an idea with no code that actually ever got
any serious development. And that was because the one who posted it
got "show us the code" flames and went and did it.
--Sumner
------------------------------
From: "G. Sumner Hayes" <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: Fri, 04 Jun 1999 13:34:42 -0400
Larry Blanchard wrote:
> I've seen a fairly large body of opinion that holds that the usefulness
> of OOP is in direct porportion to the percentage of user interface
> code. In other words, an inverse relationship to the percentage of
> internal calculations.
A lot of modern research doesn't even grant that, assuming a
simplistic definition of OOP. Associating code and data tends
to limit you to a single view of your data, precisely the sort
of problem you want to avoid in a good UI. Of course, the
definition of OOP has evolved to the point where some OOP
models don't have that sort of issue. If you're talking about
C++, those models generally don't agree with the language's ideas --
but the C++ model is useful for some elements within the UI.
--Sumner
------------------------------
From: IanP <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.setup
Subject: Re: 2.2.9 kernel too big?
Date: Fri, 4 Jun 1999 13:58:22 +1000
LILO was complaining that my newly compiled 2.2.2 kernel was too big even
with "make bzimage". After searching for some help I found "make bzlilo",
problem fixed. I don't know if its the same problem but I hope it helps.
Ian
On Wed, 26 May 1999, Naz Irizarry wrote:
> I get the same message on a 2.2.9 build on a zImage that is about 20%
> smaller than the RedHat 6.0 vmlinuz. ??
>
> Amaury JACQUOT wrote:
> >
> > bzimage is not bzip'ed but big zimage
> > you need to remove stuff from the kernel and compile as modules whatever
> > is not needed
> > to boot the system (think of parport zip drivers and the like)
> >
> > [EMAIL PROTECTED] wrote:
> > >
> > > has anyone else had problems with the 2.2.9 kernel refusing to compile
> > > on an x86 redhat 6.0 box when using "make bzImage"?
> > >
>
>
------------------------------
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
From: [EMAIL PROTECTED] (Vladimir Z. Nuri)
Subject: Re: TAO: the ultimate OS
Date: Fri, 4 Jun 1999 03:54:03 GMT
ross reaffirms the idea that linux is "pasted together" and lacks
an overall vision/philosophy.
I respect the work done on linux by people here and others. I have used
linux since 96 or so and am eternally grateful to all the contributors.
yes, perhaps new proposals are tedious and tiresome, but another
interpretation is possible: the linux community does not have
a vision, and has difficulty integrating a vision, perhaps has
a blind spot about a vision, therefore
many competing visions are posted regularly.
btw, I respect torvalds, but.. what is the vision for Linux?
support for parallel processing? ok, ok, great, but come on.
is linux trying to make it into the mainstream?
btw, I don't know if a new OS may have to defy linux founders.. I
can see it as possible. it is entirely possible that linux will
someday be eclipsed by something different enough that it doesnt
even resemble it anymore.
ok,ok, "ultimate" is not a great word to use in the essay, it
pushes some buttons. but surely there is a way to have a "way-cool"
OS even better than what we have now. it surprises me how
"ludditish" some of the most forward thinking individuals can
be within their won boxes.
ross nails the problem of trying to get the hardware people
to cooperate with the software people. imho this has been
very poorly done to date with existing OSes because of an
often adversarial relationship between MS and partners. but
I guarantee it-- some day there will be a robust open device
interface standard. we will get there.
as for bugs, the whole point of the essay is that a truly
great OS can actually tolerate bugs in a pretty seamless/sophisticated
fashion. getting rid of bugs is an impossible task. creating
an OS that acknowledges this and runs with it is an
exciting new possibility/paradigm. again, remember, "sandboxes
within sandboxes".. we can build software with its own
firewalls built in, in multiple layers.
perhaps what I am proposing is not an OS but something
bigger than an OS, i.e. the next level of abstraction. I don't
really care what the low level details are.
part of the essay is suggesting the OS can be made more efficient
by revisiting the idea of the compiler. it seems to me that
the compiler is actually a basic part of the OS, and when this
concept is fully realized by the development community, far more
powerful/efficient OSes can be created.
right now everything is seen in fragments. but there is some
kind of unifying framework dying to be born, I can feel it.
Ross can feel it too, thanks Ross<g>
: This reply turned out to be longer than I planned. Here is a summary:
: 1) You had some good points
: 2) Sorry Alexander was so rude
: 3) Why I think he made those remarks
: 4) Projects that might tie-in
: I have read through you article posted to comp.os.linux.development.system.
: I agree with most of your ideas. Especially the "philosophy" stuff, that is
: one thing that people tend to forget, so the system starts to feel like
: something that has been taped together from parts rather than being the
: simple, clean, and obvious way of doing things. Many supporting statements,
: examples, and the absolute tone are places where I didn't agree as much.
: I also read the reply from A. Viro. He does a lot of nice clean work on the
: Linux kernel so I was surprised to hear him be so rude. That is a response
: that I have seen some of the Linux hackers like Alan Cox and Dave Miller use
: before. I think they do it when they don't expect a project to go anywhere
: and want to stop the (likely cascading out of control) discussion in what
: might be an improper forum. I guess he is right that there is no code... but
: things have to start somewhere, and coding isn't usually the best place. It
: would have more validity if this had been around as a project and essays
: were all it was producing. There is some still logic to his argument,
: though, especially when you consider the how well many of the Linux
: developers use code as a primary means of communication.
: I can also understand how he might categorize you this way. Many, many
: people have posted "designs", or "plans", or calls for volunteers on what
: basically boil down to wish lists. Many of these lists are not even self-
: consistent. I do, however, believe that there is the real "essence" to your
: essay which shouldn't be
: It may have come across that way because you used pie-in-the-sky words like
: "ultimate", buzzwords like "plug-and-play" (which have a natural meaning and
: a "tainted" meaning), and phrased statements about the system as if it
: already existed:
: In Tao the installation process and deinstallation process of any
: component is absolutely foolproof. Often in Win95, errors arise during
: installation or de-installation that leave the entire system in a
: "half-baked" state. In Tao there are no prompts at either installation
: or deinstallation, the entire process is always completed as a whole
: without further interruption.
: This is a great _goal_; it should probably be phrased as such. Many people
: are picky about phrasing and factuality (including me). I often like to
: play "the devil's advocate" both in my mind and out loud. It is easy to
: think of situations where it is impossible to guarantee this:
: * poorly designed hardware
: * unsupported hardware
: * software bug
: * hardware failure
: You may argue that the hardware must be redesigned. I don't know how
: realistic that is. It is very hard for MS to get hardware vendors to do
: things their way... so why would they listen to some startup OS?
: You may argue that all hardware may be supported by the vender, but that is
: also not realistic. Often Windows NT drivers don't come out for hardware
: until well after it has been released.
: I don't see how you can argue against the existence of bugs :)
: Hardware may be made redundant but there is always a chance.
: Nothing can be perfect or completely foolproof have any significant amount
: of complexity. Usability, flexibility, and being foolproof are not mutually
: exclusive, but they are not orthogonal either.
: Well, I don't mean to dwell in little details. I have made many statements
: like yours, but mostly talking to my friends and not on Usenet. We like to
: talk about how we would like things to be. We have hashed out plans for:
: * An object/component architecture which is very focused on interfaces.
: (But not horribly implemented like COM). We have been trying to figure
: out nice ways to make it network-transparent with minimal impact on
: use of pointers/references.
: * A nice object oriented language (basically SmallTalk like in philosophy,
: C-like in syntax, and very clean unlike C++)
: * A rendering engine that is scary to talk about... it would be able to do
: things like polarization, interference patterns, fluoresce, etc. Very
: object oriented.
: * A Linux distribution with our own shell, window manager, and many apps.
: One of my friends is very inspired by BeOS and MacOS. He does see the
: fundamental simplicity in Unix as well as the resulting reliability and
: power. We would like to combine all these features.
: * Plans for devising a license agreement to create small groups of people
: who work on projects together. Similar to a company. This thinking was
: partially inspired by http://www.elj.com/lss/lss.html
: * Lots more :)
: Our component architecture philosophy is very similar to the philosophy in
: your Tao OS. We continually fought with the idea that it should be an OS or
: not. We decided that it was best for it not to be. The reasoning was
: something like this:
: * object orientation is the best method we have for dealing with
: complexity because it is the most complete form of abstraction
: * software is too monolithic to be easily modified, and without
: source code, all a user can do is modify settings
: * both Apple and MS had ideas on how to fix it
: * Apple made OpenDoc and their publications said all the right things,
: but when it came down to the actual product, it was really not at
: all flexible (basically nested rectangles like OLE)
: * MS came up with COM which also said some good things (it stressed
: the idea of the interface), but it was really a low-level
: standard (even though they claim it is ultra-portable, it depends
: on the vtable format used by the compiler)
: * one problem with a whole sea of objects is that the complexity
: hasn't really gone away... it moved into the interactions
: between the objects
: * oh wait... structured programming had a solution for that already,
: why do people forget to use it: layering
: * by defining a narrow interface between groups of objects, you
: get extra abstraction, like the Unix "everything's a file"
: philosophy where program interaction with the kernel boils
: down to read() and write(). (bad example though, with ioctl(),
: sockets, IPC, etc, the number of system calls keeps growing...)
: * so why don't we break our component architecture into layers
: * oh wait... the bottom layer is what the OS is doing already
: We were basically going to just use the OS for drivers, scheduling, and
: resource allocation. We would abstract off everything else in our lowest
: layer so that all other components would see nothing but components.
: I understand that your project is more ambitious: you would like to change
: the way even drivers work. But really, we felt at that level, things
: were better handled by another kind of program because there is little room
: for overhead there... sometimes not even function calls. Good abstraction
: may amount to macros that hide the scary bit-twiddling. Add to that a
: neverending stream of hardware to support... we figured that someone else
: could deal with that :)
: I don't want to bore you with any other details about our projects, but I
: wanted to mention that many of your ideas look familiar and that I have been
: thinking about such things too.
: Best of luck!
: --
: ~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
: "in theory, there's no difference [EMAIL PROTECTED]
: between theory and practice, mad genius research lab
: but in practice there is!" http://www8.pair.com/mnajtiv/
--
~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
"in theory, there's no difference [EMAIL PROTECTED]
between theory and practice, mad genius research lab
but in practice there is!" http://www8.pair.com/mnajtiv/
------------------------------
** 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 PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
