Linux-Development-Sys Digest #183, Volume #6 Sun, 27 Dec 98 21:14:32 EST
Contents:
Switching from floppy drive to CDROM drive (Compaq Armada) (Petter Reinholdtsen)
Re: Registry for Linux - Bad idea (Stefaan A Eeckels)
Re: building kernel under RH 5.2 (mvrao)
Re: Threads and PIDs ("Bjorn Wesen")
Re: building kernel under RH 5.2 (David Fox)
Re: gcc on RedHat 5.2 ("Jiandong Ruan")
Re: Registry - Already easily doable, in part. (Tristan Wibberley)
Re: Linux Registry Stone Bitch to Administer (Michael Kelly)
Re: Registry for Linux - Bad idea (Michal Mosiewicz)
Re: missing my C header files... (Erik de Castro Lopo)
Re: Registry - Already easily doable, in part. (Michal Mosiewicz)
Re: Possible MS legal threats to Linux and/or OSS (Graham Clark)
Re: Registry for Linux -> Use CORBA!!! (George MacDonald)
Re: Registry for Linux - Bad idea (Craig Kelley)
Re: Registry for Linux - Bad idea (Robert Krawitz)
Re: Registry for Linux - Bad idea (Rick Moen)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Petter Reinholdtsen)
Crossposted-To: comp.os.linux.portable
Subject: Switching from floppy drive to CDROM drive (Compaq Armada)
Date: 27 Dec 1998 15:30:29 GMT
Is there a way to get the linux kernel to "rescan" the IDE bus and
redetect floppy drives?
I have a Compaq Armada 7380DMT running RedHat 5.2. On this machine it
is possible to swap the CDROM and floppy drive at runtime. Linux
however does not detect this change, and the kernel goes bananas when I
try to use the removed device.
Any solutions?
------------------------------
From: [EMAIL PROTECTED] (Stefaan A Eeckels)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: 27 Dec 1998 13:17:14 GMT
In article <[EMAIL PROTECTED]>,
Michal Mosiewicz <[EMAIL PROTECTED]> writes:
> Stefaan A Eeckels wrote:
>> [...]
>> > In fact people are too tied to those fancy configuration files. They
>> > start to complain when it comes to start some netscape or some another
>> > configuration-hungry program. Just look at how your system (I mean
>> > Linux) starts. It takes a minute or so to boot up. Much of this time is
>> > spent on setting up the state of kernel. It takes hundreds of files to
>> > be open, tens of programs to be started and a lot of scripts to be
>> > interpreted.
>> Incorrect - the kernel doesn't use configuration files and only init
>> (which runs as a normal process) reads through inittab and executes
>> the /etc/rc.d scripts.
>
> Please, try to understand more deeply what does it mean to set up state.
> As you start your system, the kernel state is: no routing, only root
> device, not many devices configured - much of this is done later. Things
> like ifconfig, mount, insmod/modprobe etc exist just to setup the
> initial state of the kernel. There is a lot of scripts run later just to
> setup 'working state'.
Yes, but you should clearly define what you're talking about. If you say
that "bringing the system up (to a well-defined state)" requires reading
many files..." I'm all with you. If you say "...setting up the state of
the kernel. It takes hunderds of files..." then I'm no longer with you.
Don't forget that much of what you're talking about (init, samba, nis,
etc) are user programs.
You haven't answered my statement that it doesn't matter how long it
takes to boot the system, as long as it isn't done frequently. A boot time
of one minute once every six months is irrelevant. When talking about, say,
a portable that gets rebooted every two hours, it is relevant, but introducing
an 'optimal database' to reduce the boot time is silly - you should take
a snapshot of the kernel state and restore it instead of booting the system.
In any case, the most prevalent OS *with* (what they believe to be) an optimal
database takes longer to boot than Linux.
If you analyse start-up delays for a large program (eg netscape), you'll
see that reading the configuration files takes negligible time compared
to the paging in of the program. Until you've found a way to speed up the
loading of the program, shaving a few milliseconds off the reading of the
configuration files is not worth the effort.
>> Configuration data doesn't require an optimal database. It's low-volume,
>> and infrequently read. If the data changes often and/or is high volume,
>> it doesn't belong in configuration files. You're again concerned with
>> micro-optimisation.
>
> First - as you may notice - that (I mean kernel state) indeed was only
> an example. If you read my post carefully you find that speeding up
> kernel bootup is not my concern.
I've just told you that speeding up the load time of individual programs
cannot be done through an 'optimal database', so the only concern you
seem to have left is the small percentage of programs that need to record
massive amounts of frequently changing state data. That doesn't warrant the
overhaul of a complete OS and all the applications.
> However in many cases configuration data are read infrequently, because
> they cannot be read frequently with such design.
I don't follow you - there's no absolute virtue in constantly re-reading
your configuration data. It can be dangerous when configuration items
depend on each other, and it certainly is useful to be able to schedule
the re-reading of configuration data (you wanna come in at midnight to
reconfigure your LDAP server?).
Each program has different configuration requirements. Trying to have a
single subsystem that meets all possible requirements is
a) impossible
b) unreliable.
Impossible because you can't forecast what the needs of future programs
will be, unreliable because you'll have a lot of code that's never exercised.
Happy New Year,
--
Stefaan
--
PGP key available from PGP key servers (http://www.pgp.net/pgpnet/)
___________________________________________________________________
Perfection is reached, not when there is no longer anything to add,
but when there is no longer anything to take away. -- Saint-Exup�ry
------------------------------
From: mvrao <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.setup
Subject: Re: building kernel under RH 5.2
Date: Sun, 27 Dec 1998 17:05:08 +0000
David Fox wrote:
> mvrao <[EMAIL PROTECTED]> writes:
>
> > OK, this is my first attempt at building kernel under linux. I have used
> > RH 5.1 and RH5.2 ( 2.0.36) versions of linux only.
> >
> > RH unpacks source into /usr/src/redhat/SOURCES instead of
> > /usr/src/linux. The problem is that there is a hotchpotch of .c, .h, .gz
> > files some of them patches, some 2.0.35 and so on. I did not see a .gz
> > file for linux.2.0.36.tar . Will someone explain to me how to proceed
> > ? I could not find a resolution to this in HOWTO docs.
>
> First you install the .src.rpm using "rpm -i". Next run "rpm -bp
> /usr/rsc/redhat/SPECS/kernel-2.0.36.spec" to unpack the archives and
> create the source directory. Now run "make config" or "make xconfig"
> in the source directory and you should get a new .config file. Copy
> this to /usr/src/redhat/SOURCES/kernel-2.0.36-i386.config. Then run
> "rpm -ba /usr/src/redhat/SPECS/kernel-2.0.36.spec" to create new
> binary RPMs. You may want to increase the release number in the spec
> file before you do this. Now install the new .i386.rpm files, use
> mkinitrd to make a new init ramdisk if necessary, update
> /etc/lilo.conf and re-run lilo, and you're done.
> --
> David Fox http://hci.ucsd.edu/dsf xoF divaD
> UCSD HCI Lab baL ICH DSCU
David,
Thanks. I was not using the -b (build) option with RPM. It seems to unpack
the spec file to /usr/src/redhat/SOURCES but actually builds the source tree
under /usr/src/redhat/BUILD- am I correct ?
Again, thanks
-vasu
------------------------------
From: "Bjorn Wesen" <[EMAIL PROTECTED]>
Subject: Re: Threads and PIDs
Date: Sun, 27 Dec 1998 18:00:10 +0100
Bill Morgan wrote in message <[EMAIL PROTECTED]>...
>My question on threads: On my SMP system, why does it seem that
>a new thread only runs on the processor that it was created on?
This is just a long shot, but: on an SMP system, the scheduler gives a
process a slight advantage to staying with the CPU it last ran on (better
caching etc). So maybe in the cases you've seen, the overall load was such
that the scheduler succeeded in this trick. I don't see any reason for
_demanding_ a thread to run on the same processor it was created on, but
this tuning parameter might be pretty high ?
/Bjorn
------------------------------
Crossposted-To: comp.os.linux.setup
Subject: Re: building kernel under RH 5.2
From: d s f o x @ c o g s c i . u c s d . e d u (David Fox)
Date: 27 Dec 1998 08:07:58 -0800
mvrao <[EMAIL PROTECTED]> writes:
> OK, this is my first attempt at building kernel under linux. I have used
> RH 5.1 and RH5.2 ( 2.0.36) versions of linux only.
>
> RH unpacks source into /usr/src/redhat/SOURCES instead of
> /usr/src/linux. The problem is that there is a hotchpotch of .c, .h, .gz
> files some of them patches, some 2.0.35 and so on. I did not see a .gz
> file for linux.2.0.36.tar . Will someone explain to me how to proceed
> ? I could not find a resolution to this in HOWTO docs.
First you install the .src.rpm using "rpm -i". Next run "rpm -bp
/usr/rsc/redhat/SPECS/kernel-2.0.36.spec" to unpack the archives and
create the source directory. Now run "make config" or "make xconfig"
in the source directory and you should get a new .config file. Copy
this to /usr/src/redhat/SOURCES/kernel-2.0.36-i386.config. Then run
"rpm -ba /usr/src/redhat/SPECS/kernel-2.0.36.spec" to create new
binary RPMs. You may want to increase the release number in the spec
file before you do this. Now install the new .i386.rpm files, use
mkinitrd to make a new init ramdisk if necessary, update
/etc/lilo.conf and re-run lilo, and you're done.
--
David Fox http://hci.ucsd.edu/dsf xoF divaD
UCSD HCI Lab baL ICH DSCU
------------------------------
From: "Jiandong Ruan" <[EMAIL PROTECTED]>
Subject: Re: gcc on RedHat 5.2
Date: Sun, 27 Dec 1998 11:32:36 -0500
Some malicious guys may get 'root' privilege if you write code in this way
for a root-setuid program. When one manipulates input from outside the
program, one should be more careful.
Jinsong Ouyang wrote in message <762df0$3bs$[EMAIL PROTECTED]>...
>On RedHat 5.2, if you write a very simple C code like below
>
>main()
>{
> char input[80];
> gets( input );
>}
>
------------------------------
From: Tristan Wibberley <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Registry - Already easily doable, in part.
Date: Sun, 27 Dec 1998 21:40:44 +0000
Reply-To: [EMAIL PROTECTED]
Michal Mosiewicz wrote:
>
> Todd Knarr wrote:
> > [...]
> > True. I could speed things up there drastically, by piling all the routing
> > and other related stuff into a single monolithic script and dumping it in
> > in one big load. That, however, would be a stone bitch to administer after
> > it was set up. Any change would require reloading the whole thing
>
> Why reloading?
>
> By registry, I mean:
> a) an easily accessible database with optimised indexed storage
> b) kernel space managment to accomplish ownership of database records
This sounds like a filesystem (except for the per application rights,
which is a little more complex, and probably unnecessary). The speed
problem then is probably caused by running interpreted scripts, and that
the files are typically less than the block size (4kb on intel?) which
is inefficient. One solution could be to have a separate filesystem for
/etc (as a loopback in a file in /), then the kernel could load in the
whole /etc directory (raw data from disk) and mount it. You would want
to have only certain parts of /etc loaded in though, so for efficiencies
sake a /etc/boot directory would be useful, and some of the files in
/etc could be moved there (with the loopback in /etc). Init and inittab
would still be in /etc, along with a script that loads and mounts
/etc/bootfs on /etc/boot, and runs your usual startup script in
/etc/boot. This neatly gives you a registry-ish high speed startup
fitting into the unix philosophy. The issue of replacing scripts for one
setup apps data files is up to the applications that use the data.
> and access rights (not only per user, but also per application)
> c) events/notifiers/signals to allow for asynchronous notification about
> the changes in the state of variables
Hmm, a kernel table of scripts to run when particular files are changed
would suffice here but a file might be changed twice with unstable state
between - so this can be left to a unified app for execution by the
admin, it then calls the appropriate script.
> But the bottom line is - the application would be able to check it's
> configuration variables using much less syscalls and without cpu and i/o
> expensive parsing of any files.
Actually, by letting the app have it's own file format specially for
it's task you reduce the overhead substantially for any complex config,
and if the task isn't complex then the unified method is faster, but
since it's simple cases, it's very minor (eg "ifconfig" and "route"
would benefit if they had config files now, but they get called only 2/3
times and work from commandline anyway which is faster still).
Does anyone know if Linux supports any filesystems that can be increased
and decreased in size as files are added and removed? Does Linux allow
this at all?
--
Tristan Wibberley Linux is a registered trademark
of Linus Torvalds.
------------------------------
From: [EMAIL PROTECTED] (Michael Kelly)
Subject: Re: Linux Registry Stone Bitch to Administer
Date: Sun, 27 Dec 1998 15:52:53 -0500
On 25 Dec 1998 22:57:11 PST, [EMAIL PROTECTED] (Satch) wrote:
>Let me break out one element of the discussion of a "registry" for Linux:
>the task of administrating such a beast.
[snip out of good points for brevity]
Just to add my $.02.. after reading the points made here it's evident
that a scheme designed for a multi-tasking single-user system isn't
necessarily the best idea for a multi-tasking multi-user system. :)
Mike
"Genius gives birth, talent delivers."
- Jack Kerouac
(remove NOSPAM from address, if present, to reply)
------------------------------
From: Michal Mosiewicz <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: Mon, 28 Dec 1998 00:42:57 +0100
Stefaan A Eeckels wrote:
> [...]
> If you analyse start-up delays for a large program (eg netscape), you'll
> see that reading the configuration files takes negligible time compared
Are you sure? I mean - is it paging the binaries that causes the delay?
As for my machine Netscape pages in about 4-5MBs at start. Not much,
right? On the same machine I'm able to page in the whole netscape binary
(which normally never happens) and every library in just 5 seconds.
The whole netscape starts about 30 seconds. Where is that negligible
time your talking about? Of course Netscape's case is pretty
exceptional. To make parsing easier Netscape often reads configuration
files byte-by-byte. But that's a different story.
Anyhow - the time spent on opening (50% missed), reading, seeking,
closing is not negligible.
Happy New Year,
Mike
--
WWW: http://www.lodz.pdi.net/~mimo tel: Int. Acc. Code + 48 42 2148340
add: Michal Mosiewicz * Bugaj 66 m.54 * 95-200 Pabianice * POLAND
------------------------------
From: Erik de Castro Lopo <[EMAIL PROTECTED]>
Subject: Re: missing my C header files...
Date: Mon, 28 Dec 1998 10:47:19 +1100
Carl Sjoquist wrote:
>
> I've installed (via RPM) gcc, glibc and libc++, but can't figure out what I
> need to do to get the C header files copied to my system. According to
> glint, libc is installed and when I list its files, there's a bunch of .so.
> files but no headers (.h). Obviously I'm missing something (like a
> screw) -- can anyone guess what I've missed?
There's something called glibc-devel-*****.rpm that you need to install
to get the header files.
Erik
--
+-------------------------------------------------+
Erik de Castro Lopo [EMAIL PROTECTED]
+-------------------------------------------------+
Those who do not understand Unix are condemned to reinvent it, poorly.
-- Henry Spencer
------------------------------
From: Michal Mosiewicz <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Registry - Already easily doable, in part.
Date: Mon, 28 Dec 1998 01:03:49 +0100
Tristan Wibberley wrote:
>
> Michal Mosiewicz wrote:
> >
> > Todd Knarr wrote:
> > > [...]
> > > True. I could speed things up there drastically, by piling all the routing
> > > and other related stuff into a single monolithic script and dumping it in
> > > in one big load. That, however, would be a stone bitch to administer after
> > > it was set up. Any change would require reloading the whole thing
> >
> > Why reloading?
> >
> > By registry, I mean:
> > a) an easily accessible database with optimised indexed storage
> > b) kernel space managment to accomplish ownership of database records
>
> This sounds like a filesystem (except for the per application rights,
> which is a little more complex, and probably unnecessary). The speed
> problem then is probably caused by running interpreted scripts, and that
> the files are typically less than the block size (4kb on intel?) which
> is inefficient.
Right - finally someone notices that. Per applications rights are not so
complex, however they are not so important. What is important - each
open operation is relatively costly. So it's good for performance to
have less opens, and to have more informations per single file. By
compressing more informations in a single page we make a better use of
cache memory.
By optimisation I mean something like clustering (related keys/values
are groupped on the same pages) and indexing.
Mike
BTW. It was my intention that it sounded like a filesystem. But
precisely customized filesystem.
--
WWW: http://www.lodz.pdi.net/~mimo tel: Int. Acc. Code + 48 42 2148340
add: Michal Mosiewicz * Bugaj 66 m.54 * 95-200 Pabianice * POLAND
------------------------------
From: Graham Clark <[EMAIL PROTECTED]>
Crossposted-To: misc.legal.computing
Subject: Re: Possible MS legal threats to Linux and/or OSS
Date: 23 Dec 1998 13:35:23 +0000
[EMAIL PROTECTED] (Tony Hoyle) writes:
>
> On Tue, 22 Dec 1998 11:54:59 -0800, Scott Johnson
> <[EMAIL PROTECTED]> wrote:
>
> >c) Reverse engineering. The legal theory of "shrink wrap licenses" has
> >yet to be tested in court, as far as I am aware,
>
> In the England such licenses are not considered valid (however in
> Scotland they are). I wouldn't be surprised if the issue had been
> decided in other countries too.
I think there's a general point here about one party imposing
extra conditions after the sale has been completed.
Also, do you know of anywhere where the Scots case is discussed? I'd
be quite interested in that.
Cheers,
Graham.
------------------------------
From: George MacDonald <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux -> Use CORBA!!!
Date: Sun, 27 Dec 1998 21:20:54 GMT
Caspian Maclean wrote:
>
> In article <[EMAIL PROTECTED]>,
> George MacDonald <[EMAIL PROTECTED]> wrote:
>
> >For now I would settle for all new apps putting user config
> >information in one directory under my $HOME. Currently I
> >have about 30 .something files and directories there!!!
>
> >How about it then could everyone start putting user config
> >files in
>
> > $HOME/.userStore/applications/${applicationName}
>
> >or something similar?
>
> I like that idea. I don't like .userStore as the name though.
> I'd prefer the word seperation to be e.g. .user_store
> and the name "user store" doesn't seem quite right for the part
> of the home directory that is storing configuration information.
> I suggest .conf_store or .config.
Thanks for the comments.
The reason for "userStore" vs. "user_store" is to alert developers
to the OO methodolgy. This seems to be the norm in OO based
toolkits such as X/Xt/Motif and in *some* of the newer class
hierarchies.
The reason for the generic name of Store, again it's more of
a OO term. Shorter form of -> user persistent storage. While
the vast majority is for config information, the space
should also be used for other context files, history files
work files ... For example gimp is currently using my home
directory to store a temp work file! The file is about
40 characters in length and makes a real mess of my ls -artl !!!
A better place would be:
$GOME/.userStore/applications/gimp/current/workFiles
or something similar.
Having said that a ".config" covers the 90% solution, it is
tempting due to it's clarity? Hmm. any one else have an opinion
on this?
Would you think it confusing to put history files under a .config?
--
We stand on the shoulders of those giants who coded before.
Build a good layer, stand strong, and prepare for the next wave.
Guide those who come after you, give them your shoulder, lend them your code.
Code well and live! - [EMAIL PROTECTED] (7th Coding Battalion)
------------------------------
From: [EMAIL PROTECTED] (Craig Kelley)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: 27 Dec 1998 18:10:06 -0700
In article <[EMAIL PROTECTED]>,
Michal Mosiewicz <[EMAIL PROTECTED]> wrote:
->> If you analyse start-up delays for a large program (eg netscape), you'll
->> see that reading the configuration files takes negligible time compared
->
->Are you sure? I mean - is it paging the binaries that causes the delay?
->As for my machine Netscape pages in about 4-5MBs at start. Not much,
->right? On the same machine I'm able to page in the whole netscape binary
->(which normally never happens) and every library in just 5 seconds.
->
->The whole netscape starts about 30 seconds. Where is that negligible
->time your talking about? Of course Netscape's case is pretty
->exceptional. To make parsing easier Netscape often reads configuration
->files byte-by-byte. But that's a different story.
->
->Anyhow - the time spent on opening (50% missed), reading, seeking,
->closing is not negligible.
Here's some real-world figures for you:
http://inconnu.isu.edu/~ink/regfun/
--
The wheel is turning but the hamster is dead.
Craig Kelley -- [EMAIL PROTECTED]
http://www.isu.edu/~kellcrai finger [EMAIL PROTECTED] for PGP block
------------------------------
From: Robert Krawitz <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: 27 Dec 1998 20:22:56 -0500
Michal Mosiewicz <[EMAIL PROTECTED]> writes:
> Stefaan A Eeckels wrote:
> > [...]
> > If you analyse start-up delays for a large program (eg netscape), you'll
> > see that reading the configuration files takes negligible time compared
>
> Are you sure? I mean - is it paging the binaries that causes the delay?
> As for my machine Netscape pages in about 4-5MBs at start. Not much,
> right? On the same machine I'm able to page in the whole netscape binary
> (which normally never happens) and every library in just 5 seconds.
I think it's a Linux kernel problem of some kind. I've observed that
the first time I start an app on Linux, of any kind, it starts very
slowly, but if I exit it and restart it it's very fast. This is true
with Netscape, emacs, and even very simple games. If I effectively
flush the page cache (by doing something that takes a lot of swap
space) it starts all over again. This does not happen on Solaris.
Emacs starts fast even the first time there.
My suspicion about what's going on is that the kernel's not doing
enough readahead; it's trying to simply demand page stuff in. Since
most things jump around a fair bit, this results in a lot of random
seek behavior, which really kills disk performance.
There are still a whole bunch of VM changes slated for 2.2, as I
understand it, and hopefully some of them will address this problem.
> The whole netscape starts about 30 seconds. Where is that negligible
> time your talking about? Of course Netscape's case is pretty
> exceptional. To make parsing easier Netscape often reads configuration
> files byte-by-byte. But that's a different story.
It also doesn't really matter. My Netscape preferences file is about
4 KB. On an even halfway modern processor it would have to do an
awfully large amount of work for that to be even visible.
> Anyhow - the time spent on opening (50% missed), reading, seeking,
> closing is not negligible.
Well, now, don't be so sure of that. Every Byte benchmark run I've
done on my box over the past 3 years has shown that this sort of stuff
really is negligible. The 4+ year old Solaris box (a Sparc 10) I use
for comparison is at least an order of magnitude slower by the
benchmarks, but first time startup is still faster on that than on my
Linux box (currently a Celeron 450A with 128 MB).
Note that that's only the first time startup performance; after that,
my Linux box makes mincemeat of it (and for that matter, it did so
quite nicely when said machine was a P90 with 32 MB). It's just that
there's some pagein quirk on Linux that could stand to be addressed.
Your Netscape might be doing other things as well, such as reaching
out over the net for a default page (like Netscape's site). If it's
doing that, it's dependent upon network latencies and bandwidth. In
that case, no fancy scheme (short of a persistently caching nameserver
and caching of the web pages) will help you.
Try this experiment: set your browser for no startup page, and start
your browser and immediately exit it. Then immediately restart your
browser, and time the restart. I suspect you'll find something rather
different between the two starts.
--
Robert Krawitz <[EMAIL PROTECTED]> http://www.tiac.net/users/rlk/
Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail [EMAIL PROTECTED]
"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton
------------------------------
From: Rick Moen <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: 28 Dec 1998 01:21:28 GMT
In comp.os.linux.setup Richard RUDEK <[EMAIL PROTECTED]> wrote:
[snippety-snip]
: I think, my next step is to try and consolidate the various related threads
: on this, into a new thread, and not let the legacy proponents stifle debate
: by splintering it - divide and conquer, so to speak.
If and when you do, please use a _sane Newsgroups header_. Please
notice the current distribution list (and the Followup-To).
--
Cheers, The cynics among us might say: "We laugh,
Rick Moen monkeyboys -- Linux IS the mainstream UNIX now!
rick (at) hugin.imat.com MuaHaHaHa!" but that would be rude. -- Jim Dennis
------------------------------
** 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
******************************
