Linux-Development-Sys Digest #817, Volume #6 Fri, 11 Jun 99 08:14:30 EDT
Contents:
TAOs: Much to do about nothing? (Paolo Torelli)
Re: Casio QV-11 on Lava DSerial PCI Port, follow-up (Tjeerd Mulder)
Re: Any Mail Application for commercial use (Juergen Heinzl)
Re: Configuration Manager for Linux (Jonathan Abbey)
----------------------------------------------------------------------------
From: Paolo Torelli <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: TAOs: Much to do about nothing?
Date: Fri, 11 Jun 1999 13:11:50 +0200
Reply-To: [EMAIL PROTECTED]
This is a multi-part message in MIME format.
==============A507B6FF82C34CA07AE409B5
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Let me introduce myself. I've been reading this topic for about a week
or so with deep interest. I am actually part of the project which you
know as TAO OS (renamed to TAPos due to various reasons, one of which
being the TAO eLate operating system). The reason for my silence is that
I was learning as much as possible from your comments (each read with
care) and from mistakes. After ome time I spontaneously decided to
ignore my duties (I'm having exams) to write a better text than the one
written ages ago by Vlad.
I am going to include that text as an attachment. Please read it and let
me know your comments. Alas, I won't be able to spend much time replying
not coding for a while (exams!!), but I swear I'll do my best. I wrote
the text in less than a day (all the time I could manage spend on it!)
and many of the things we've already discussed is not present at all.
Also, the text is pretty chaotic in its contents (should be re-arranged
in a better way) but what I wanted to do was to explain better the
situation. That's all I can write for now, thanks for your patience and
cooperation so far! :)
--
[=-----------------------Technolord-the-Hellraiser----------------------=]
To those who can see the truth to those who can still have
feelings
to those who still have the courage to live in this evil world.
.no.regrets.
==============A507B6FF82C34CA07AE409B5
Content-Type: text/plain; charset=iso-8859-1;
name="tapos.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline;
filename="tapos.txt"
"A 10'000 steps travel always begins with the first step"
-- Taoist motto
For whatever it might seem fool ordisastrous to design a new operating
system nowadays, someone has to do it.
It is pretty clear that actual operating systems are restricted in their
potentiality, closed in their shell, hanging to an old conception or not
enough widespread.
Alas, an OS does not become THE OS just ecause it is programmed well, or
because it is designed better. A clear example, Windows. An example of a
missed great OS: OS/2, which showed better functionality than NT's ages
before NT itself. What makes a system "better" than another is the quanti=
ty
of applications for the type of audience the OS is expecting to gather.
Without so many graphical/DTP applications at disposal, MacOs wouldn't be=
so widespread in typographies. Also, with all the new upcoming technologi=
es
(eg: in 2 years 3d-accellerators are on almost every computer), an OS
should be able to offer coherent interfaces to the hardware to tht it can=
be easily extended. MSDOS was a good example of non-extendable system.
(note that tweaks are not extensions!)
Also, with the extension of computer usage to non-operators, the ease of
use has become more stronger; the internet experience made security more
important; data safeness is a major requirement for companies which canno=
t
see their data lost just because winamp crashed and the system wasn't
robust enough to continue functioning proprely (NOTE: I have nothing
against winamp, which I consider a great software indeed. I was just givi=
ng
a real example of things that I saw happening)
The key points to keep in mind are then summarized as follow: (to be
considered a guideline and not a complete nor exhaustive list of things)
- Ease of use
- Software availability
- Networking capabilities
- Platform indipendance
- Extendability
- Idiot-friendly as well as hacker-friendly
- Reliability under most circumstances
Hopefully, these points should be kept in mind all the time by software
designers, and even more by OS designers. Alas, too often it isn't. Linux=
is all but easy to use or idiot friendly, it assumes the user is a
programmer, at least. On the other side, MacOs is really easy to use but
limited by the lack of programming tools (well, FREE tools I mean) and mo=
st
important is not reliable (crashes way too often!). Microsoft offers a wi=
de
set of tools and libs to aid the programmer, yeah, but try programming un=
der
windows without M$'s visual tools and... welcome to hell! MSDN costs big
bucks, making it almost unaffordable if not for companies.
The TAPos project tries to solve efficiently and (most important!)
elegantly all the issues with an eye to the present to learn and an eye t=
o
the future, to create somthing that will be able to painlessy evolve for
the next years (many, we hope :). Ideas are correlated with suggestions a=
s
how this should, or might, be achieved, trying to make this document more=
a
designing project than just a wish-list.
A basic point is that the system should be easily portable without almost=
any change in the code. UNIX gave a good example it should be done, and N=
T
gives an even better idea. An idea is that we should have all components =
of
the OS (apps will be considered extern to the OS itself) being independan=
t
from the platform on which they're implemented. Obviously, this is not
possible in its strictest meaning: memory management/paging is a perfect
example of what I mean. But examining more closely, we can subdivide the
memory management in 2 parts: a machine independant part, the algorhithm
itself, and a low-level part, which actually sets the procesor's tables a=
nd
such things. Then, seems possible to subdivide those components which
require a direct access to the hardware details to be abstracted, a
component written in an high-lelvel language (like C) and an assembly,
architecture dependant part. Porting would then be just matter of
re-writing the assembly part, which sounds good to us.
The above subdivision opens the doors to another, fascinating as well as
powerful, world: real plug-and-play OS. What I am to say here might sound=
absurd to most of you, but I assure it IS possible to realize it (sample
code can be done in few time), so why not take it in consideration? :)
Linux is considered a good OS to study because the source can be changed =
by
the user, and portions of it modified and studied. Another idea is that
different systems can have different requirements, and the ideal OS for a=
n
use can differ slightly from another. The idea behind that is: why not ma=
ke
single modules interchangeable? If for my requirements a scheduler like
linux's (single queue) works fine, why should deny those who have better
functionality with NT's scheduler (priority queues with feedback) to use
it? After all, it's just a differnt loaded module. But we can't make
end-users (or system operators, but home users are no sysops!) recompile
the kernel each time, so use loadable modules, which then have to be
interchangeable each other in the same family (obviously, you can't put a=
memory manager in place for the keyboard manager!). Then the op could
exchange the component (say, from a list of availables possibilities),
restart the system and evaluate changes in system's efficiency (correctly=
written modules should make no change in overall behaviour: if A makes ap=
p1
work, also B should make app1 work!). A good example of what I mean is th=
e
PSEmuPro, which has exchangeable components. But hey, there are times at
which it is NOT required to restart the system itself! A scheduler can be=
exchanged with another just by re-scheduling all processes, a video drive=
r
can be exchanged on-the-fly by migrating all data from one driver to
another! I already hear your voices, "it is way too slow to dynamically
link modules, to use indirect calls instead of direct calls, etc", and th=
en
comes the idea: to modify directly the code at load-time so that it looks=
perfectly like it was all glued together at compile time. Well, a bit of
overhead at load time is acceptable (and I can say it is so small that
doesn't make the difference), and the advantages are clear! Also, see
another advantage: if an experimental module doesn't work proprely, it
takes no trouble to revert back to a safe module; mess with the kernel un=
der
linux, recompile the kernel and, if it doesn't work, well I hope you kept=
a
previous copy of the kernel or you'll have troubles, if not so big it'll
always be a waste of time.
Interchangeability requires a good and well-defined interface between
modules, and we're working on it, but we have faith we'll get to somethin=
g
good pretty soon.
To safeguard the system stability all entities have to be indipendant and=
well-coded, eg a driver cannot see another driver's memory. This can be
done with protection, but it slows down. To make entities exchangeable it=
is required a "container" which encapsulates the other entities and
connects them each other... think as an example to the HDD moble rack,
which has space for the hard disk and a plug on its back to connect to th=
e
HDD bus: you can take away the HDD and plug another one which has the sam=
e
interface, plug back the rack and all works fine. Same thing! the "rack"
(or container) can have a flat cable or an interface which checks data fl=
ow
for it correctness. Likewise, the container in the OS can check or not al=
l
parameters in and out the entity for validity, but the entity should work=
either case. If an operator does not trust a driver, or it is experimenta=
l,
or whatever, he (she?) can choose which check level apply to the entity's=
connections at the cost of efficiency but gaining in security or ignore
saveguard ("trusting entities") but gaining greatly in performance. The
connector is interchangeable with another, making all this discussion cut=
e,
clean and coherent with the text so far.
More on, the connection system itself can map messages between structures=
without notice from the entity: the interface is the same, and an HDD
doesn't know if it's connected to my PC or my neighbour's, it just accept=
s
messages and responds to them, as long as they're correct. But then, pipe=
s
of enities can be easily created using "wrappers" of messages from one
system to another. A ISO-CD driver which gets mapped over a FAT system
mapped on partition 1 of IDE11 (in other words, a binary image of a CD in=
a
file on a FAT system) would be identical (maybe not speed :) to ISO-CD
mapped on partition1 of SCSI15 (a cdrom drive on SCSI ID5, LUN1).
Eventually, a log of mesages can be kept so that, if something goes wrong=
,
the path the paket taken can be rebuilt and eventually the single message=
s
rebuilt, so that the source of error can be discovered. Slow? Just don't
use the feature by selecting another handler! Easy, ain't it? :)
The slots are to be filled in some way. The easiest and apparently most
intelligent way is to let OTHERS fill them ;)) And since the hard part is=
to
write (and keep updated) drivers, the best way to have them done is makin=
g
companies doing them. We're not going to ask them to build our specific
drivers, indeed we're going to implement natively the UDI interface and n=
ot
defining anything new for them, having then the advantages of drivers wri=
tten
with a good interface (a commitee of experts is working on it) and using =
them
without tweaks/wrappers (which introduce overhead).
Thinking to the poor and bethrayed programmer, the programming interface =
will be studied to be as more powerful and abstract as possible, leaving =
the dirty work to the underlying system (and therefore allowing possible =
hardware specific funcions). As for linux systems, for example, the file =
system will be virtualized, the memory spaces will be virtualized, and so=
me more.
Virtualization is another of the key points in our efforts, trying to all=
ow OS usage on the widest range of platforms, limiting as least as possib=
le both the user and the programmer. One of the major goals is to have di=
fferent platforms (eg. a P2 and an iMac) run the SAME program (without ex=
plicit recompilation), use the same data and have the user not noticing a=
ny change in functionality. This can be achieved in various ways. The eas=
iest would be limiting all the platforms to a minimal set, but this would=
be awful and pretty stupid, as great parts of the system would then be l=
eft unused. Another chance is to emulate a system (say, a P2 emulator for=
the iMac), with relative unhappiness from the later. The choice we're tr=
ying to implement is to create a system which is a superset of actual sys=
tems, where (if required) resources are mapped into the system architectu=
re. Also, use of an interpreted set of instruction (as for Java machines)=
would be used. By selecting an appropriate set of instruction (eventuall=
an existing processor's) which is a subset of many computer's, we may im=
plement a dynamic recompilation to native code, making it very efficient =
and not time-consuming. Also, since the code is from a virtual machine (a=
gain, think JavaVM) we can safely execute code in native instruction set =
(as long as it is translated correctly, it shouldn't give any problem). F=
or the resources limits, we're actually trying to define which limits are=
acceptable and which are tweakable efficiently. For example, defining a =
>4GB space on a 386+ processor is pretty trivial using paging and require=
s almost no overhead (the problem is how to map >4GB into 32bit addresses=
, windowing sounds a good choice).
The whole system cannot be made with pseudocode (obviously), and requires=
to be compiled natively. Also, if an user wants to gain even more speed,=
should be allowed to ask to "recompile" the pseudo-code natively, so tha=
t translation occours only once and not at every execution. Therefore it =
is required to have some distinction between file types, plus some more. =
Moreover, since compatibility is a major issue (no apps =3D no users), an=
d since the system should be easily extendable, a subsystem structure lik=
e NT's makes the perfect choice, where subsystems may lay on other subsys=
tems. Eg: if a VM with 32 bit addressing is created, for example, and the=
n a 64bit one is developed, becomes easy to extend the system's functiona=
lity just installing a 64bitVM subsystem and then using it. Hence, we can=
implement a POSIX subsystem (eventually laying on the VM32, if required)=
and allow *X users to migrate, or even create a Win32s and allow window =
users to continue using their programs, this time on a (possibly) safer p=
la
form. Subsystems would be implemented by redirecting (wrapping) native ca=
lls over OS's transparently. And more, by masking the subsystems (again, =
each process becomes an entity without knowledge if where it's placed) we=
can make different processes under different subsystems to talk (a unix =
KILL mapped to a win32s program close or such is a good example), each be=
lieving the other app (or whatever) was of the same type.
The system as a whole is going to be implemented by abstracing each entit=
y from its context, therefore making piping easy, but the heart of all wo=
uld be message passing, which allows for thorough checking as well as tun=
neling. And there comes the fun part: messages can be tunneled, and what =
retains us from sending them over a network adapter to another computer? =
Theoretically nothing (ok, speed. But still feasible!). And then, where's=
the problem in realizing parallel processing over different machines? By=
using pseudocode, the machines can be etherogeneous, by using message pa=
ssing they can communicate, and by applying a memory manager over the mes=
sage passing scheme, they can also (virtually) share memory between proce=
sses, so in theory there are no apparent problems (none of which we can v=
iew, at least).
Then comes the secutiry problem. Within an user space, subsystems themsel=
ves make a good distinction if supported by hardware abstraction (ie, vir=
tual memory), and subsystems themselves should be able to separate addres=
sing spaces within themselves. The solution we're developing implies that=
subsystems are user level programs (then, with no privileged instruction=
s) that clone (fork) themselves, keeping some code shared (the subsystem'=
s) but not data (subsystem's structures). This saves some memory and shou=
ld ensure that is an application corrupts a subsystem's data structures (=
shouldn't, but who knows?) it can be shut down safely. Crashing of a prog=
ram is always a problem, leaving now freed memory as used and not releasi=
ng resources. The layer underlying the subsystem should keep track of all=
ocated resources for each instance of it, whether it has open files, conn=
ections, loaded DLLs (whose code is shared among programs to save memory)=
or whatever, releasing them on termination (wether normal or abnormal) -=
some resource-dependant code could be required to proprely release a dev=
ice, say, a tape.
Also, leaving resource allocation to the lower layers (eventually a modul=
e dedicated to resource allocation) makes easy to substitute them to impl=
ement (if required) any allocation policy, based on priority, on running =
time, on deadlock countermeasure (prevention, avoidance, detection), alwa=
ys keeping in mind the interchangeability of the single elements, depedin=
g on the system usage.
System coherence is to be assured over time, and this can be accomplished=
in various ways. It is still to be well-defined HOW we're actually going=
to achieve it, but there are some ideas being considered. First of all, =
denying access to some files to every user (include sysops) and allowing =
it only to certain system utilities, utilities which are themselves write=
able only by users who have rights to do it (eg, the sysops), and only un=
der previous acknowledgement which cannot (should not...) be cheated by a=
pps. This makes difficult (but I guess still not impossible) for evil pro=
grams to infiltrate a system: if the user is to install something known n=
ot to be a system utility and gets the message "Hey, are you really going=
to install something to the system directory???" it obviously mean somet=
hing wrong is about to happen, and since system utilityes should be downl=
oaded only by official sites (trusted), it makes things a bit safer. Also=
, installs are to be monitored through all the process. MacOs suggests a
ood way to keep track of program positions, and should be kept under cons=
ideration. Also, a better implementation of registry than windows' seems =
a good thing to keeep in mind (cleaner and more space-efficient than havi=
ng configuration files for each app like linux does). More coherence is a=
lso kept by reducing application's domain (I mean, installation stuff, no=
t data) to a directory (unlike windows' policy do what you want, overwrit=
e system files as you wish) and by offering a version system to shared li=
braries so that a program can use the newest version or revert back to a =
previous if errors occour, and eventually the user will have control over=
which versions to keep and which to drop (to save space)
With an eye to all those who'll use it, policies are choosen to help ever=
yone's life. The poor system operator (which has hard life under pretty e=
very operating system) is considered just as every other user, and user m=
anagement is treated like in Netware (an user can build subgroups and oth=
er users which are limited in their permissions by creator's), the sysop =
being a user with restrictions applied (so that he can't accidentally do =
anything like 'rm -rF /'). User friendly panels like those in MacOs/windo=
ws are to be used to help configuring easily the whole system. Diagnostic=
tools are also to be deployed.
Programmers should be aided with well-defined and consistent APIs, which =
include (but not limited to... ;) memory management (allocation, sharing,=
file mapping), process and thread management, synchronization primitives=
(semaphores, monitors), communication ports (sockets, messages, pipes), =
security (privilege restrictions, checking), intelligent data types (like=
NT's "object" entity).
Users too are important (as they decide an OS' future), and to them shoul=
d all remaining efforts go. By defining an elegant and neat interface, us=
er gets good feelings. By defining configurable interfaces the user feels=
more comfortable and gains in both productivity and happiness. By defini=
ng interchangeable interfaces the system can therefore be updated (change=
d) possibly painlessly. It is needed to define a good interface for both =
pointing devices (mouse, pen, touchpad, eventually keyborad, but also gau=
ntlets, visors, guns and so on) as well as character devices (keyboard, b=
ut also vocal input) so that they can be used each in place for the other=
=2E
Interaction should be kept as much independant as possible from the syste=
m being used, and X's clinet-server structure shows a good idea which req=
uires to be better implemented, but that's still a good starting point.
We all know computers are not only for work, and games should be able to =
work proprely and efficiently under the system. We strongly believe that =
well-defined APIs do not require workaround such as those required in win=
dows, and an in-depth study of fine-tuned APIs is to be done. The abstrac=
tion work stated above greatly helps this step, defining an uniform inter=
face between different devices.
Other capabilities should also be implemented, some of which are stated d=
uring the whole curse of the text and which fit perfectly in the overall =
system design.
Things like mounting point different from the root directory of a disk (c=
annot be done under *X if not with tweaks like 'mount /dev/hda5 /mnt/hda5=
; ln -s /wherever /mnt/hda5/this/is/a/subdir')
Also, the VFS under linux is restrictive, not allowing streams, ACLs and =
some other stuff which is instead present under file systems like NTFS. O=
ur purpose is to implement a superset of existing filesystems where some =
(depending on the filesystem in use) things are disabled or mapped to oth=
ers; pretty much like *X's approach, each filesystem has its own drivers,=
loaded and unloaded as required, eventually attached to a special interf=
ace, "wrapper", which wraps a whole filesystem to another. A concrete exa=
mple would be:
FAT -> WRAPPER -> RAW (which implement partitions, see below) -> IDE11 ->=
hdd
The RAW file system could also implement multi-segment partitions (eg, sp=
anning over 2 HDDs) trasparently to the FAT driver. Or cache another supp=
ort over a faster one, like a CD disk over an HDD or over a network conne=
ction (effectively sharing the CD).
In conclusion, the whole system would be placed upon lists of interchange=
able functions, the system keeps complete track (RPM-like) of every insta=
llation and is therefore able to 1) move objects around 2) clone installa=
tions to other compatible systems 3) completely uninstall the app without=
leaving the (well-known to windows users) garbage around or removing vit=
al components.
Expecially the later point is vital for the correct owrk of the system, a=
nd this can be achieved by examining new software not installed (eg. unzi=
pped programs or self-made programs, which do not have gone through an in=
stallation process) for which shared components they use, effectively rec=
ording them as needed and updating counters which else are often inaccura=
te (again, windows gives a perfect example)
[some other stuff might go here]
Personal background: Knowledge of various programming languages, from ass=
embly [x86, 68k, RISC, Z80 :) and some other embedded processors] to C, C=
++, Java, Pascal, Eiffel, Scheme, Prolog, Clipper, Visual Basic and some =
more. Have used AmigaOS, MacOs, MSDOS, IRIS, Windows (2.0 (!!) up to 98,N=
T3.1 up to 5.0), OS/2 (2.0 up to Merlin), Linux (debian, redhat, slackwar=
e, suse). Knowledge of the in-depth work of most of them (don't want to r=
e-write the list ;). In the projects I made (x86) can be counted: a minim=
al operating system, a 3.1-like system (gui, multitasking, etc), democodi=
ng, protected mode programming. Knowledge of algorhithms, complexity and =
stuff like that. Knowledge of protection schemes (both software and hardw=
are), bughunting and backdoor finding/removal.
==============A507B6FF82C34CA07AE409B5==
------------------------------
From: Tjeerd Mulder <[EMAIL PROTECTED]>
Subject: Re: Casio QV-11 on Lava DSerial PCI Port, follow-up
Date: Fri, 11 Jun 1999 13:19:22 +0100
I modified the standard serial driver to support several PCI serial
cards including the Lava one. I have patches for 2.0.36 and 2.3.3. The
2.3.3 patches should work for 2.2.9 as well. I did try to get them in
2.0.37 but was too late. Hope to get them into the 2.3. series. Please
tell me if you want to have the patches.
Marco Fonseca schrieb:
>
> Marco Fonseca wrote:
> >
> > Does anyone out there know how I can go about getting Linux to recognize
> > the Lava card (which in Win98 device manager appears in two separate
> > entries: as a parent card and as COM ports 5 and 6) and then Casio
> > digital camera attached to it?
> > Thanks,
> > Marco Fonseca
>
--
======================================================================
Tjeerd Mulder ! Email: [EMAIL PROTECTED]
Siemens PC Systeme RD CM !
Buergermeister Ulrichstr 100 ! Phone: +49 821 804 3549
86199 Augsburg ! Fax : +49 821 804 3628
======================================================================
------------------------------
From: [EMAIL PROTECTED] (Juergen Heinzl)
Crossposted-To:
comp.os.linux.development.apps,comp.os.linux.networking,comp.os.linux.misc
Subject: Re: Any Mail Application for commercial use
Date: Wed, 09 Jun 1999 21:58:34 GMT
In article <[EMAIL PROTECTED]>, Eddy wrote:
>Besides Zmail and Sendmail, is there any mail application suitable for
>commercial use ? As Sendmail seems too complicated for commercial and
>the user interface is not so user-friendly.
True, though sendmail is a MTA, and quite common in commercial
environments, while Zmail is a MUA. Say do you want something to
read and write email or something to transport it from A to B ?
Cheers,
Juergen
--
\ Real name : J�rgen Heinzl \ no flames /
\ EMail Private : [EMAIL PROTECTED] \ send money instead /
------------------------------
From: [EMAIL PROTECTED] (Jonathan Abbey)
Subject: Re: Configuration Manager for Linux
Date: 10 Jun 1999 12:56:29 -0500
In article <7jom2e$3155$[EMAIL PROTECTED]>,
Leslie Mikesell <[EMAIL PROTECTED]> wrote:
|
| I guess one thing that made me put off setting up Ganymede to test
| it was the idea of yet-another-database. I already have several
| flavors of sql servers and ldap each with their own concepts of
| multi-platform clients and access controls. Wouldn't it have
| been possible to use one of these instead of inventing another
| one? The idea is supposed to be to avoid having to understand
| and manage so much different stuff - or at least that's what
| I'm looking for.
Oh, as far as existing databases having their own multi-platform
clients and access controls..
5) I wanted the client to be maximally helpful and, in conjunction
with the server, intelligent about guiding the inexperienced
non-technical administration staff to do the right thing. Giving them
a client that talked directly to an SQL database or LDAP server would
mean that all the intelligence and protective logic would have to be
in the client, which wasn't adequate from a security standpoint.
Perhaps Ganymede could have been made to act as an LDAP server to
existing LDAP clients, but those LDAP clients didn't exist in 96, and
even current LDAP clients have no way of engaging in a wizard dialog
sequence with the server, which Ganymede supports for customization
and user guidance.
6) I've never seen a general purpose database that has as much
intelligence in access controls as Ganymede does. Not only does
Ganymede have a rich 3-level permissions system, it also supports
complete customization of permission logic for individual types of
objects, through the plug-in architecture. Since Ganymede has an
explicit notion of objects and fields, this security model fits very
naturally with the data. There would be no practical way to force as
rich a security model onto an SQL server and still have the easily
modifiable schema.
And of course, I wanted the extensive logging and event reporting that
GASH had. Ganymede lets you click a single button on an object to see
a complete history of changes made to the object, in transactional
context, even across schema changes, which would have been somewhat
difficult with an SQL or LDAP server.
| Les Mikesell
| [EMAIL PROTECTED]
--
===============================================================================
Jonathan Abbey [EMAIL PROTECTED]
Applied Research Laboratories The University of Texas at Austin
===============================================================================
------------------------------
** 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
******************************
