Linux-Development-Sys Digest #217, Volume #6 Tue, 5 Jan 99 03:14:40 EST
Contents:
Re: Massive vfat memory leak? (Gady Kozma)
Re: Where is the Console Driver Menu in Kernel 2.1.99? (Steven James)
Re: Registry - Already easily doable, in part. (George MacDonald)
Re: Registry - Already easily doable, in part. (Frank Sweetser)
Re: GUI, The Next Generation (Derek B. Noonburg)
Re: Kernel v2.2 (Edward Lee)
Re: Registry - Already easily doable, in part. (Todd Knarr)
Re: WDM Emulator, anyone? (SONE Takeshi)
Help with kernel error message... (Brian C. Thomas)
Re: Registry for Linux - Bad idea (Frank Sweetser)
Re: Why I'm dumping Linux, going back to Windblows (Nick Andrew)
Pent II 450 system 82233 ([EMAIL PROTECTED])
Re: silly question (Tristan Wibberley)
Re: Registry for Linux - Why? (Christopher Browne)
Re: Registry for Linux - Bad idea (Christopher Browne)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Gady Kozma)
Subject: Re: Massive vfat memory leak?
Date: 4 Jan 1999 23:51:36 GMT
Waldek Hebisch ([EMAIL PROTECTED]) wrote:
: I run nightly a cron job liki this:
: - zero the vfat partiton
: - write first 2.5 Mb (boot + FAT + DOS) to device
: - mount the partition (mount -t vfat -o uni_xlate ....)
: - untar the backup copy (about 300Mb)
: - umount the partition
: The purpose is to "refresh" W95 instalation.
: Now is the problem - after the job ends `free' shows
: few megs less free memory, after some number of runs
: (of order ten) the machine runs out of memory. I was
: able to log in (in remainig free 1Mb) - it looks that
: memory is taken by kernel (cannot be atributed to a
: runnig process and appearently is unswappable).
: Just for test I tried:
: mount -t vat /dev/hda1 /dos_c
: ls -lR /dos_c | wc
: umount /dos_c
: on another machine - it seems that I lost 10Mb, however
: repeating the operation incurred only small additional loss.
: I am running 2.0.34 kernel from the RH 5.1 distribution.
I had a similar problem with 2.0.35
I upgraded to 2.0.36 and the situation improved drastically.
YMMV
Gady.
------------------------------
From: Steven James <[EMAIL PROTECTED]>
Crossposted-To:
alt.os.linux,alt.uu.comp.os.linux.questions,aus.computers.linux,comp.os.linux.development.apps,comp.os.linux.hardware,comp.os.linux.misc,comp.os.linux.networking,comp.os.linux.setup,comp.os.linux.x,fj.os.linux,h
Subject: Re: Where is the Console Driver Menu in Kernel 2.1.99?
Date: Mon, 04 Jan 1999 23:30:07 -0500
it's not there
try 2.1.132
ps- you have a voodoo banshee chipset?
George Thia wrote:
> I am unable to locate the Console Driver Menu in Kernel 2.1.99
>
> Can anyone help?
>
> Thanks!
------------------------------
From: George MacDonald <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Registry - Already easily doable, in part.
Date: Tue, 05 Jan 1999 05:21:22 GMT
Frank Sweetser wrote:
>
> George MacDonald <[EMAIL PROTECTED]> writes:
>
> > Doesn't even need to be Unix specific and the "Active" tends to indicate
> > other Microsofty type things(Active X, ...) so I would prefer not to
> > confuse people with that term. Other names I have thought of for a
> > project to do this:
> >
> > OpenStore - Shorter version opStore
> > OpenConfig
> > NetConfig
> > ConfigBase
> >
> > SNCP - Simple Network Configuration Protocol
> > NOCP - Network Object Configuration Protocol
> > CIB - Configuration Information Base -> Descriptions of schemas
> >
> > NOCS - Network Object Configuration System (Hmm I like this one)
> >
> > Thoughts?
>
> well, from what i gather so far, your idea is to have some kind of a
> configuration parsing engine taking input from various multiple
> sources... so how about Multple Source Configuration Engine? <G>
>
> more seriously, i kinda like NAOCS a little better - Network Aware Object
> Configuration System.
>
> two other random thoughts i just had wrt security -
>
> it would need a slightly different API for opening encrypted
> files/channels, as it should prompt for a passwd. you could have the
> library itself prompt for the credentials, but that could interfere with
> the program output...
>
That's assuming you need permissions other that the default, most typically
not. In other words a system admin could configure the security once for a
syste/user and the library automatically use the keys given.
If you are talking about one time passwd for a connect then, one could
add a seperate call to give the library a key for that session only.
The key would then go into the protocol stream as a security key
object.
> another good idea might be to have the ability to mark certain values as
> 'sensetive'. this could then place certain restrictions on how the library
> deals with it - for example, it might refuse to send it in plaintext
> accross the network, or save it in an unencrypted or world readable file.
Hmm yet more reasons for an external config description file, this is getting
more MIB like.
>
> anybody know of any good libraries to allow you to transparently open an
> encrypted file securely (no tmp files or anything), ala zlib?
If it's across a network then some kind of PGP mechanism. I was thinking
that in such cases the protocol stream could startup with
Hello I'm so and so
Here's my key
I'm going to encrypt using ...
Let's get down to business
Start of encrypted protocol objects.
If it's direct then one or more of the encryption libs/modules would do it.
I wouldn't want to bind to one specific encryption technique though.
--
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: Frank Sweetser <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Registry - Already easily doable, in part.
Date: 05 Jan 1999 00:47:56 -0500
George MacDonald <[EMAIL PROTECTED]> writes:
> > two other random thoughts i just had wrt security -
> >
> > it would need a slightly different API for opening encrypted
> > files/channels, as it should prompt for a passwd. you could have the
> > library itself prompt for the credentials, but that could interfere with
> > the program output...
> >
>
> That's assuming you need permissions other that the default, most typically
> not. In other words a system admin could configure the security once for a
> syste/user and the library automatically use the keys given.
okay, works for me. of course, those keys would have to be stored
locally. perhaps a global config file, read in by all calls to this lib,
would be prudent?
> If you are talking about one time passwd for a connect then, one could
> add a seperate call to give the library a key for that session only.
> The key would then go into the protocol stream as a security key
> object.
or perhaps use a callback to let the program obtain the credentials in
whatever manner it chooses (popup window for a gui, simple prompt for
command line util, etc).
> > another good idea might be to have the ability to mark certain values as
> > 'sensetive'. this could then place certain restrictions on how the library
> > deals with it - for example, it might refuse to send it in plaintext
> > accross the network, or save it in an unencrypted or world readable file.
>
> Hmm yet more reasons for an external config description file, this is getting
> more MIB like.
definatelly. hehe... how to configure the configuration =)
> >
> > anybody know of any good libraries to allow you to transparently open an
> > encrypted file securely (no tmp files or anything), ala zlib?
>
> If it's across a network then some kind of PGP mechanism. I was thinking
> that in such cases the protocol stream could startup with
>
> Hello I'm so and so
> Here's my key
> I'm going to encrypt using ...
> Let's get down to business
>
> Start of encrypted protocol objects.
perhaps a look at ssh would be in order.
> If it's direct then one or more of the encryption libs/modules would do it.
> I wouldn't want to bind to one specific encryption technique though.
agreed. of course, at that point, export laws come into effect... anybody
from outside the US or any other such country with brainded export laws
willing to contribute here?
--
Frank Sweetser rasmusin at wpi.edu fsweetser at blee.net | PGP key available
paramount.ind.wpi.edu RedHat 5.2 kernel 2.2.0pre3 i586 | at public servers
Sam: Hey, how's life treating you there, Norm?
Norm: Beats me. ... Then it kicks me and leaves me for dead.
-- Cheers, Loverboyd
------------------------------
From: [EMAIL PROTECTED] (Derek B. Noonburg)
Subject: Re: GUI, The Next Generation
Date: 5 Jan 1999 00:16:01 -0600
"Glen Parker" <[EMAIL PROTECTED]> writes:
> I know this isn't very 'blue sky', but one idea I've had lately is the idea
> of translucent windows. All windows would look like a colored pane of
> glass, with modal windows being more transparent than main windows, so you
> could see what's below it without having to move it.
Hey, I like this idea, but with a different twist. I tend to open up
lots of windows, and I always end up "losing" the ones in back. How
about making all but the active window translucent? Then when you
shift-left-click (or whatever) on a title bar, even if there are other
windows in front of it, it brings that window (the one whose title bar
you clicked) to the front.
This needs some tweaking -- modal windows (dialogs) might be
translucent, with their parent window remaining opaque. And I'd want
some way to quickly toggle transparent/opaque-ness on a non-front
window (another mouse binding, maybe), since I often want to be
looking at or typing in a non-front window, while also working in the
front window.
Hm, now I'm not sure if it should be the front window or the active
(keyboard focus) window that's opaque.
Or how about this: holding down that useless left-windows key (on new
"Win95 keyboards") would instantly turn all windows translucent. Then
I could find what I was looking for, click on its title bar, and bring
it to the front. Letting go of the window key would turn everything
back to normal (opaque) again.
Anyway, cool idea.
- Derek
------------------------------
From: Edward Lee <[EMAIL PROTECTED]>
Subject: Re: Kernel v2.2
Date: Mon, 04 Jan 1999 17:53:31 -0800
[EMAIL PROTECTED] wrote:
> Martin Bahlinger <[EMAIL PROTECTED]> wrote:
> > Does anybody know, how long we've to wait for the new Linux kernel ??
> > BTW: Is it called v2.2 or v3.0 ???
>
> > Martin B.
>
> Why don't you try 2.1.132 or the latest 2.2.0pre1 ? I use 2.1.132 without a
> problem with a debian instalation
>
> bye
>
> http://student.dee.uc.pt/~slug
Where did you get the modules package to compile 2.1.132?Did you find a newer
modules package in debian somewhere?
I need the "-k" option of genksyms in the modules package.
With modules-2.0.0 (in sunsite & tst-11 mirrors), i can't even compile the
kernel.
------------------------------
From: Todd Knarr <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Registry - Already easily doable, in part.
Date: 5 Jan 1999 01:57:29 GMT
In comp.os.linux.development.system Andrew Morton <[EMAIL PROTECTED]> wrote:
> 1: They're Linux specific.
No, they're specific to the class of systems that have a filesystem
with a namespace conforming roughly to Unix conventions ( 255 characters,
extensions not special, optionally case-sensitive ).
> 2: They're "single system centric" (tm). We need to pay more
> recognition to the requirement that reconfiguration of applications is
> an enterprise-wide function. The rdist approach is klunky (how do I
> simply change/propagate a single line of config?)
For single-line changes, you rdist the appropriate sed script and apply
it. For machines with truly common configurations there exists this
thing called a network file system, although as with any non-local config
source you have the problem that, when the network is down and the
non-local config source cannot be reached, everything on the network
stops dead ( which is _not_ graceful degradation of service by any
definition ). And I have seen very few systems in reality that have a
single enterprise-wide configuration. More often you have multiple
configurations which need applied to multiple sets of machines, with
noticeable overlap between configurations and sets of machines but not
enough to actually combine either.
Part of the problem is that I work in an environment where all of the
machines I normally deal with are either several steps ahead of the
rest of the company ( developing the software that will be rolled out
in 6-12 months ) or several steps behind the rest of the company ( the
configuration and versions being determined by what critical software
needs to have to run rather than what the latest version is ).
> 3: They do not provide for notifications to running applications.
This is a good thing. As noted a while back, it is very common to make
several changes in several steps and test them on one machine before
committing all machines to using them. This is usually best handled by
having the applications only re-read config data when told to. Automatic
detection or notification has a nasty tendency to re-read the data when
you have almost but not quite finished with all the changes, leaving the
application in a state which is almost but not quite entirely unlike any
it ought to be in.
--
We won, didn't we? Cope!
-- Mimi, Reality Check #8
------------------------------
From: SONE Takeshi <[EMAIL PROTECTED]>
Crossposted-To: comp.os.ms-windows.programmer.nt.kernel-mode
Subject: Re: WDM Emulator, anyone?
Date: Tue, 05 Jan 1999 15:25:09 +0900
I used to think of kernel-level NT emulator for linux.
One part of it is PE EXE/DLL loader, which is rather trivial.
The other part is NT system call handler.
AFAIK, all NT API call become INT XXh kernel call (through NTDLL.DLL
etc).
They can be handled by a kernel module.
This part, NT kernel emulator, naturally becomes the layer to help NT
drivers to run.
Inaki Castillo wrote:
>
> > Actually, WDM starts with the NT Driver model. We would probably start
> > with the NT DKK.
> >
>
> Have you any idea of what are you saying ?
>
> NT DDK is nothing by itself, you should reproduce all NT Kernel
> components to do any simple piece of driver to work. That is all the
> operating system. Win32 is in fact a layer above that.
>
> Maybe is better to move to NT.
--
SONE Takeshi そね たけし
mailto:[EMAIL PROTECTED] Office Craftsman Arts
http://www.cma.co.jp/~ts1/
------------------------------
From: [EMAIL PROTECTED] (Brian C. Thomas)
Subject: Help with kernel error message...
Date: Mon, 04 Jan 99 18:10:19 GMT
Hi all,
I am running 2.2.0-pre4. In my syslog file, I am getting this error
intermittantly, but persistantly...
darkstar kernel: Symbol table has incorrect version number
Can anyone explain this to me, and perhaps a way to get it fixed?
Thanks,
bct
------------------------------
From: Frank Sweetser <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: 05 Jan 1999 02:05:56 -0500
George MacDonald <[EMAIL PROTECTED]> writes:
> > hrm... okay. so this would then require 1) some way of logically combining
> > multiple files in to a single 'virtual' config, and 2) locking the entire
> > group, making sure that there are no files shared between that group and
> > any other groups that are locked... could be hairy with files, should be
> > easier with databases, no idea about CORBA :P
> >
>
> Could create a new hierarchy with just the changes. Then push the changes
> in the front of a path of configs to merge together. Then only have to worry
> about someone else creating another branch at the same time. Could
> allow either locking or open changes with a merge done automatically
> and user notified on conflicts(or let latest save win a conflict).
>
> This is the stuff of DB table/row locking and commit/rollbacks. All
> of which can be done in a fs using cow, lockfiles, ... The biggy
> is having at least one kind of atomic operation i.e mv or rename.
> Of course it's way slower on a fs, but we are talking user speeds
> for the most part. If the need is really there, i.e large systems/
> networks or many config changes then use a DB &/CORBA.
that works. inefficient on FS stuff, but if you need effeciency you should
be running it on a DB (or something similar) anyways.
> > hmm... so, are you suggesting that in addition to the config data, certain
> > components would also contain code for configuring that code? <hmm...> if
> > the library could deal with raw binary data, then it could be treated as
> > just another configuration entry.
>
> It doesn't have to be binary data, all binary data can be represented as
> ASCII. Remember one of the goals is to make the config info
> understandable to users. I am thinking the data can be typed or
> more appropriately "classed". i.e. the config files contain chunks
> of persistent config objects.
>
> Lets say one of the attributes is a color, then it would be nice to
> have a color selector component that could be used when a user
> decides to set a color preference. It would be one less thing for
> developers to develop again and again. In fact I think GNOME
> has something like this.
herm.... okay, i think i've got you. an independant program associated
with the value, right? so rather than storing the actual exe in base64 as
a perl script, simply store the name of a local exe (which also solves the
problem of having one that works on different platforms). have i got you
right?
> > > to put togther a feature list ... See
> > >
> > > http://at.home/gmd/opStore/
> >
> > this web site doesn't seem to be up ATM.... :(
>
> Oops should be
>
> http://24.1.97.22/gmd/opStore/
aha, i see what happened - i tried http://24.1.97.22/gmd/opStore which in
turn gives a 301 permenantly moved to http://at.home/gmd/opStore/ which in
turn doesn't work.
read it over, looks pretty good to me. suggest the next steps are to start
defining 1) data types 2) the library API 3) the config module API and 4)
the flat text file format.
> > > http://24.1.97.22/gmd/tps/treepsfm.html
> >
> > and neither is this one :(
>
> Hmm, that one should be. Could you try again and let me know? I check the
> log and got some hits today and the server seems ok just now.
works now... must have mistyped it earlier =(
> Are you familiar with X resources? How about ini file formats?
> I am much more familiar with X resources than ini file format,
> and realize they are not the easiest to understand.
not really... mind explaining it? =)
--
Frank Sweetser rasmusin at wpi.edu fsweetser at blee.net | PGP key available
paramount.ind.wpi.edu RedHat 5.2 kernel 2.2.0pre3 i586 | at public servers
Sam: Hey, how's life treating you there, Norm?
Norm: Beats me. ... Then it kicks me and leaves me for dead.
-- Cheers, Loverboyd
------------------------------
From: [EMAIL PROTECTED] (Nick Andrew)
Crossposted-To: alt.os.linux,comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Why I'm dumping Linux, going back to Windblows
Date: 5 Jan 1999 18:22:38 +1100
In <[EMAIL PROTECTED]> [EMAIL PROTECTED] (Mike) writes:
>I'm sorry! But this sentiment on the user interface is simply
>nonsense. Wanting to learn or use "vi" as opposed to something like
>super note tab is like wanting -- insisting-- on using a rock instead
>of a hammer to do your cabinet making.
In that case, I insist that all my rocks have functionality equivalent to
vi(1).
Nick.
--
Zeta Internet SP4 Fax: +61-2-9233-6545 Voice: 9231-9400
G.P.O. Box 3400, Sydney NSW 1043 http://www.zeta.org.au/
------------------------------
From: [EMAIL PROTECTED]
Subject: Pent II 450 system 82233
Date: Monday, 04 Jan 1999 20:50:32 -0600
Reply-To: [EMAIL PROTECTED]
Hello I have some 36bit 600x1200 scanners that i want to sell. Along with vidoe cards
netwoking few other things
you can see the list of things i have at
http://members.xoom.com/RajLamba/comp.htm
copy and paste the address.
You are welcome to make an offer to me on any of those prices I will try my best to do
whatever i can for you
Thank you.
Raj
6-_
------------------------------
From: Tristan Wibberley <[EMAIL PROTECTED]>
Subject: Re: silly question
Date: Tue, 05 Jan 1999 02:46:44 +0000
Reply-To: [EMAIL PROTECTED]
David B Anderson wrote:
>
> In article <[EMAIL PROTECTED]>,
> mlw <[EMAIL PROTECTED]> wrote:
> >Peter Pointner wrote:
> >>
> >> mlw <[EMAIL PROTECTED]> wrote:
> >>
> >> > Actually, I would love to see Xcopy on Linux. "xcopy /s /e /h /c this
> >> > there" would be great.
> >>
> >> I can't remember all the options, but are you sure "cp -a" doesn't do
> >> what you want?
> >>
> >> Peter
> >
> >I have looked, maybe I am dense, but, I would like to do something like:
> >
> >xcopy *.cpp -s -e -h -c ../anotherdir
> >
> >This will copy all of the files that end with .cpp to another directory,
> >recreating the directory structure with them. If an error happens it
> >will continue.
> One can do this sort copy with
> find(1) and a bit of shell scripting (I claim), so one need not
> write this sort of copy facility in C (perl or sh will do
> (again, the same claim)).
Easiest done using tar (ie [pseudocode] 'tar -options `find files` |
untar -options location')
--
Tristan Wibberley Linux is a registered trademark
of Linus Torvalds.
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Subject: Re: Registry for Linux - Why?
Date: 5 Jan 1999 02:46:21 GMT
Reply-To: [EMAIL PROTECTED]
On 3 Jan 1999 06:25:22 GMT, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>Christopher Browne <[EMAIL PROTECTED]> wrote:
>
>>>I think if it's done right it could be an incredible asset to Linux. Something
>>>that can take alot of the confusion out of configuring a UNIX system. If it's
>>>all in one place, you already know where to look when something's wrong. (of
>>>course having the data in a single file a la windows is IMHO a VERY BAD
>>>idea.) No one has to use it if he/she does not want to.
>
>Maybe I'm a snob, but I don't think it's wise or nescissary to "dumb-down"
>our OS or how to configure it. System admins aren't stupid; They may
>forget where to find a config file on occasion, but they all know how to use the
>man pages and do a quick search for the "FILES" section. It's really pretty
>easy... /etc for system stuff, ~username/.applicationrc for user apps,
>app-defaults for X-Windows system level stuff, .Xdefaults for user X
>defaults... /usr/local/lib/ or /usr/local/shared for installed stuff...
>Okay... there's a few choices... but nearly all apps, tell you in the man
>pages, where the default config file is, and where the user-level file is.
>So is there really that big of a problem?
>
>> It would thus be appropriate to provide a Sample Implementation that
>> clearly defines a combination of:
>> - API (so that applications may conveniently get at config data without
>> having to worry about Physical Representation),
>> - Specification of Physical Representation, so that Alternative
>> Implementations may be created and validated.
>> (Suppose, for instance, that the SI is a C version, and I'm using
>> [Perl|Python|Scheme|ML|...] and don't want to link in the SI code...)
>
>I really think that using an API call to get this config info is a bad
>idea... I think this information would best be served in a plain text
>file... so it can be edited with scripts, and FIXED with text-editors.
The benefit of having an API *available* is that it allows applications
to request updates without having to intrusively add in parsers and the
like.
If [Pick Favorite Application] needs to do some keyed lookups of
configuration data, it is a nice thing to be able to have the
application do something like:
#include <configlib.h>
#define APPLICATION "foo"
void main() {
config_ptr config;
config = open_config(APPLICATION, USERCONFIG, RO);
if (config) {
/* Now look up a bunch of things... */
a = config_lookup (config, "HOME");
b = config_lookup (config, ...);
}
}
I. The first point is that the purpose is *not* to force a library on
people, but rather to provide a useful abstraction that lets them worry
more about making the application do useful things, and less about
parsing config files.
II. The second point of using an API is to provide some guidance as to
behaviour and not merely on format.
III. The third point of the API is to provide a scheme that can be
indirected so as to grab config data via a variety of mechanisms. Thus,
the same API might be, with suitable arguments, usable assortedly with:
a) A text-based config file sitting in /etc
b) A text-based config file sitting in $HOME/etc
c) A binary-database-based config file sitting in /etc
d) A binary-database-based config file sitting in $HOME/etc
e) A configuration system sitting on another machine, being accessed
via [CORBA|NIS|YP|Other network protocol]
IV. Fourthly, it might very well be that we would want to consult *ALL*
of the mechanisms suggested in the third point in order to provide an
application with its configuration information.
X resources are a prime example of something where configuration can
come from a whole variety of places.
If we don't have some common "helper," then each application has to
independently reinvent this sort of functionality. It's not so bad if
configuration for a subsystem only exists at one level, but if there is
going to be configuration that we expect to be provided at an
assortment of "levels" such as:
- Host-based (e.g. - if you're on ncdterm.brownes.org, there is only
8 bit graphics available)
- Network-based (e.g. - everyone on this network segment should go to
cache.brownes.org to get HTTP and HTTPS requests)
- User-based (e.g. - My favorite color scheme is [Chris's Wild
Colors])
then it is real nice if we can manage this information in common ways,
thereby allowing what learning I do in figuring out how to configure one
application to be useful when I go to another application.
The point is not to constrict things, forcing everything into a single
database, but rather to open up access, allowing a single scheme to
allow access to data in the variety of locations and formats that are
likely to prove necessary.
--
Microsoft Corp., concerned by the growing popularity of the free 32-bit
operating system for Intel systems, Linux, has employed a number of top
programmers from the underground world of virus development. Bill Gates
stated yesterday: "World domination, fast -- it's either us or Linus".
Mr. Torvalds was unavailable for comment ... ([EMAIL PROTECTED]
(Robert Manners), in comp.os.linux.setup)
[EMAIL PROTECTED] <http://www.ntlug.org/~cbbrowne/lsf.html>
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: 5 Jan 1999 02:47:18 GMT
Reply-To: [EMAIL PROTECTED]
On 4 Jan 1999 11:23:38 -0700, Craig Kelley <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
>Andrew Morton <[EMAIL PROTECTED]> wrote:
>->The Unix model of:
>->
>->- Every app has its own config file
>->- Every app has its own code to read that file
>->- Every app needs a restart when something changes (or SIGHUP: almost
>->the same thing)
>->- Config is local to this host
>->
>->is _extremely_ dated, unwieldy, unscalable and expensive. It's
>->unreliable and requires excessive administration and training resources.
>
>And yet nobody has been able to come up with anything better.
Indeed.
There have been attempts at alternative solutions.
- We have the morass that is the Windows Registy.
- HP's "SAM" is pretty cool, but, like Linuxconf, seems mostly to hide
behind the scenes what it's doing with your configuration.
- IBM's "SMIT" does decent logging of what it's doing, and can thus be
instructive to the new administrator to indicate how it reconfigures
those things that you select.
- I'm not sure if either SAM or SMIT are particularly extensible; that
is one thing that Linuxconf offers that is nice.
>As for it being expensive for "administration and training resources",
>I have one word: linuxconf. I think you will be very surprised when
>RedHat 6+Gnome+linuxconf hits the shelves.
>
>Linuxconf already works just fine, and it has managed to centralize
>more configuration information in one easy-to-use place than Microsoft
>has ever dreamed of (SMC is just a ghost of what linuxconf can already
>do).
What has changed lately? I've got a *fairly* recent edition of
Linuxconf on one of my boxes, and am not finding my "socks blown off" by
it.
The "problem" is that there are a number of secondary services that it
needs modules for, such as sudo, perhaps xauth, and other "role
modification" tools.
--
In a world without fences, who needs Gates?
[EMAIL PROTECTED] <http://www.ntlug.org/~cbbrowne/lsf.html>
------------------------------
** 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
******************************
