Linux-Development-Sys Digest #215, Volume #6 Mon, 4 Jan 99 22:14:19 EST
Contents:
Re: silly question ("mkf")
Re: Why I'm dumping Linux, going back to Windblows (Marco Anglesio)
Re: Registry for Linux - Bad idea ([EMAIL PROTECTED])
Re: Registry - Already easily doable, in part. (George MacDonald)
Re: silly question (David B Anderson)
Re: Organizing Application Files/Config Info (Registry Unix Style) (George MacDonald)
----------------------------------------------------------------------------
From: "mkf" <[EMAIL PROTECTED]>
Subject: Re: silly question
Date: Mon, 4 Jan 1999 11:44:17 -0800
heres something youre not used to either. aliasing. just alias all the
utilities to dos names and your dos infection will be cured. of course we
have all gone through the wish-it-was-like-this-and-wish-it-was-like-that
stage. its called kernel hacking give it a go :D mike
------------------------------
From: Marco Anglesio <[EMAIL PROTECTED]>
Subject: Re: Why I'm dumping Linux, going back to Windblows
Crossposted-To: alt.os.linux,comp.os.linux.development.apps,comp.os.linux.setup
Date: Mon, 04 Jan 1999 19:52:53 GMT
In comp.os.linux.development.system J?rgen Exner <[EMAIL PROTECTED]>
wrote:
> Try Slackware.
> To my knowledge this is the only distribution which still can be installed
> from floppy only.
The base Debian distro is on five floppies. And it doesn't really matter
to dpkg/dselect where the rest of the packages that you want comes from.
marco
--
Marco Anglesio Like Captain Idiot
mpa at the-wire dot com in Astounding Science comics
http://www.the-wire.com/~mpa (The Manchurian Candidate)
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: Mon, 04 Jan 1999 19:21:50 GMT
In article <[EMAIL PROTECTED]>,
Robert Krawitz <[EMAIL PROTECTED]> wrote:
>
> Do you refer to central storage of (at least some of) the information,
> or a centralized representation of it? If the former, I have no
> quarrel with central storage of hostname, account, and such
> information; that's what NIS, DNS, and friends are all about. But
> that has nothing to do with how easy it is for a non-expert to manage
> single system at home.
My experience with YP is limited, I do have experience with NIS+, but I have
found that although NIS and friends are centralized, they are not really
browseable. Niscat and nismatch are nice, but they dont give you a well
definied hierarchy, or an intuitive organization. Personally I've never seen
an NIS+ installation that does not leave the old text files around (in case
of failure?) which further confused the problem.
>
> If you're talking about centralizing the representation of the
> information on a single machine, though, I can't agree with you. I'd
> like to understand why you believe it to be necessary, though, as
> opposed to a centralized interface that understands all of the various
> configuration files and has a plugin interface to allow additional
> modules to be added for new programs.
Why develop plugins if it can be changed and/or standardized so that
configurations are all handled in a common way? Making plugins is just
layering more complexity onto the problem. What happens if a program changes
but the plugin does not? Why not avoid the plugin altogether and speak
directly to linuxconf? A centralized interface is nice, now imagine how
quickly new software can be integrated into it if the data was centralized as
well. Something like linuxconf will impede flexibility if the plugins are not
up to date, or if a software package does not have a plugin.
>
> A central configuration database is neither necessary nor sufficient
> to do this. Regedit on Windows (just as an example) is the ultimate
> tool for manipulating the registry, but nobody claims that it makes it
> any easier to use.
Regedit does not offer human readable keys, I'm sure some people know what
HKEY_LOCAL_USER\FOO\BAR means, but it's hardly more readable than an old .ini
file. If it were MY_COMPUTER\NETWORK\DEVICES\PRINTERS and then regedit was
able to spawn the apropriate configuration utility for each printer listed
(if applicable) it would be easier to use. Windows is designed to deny that
ability to users, Linux does not have to be. The central config database
would not provide any ease-of-use in and of itself, but it provides a
mechanism such that netscape plugins or linuxconf, or emacs or whatever can
hook directly into the config information easily.
Some people have talked about organizing information in a filesystem like
structure where there's a defined hierarchy. This is exactly the kind of
thing that can help people. Users already know how to use a filesystem. As
long as the folders and files are intuitive and/or well documented the
browsing mechanism of choice alread provides the interface. Of course this is
just an example, but what I am getting at is there are things that people can
easily understand given the correct information.
-Rich
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: George MacDonald <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Registry - Already easily doable, in part.
Date: Mon, 04 Jan 1999 21:16:21 GMT
Andrew Morton wrote:
>
> May I point out some shortcomings of the filesystem-based approaches?
>
> 1: They're Linux specific.
>
> 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?)
>
> 3: They do not provide for notifications to running applications.
>
> Let's stop thinking "Linux registry" and start thinking "Unix Active
> Directory".
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?
--
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] (David B Anderson)
Subject: Re: silly question
Date: 4 Jan 1999 21:18:31 GMT
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.
By default, UN*X shells expand wildcards when seen and
applications (like cp) assume the wildcards are expanded.
If xcopy were implemented to understand expanding its own
wild cards (in some app-specific fashion),
in many shells one could do
xcopy \*.cpp -s -e -h -c ../anotherdir
as the backslash would prevent expansion (in csh/sh shell
families at least) so the *.cpp would be literally passed to xcopy.
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)).
Perhaps this hint is enough.
Regards,
David B. Anderson [EMAIL PROTECTED] [EMAIL PROTECTED] http://reality.sgi.com/davea/
------------------------------
From: George MacDonald <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Organizing Application Files/Config Info (Registry Unix Style)
Date: Tue, 05 Jan 1999 01:46:41 GMT
Andrew Morton wrote:
>
> George,
>
> You'll save mankind if you can pull this off.
>
> This topic is being discussed on the gnome mailing list and has spun off
> into another mailing list at mailto:[EMAIL PROTECTED] - just put
> 'subscribe' in the subject.
>
> A basic web page is at http://www.thestuff.net/libcfg
>
> Personally, I think you're a bit too file/directory based. I'd prefer a
> client/server model with, presumably, CORBA. With the appropriate API
> wrappers this would be indistinguishable for those apps which only need
> startup config.
>
That's actually pretty close to what I was thinking, except I want to
start with a file based system and a simple library.
The file based mechanism is for simple apps that only want to deal
with files. The advantage of this approach would be to make it easy to
get started, Later developers can migrate to a more object/component
based approach and eventually CORBA. In fact this can be made transparent,
i.e. a simple library can use CORBA with the flick of a switch. My
desire is to start simple and allow for the complex/rich config service
to develop over time.
b.t.w. Thanks for the links.
> I think the oft-stated requirement that everything be in text files to
> leverage grep/sed/awk/etc is a red herring. All that is needed is a tool
> which can extract and insert a section as text:
>
> get_registry_section fstab | sed -e "s/foo/bar/" | set_registry_section
> fstab
>
> end of argument?
While it might be nice to do as you suggest, I doubt you will get very far trying
to remove the existing flat files. They are simple and well entrenched.
I want to wrap app config in the same manner as linuxconf, well perhaps
a bit more object oriented. A three tier architecture will support all
the requirements, anything else is taking a swipe at just part of the
problem. Most all of the features described are already done by
various tools/methods, so the only way to progress is to do a
better more complete job. A MS style registry does not solve many
of the problems. In fact the solution I am talking about would ultimately
replace the MS registry, i.e. it's a more complete solution.
>
> And something you appear to have not addressed: how do we retrofit this
> uniform mechanism to legacy apps? We need a mechanism for a machine's
> config interface to be used for administering, say, /etc/fstab without
> changing mount, swapon, NFS, etc.
The system side I was talking about would be similar to linuxconf(
note I was not aware of it when writing the article below). My
natural inclination would be to see if linucconf can be extended to
perform the desired functionality. Linuxconf already wraps the
files/programs you talk about and does so much in the manner
I was thinking about. It would be nice to extend this service
to applications and user application config files. I am not sure
if the architecture of linuxconf would allow for that though(need
to investigate it some more).
>
> George MacDonald wrote:
> >
> > A Proposal for organizing application files and config info
> > -----------------------------------------------------------
> >
> > The Problem
> > -----------
> >
> > A recent check of my home directory counts over 40 application specific
> > files and directories. It's beginning to get so crowded that I have
> > a hard time finding my own files that *I* put there. I can't
> > even type "vi .pr*" and edit my profile any more!!!! Arrggghhh!!
> > Me thinks there has to be a better way!
> >
> > I am also developing an application that needs a lot of configuration files,
> > many of which may be overriden at run time by a user. After checking
> > around a bit for a common way to do this, I find there isn't one.
> > Well I suppose the "common" way is to create a ".app_name" file or
> > a ".app_name" directory. But this only seems to add to the above problem,
> > and well I don't particularly want to do that! A secondary problem is
> > that there is no common format and no library that I can use, so I
> > have to spend time to develop one.
> >
> > Anyhow, there has been this huge thread recently in some of
> > the comp.os.linux.* newsgroups regarding a Registry for Unix.
> > While I could write volumes about why the "MS Registry" is not a
> > suitable solution for Unix/Linux. I thought I would offer a
> > Unix/Linux way of achieving the same thing. As it turns out
> > this also solves the overcrowding in $HOME and gives me somewhere
> > nice to put my new applications config files.
> >
> > So here goes, it's kind of long, as the solution described is
> > laid out in a planned implementation. I'm going to start implementing
> > this next week, unless a better solution is available or someone is
> > already working on one. Comments/help are welcome, I'm open to
> > suggestions and to organizing an "OpenProject" if it's appropriate.
> >
> > Some comments on how GNOME/KDE do user side storage would be welcome,
> > this proposal would encompass both of those as well as any other app.
> >
> > I setup a web site to track this proposal/project at:
> >
> > http://24.1.97.22/gmd/opStore/index.html
> >
> > Summary of Proposal (A MS Registry? Well perhaps a better Solution!)
> > -------------------
> >
> > Phase I - A user specific, quasi "object oriented", persistent storage
> > mechanism based on flat files in a directory structure located
> > in user space(Under the users home directory). i.e.
> >
> > $HOME/.userStore/organizations/${org_name}/...
> > $HOME/.userStore/packages/${package_name}/...
> > $HOME/.userStore/applications/${app_name}/...
> > $HOME/.userStore/components/${component_name}/...
> >
> > Phase II - Config file format and interface library's for user store.
> >
> > Phase III - A similar system for applications files at a system level.
> >
> > $SYS_STORE/organizations/${org_name}/...
> > $SYS_STORE/packages/${package_name}/...
> > $SYS_STORE/applications/${app_name}/...
> > $SYS_STORE/components/${component_name}/...
> >
> > Phase IV - Extend libraries to also work with system level app files
> >
> > Phase V - Develop a userStoreCache helper process to make the
> > user driven part faster. Perhaps creating a registry
> > like tree that get's mmap'ed into an application.
> > Library will handle syncronized changes.
> >
> > Phase VI - Develop a System level helper process to make system
> > level access faster. Create a system part of the
> > tree and likewise allow it to be mmap'ed into
> > an app. Taking care of permissions, syncronization,...
> >
> > Phase VII - Add CORBA support, i.e. add ORB's to helper processes
> > and allow CORBA invokations for store/retrieve service.
> >
> > Phase VIII - Add persistent storage to RDBMS, OO-RDBMS i.e. allow
> > helpers to replicate storage to other storage structures
> > from flat files.
> >
> > Proposed Phase I Solution
> > -------------------------
> >
> > My proposal is that we push down users application files into a more
> > organized directory structure. At the top of this structure is the
> > directory called ".userStore", named to indicate a users persistent
> > storage. You will notice the OO(Object Oriented) terminology, this is
> > done to acknowledge the comming wave of component based applications.
> >
> > A brief analysis of the current set of application files/directories under
> > *my* home directory reveals the following usages:
> >
> > Application configuration files - user controled via editors
> > Saved settings - application controlled
> > Saved context - i.e. history, session variables, ...
> > Temporary work files - journaling files, cache, ...
> >
> > The vast majority seems to be static config files, although
> > lately I have seen an increase in application controled config
> > files.
> >
> > On thinking about the application related configuration a
> > number of natural classifications arise. i.e. There appears
> > to be the following ways in which configuration setting can
> > be "classed":
> >
> > Applications
> >
> > Packages
> >
> > Organization
> >
> > Components
> >
> > Applications
> > ------------
> >
> > Many applications, or individual programs, use config files.
> > They include programs like:
> >
> > screen -> .screenrc
> > bash -> .bashrc
> > ddd -> .ddd
> >
> > Some applications are more complicated and use several files, such
> > as:
> >
> > X -> .Xinit, .Xauthority, ...
> >
> > Others use directories, such as
> >
> > ncftp ->.ncftp
> > mc ->.mc
> >
> > My thinking is that these applications related files could be organized
> > into a directory called
> >
> > $HOME/.userStore/applications/${app_name}
> >
> > Where ${app_name} is the name of the application. Further I
> > would suggest an additional level in each app directory to differentiate
> > between versions of the application. i.e.
> >
> > current - A symbolic link to a specific release directory
> > 1.0.2 - A specific release
> > 1.0 - A previous release
> >
> > This will allow updated applications to be installed without
> > wiping out a users previous settings, and at the same time
> > allow the user to backup to a prior release if desired. A new
> > release of an application could perform a copy/merge of prior settings
> > the first time the user runs it. At a later date the user can
> > deprecate the previous release files, either manually of via
> > an option in the program.
> >
> > Packages
> > --------
> >
> > A number of people put together groups of applications into
> > packages. Sometimes these packages share configuration/work files
> > between one or more of the applications. Some examples
> >
> > GNOME ->.gnome
> > netscape ->.netscape
> >
> > Such common files could be put in a structure such as:
> >
> > $HOME/.userStore/packages/${package_name}
> >
> > Where package name is a directory named for the package. Again
> > an additional level to manage releases might be quite useful.
> > e.g.
> >
> > current -> 1.0 Symbolic link to latest release settings
> > 1.0 The user related files for release 1.0
> > 0.99 User files for release 0.99
> >
> > Organizations
> > -------------
> >
> > Likewise there are a few organizations that put together
> > many applications and packages. These organizations could
> > create user specific files that are shared across packages
> > and applications. Examples of such organizations are:
> >
> > GNU
> > KDE
> >
> > This could be represented in the following manner
> >
> > $HOME/.userStore/organizations/${org_name}
> >
> > Where ${org_name} is a directory for the organization
> > containing user related files for apps/packages from
> > that organization.
> >
> > Components
> > ----------
> >
> > The desire to leverage software development has culminated in the
> > development of components. The level of abstraction achieved by this
> > allows tremendous improvements in productivity. With the introduction of
> > GNOME and KDE, the component model has taken hold on Linux and undoubtedly
> > will continue to grow in leaps an bounds. For example imagine if a file
> > selector component were being used by ALL applications. If someone decided
> > to write a new files selector, say one with history, favorite places, ...
> > then all you would have to do to include it in ALL your component
> > based applications would be to set a simple configuration option!! No
> > re-development, re-compilation, re-download, re-install, just a one
> > line config change!! Now that's leverage big time!! So where's a user
> > to configure such a thing? Glad you asked, why in
> >
> > $HOME/.userStore/components/${component_name}
> >
> > of course. In particular the file selector attributes would go in
> > the directory:
> >
> > $HOME/.userStore/components/fileSelector/...
> >
> > The file selector could store history, favorite places, ...
> > in this space. As with the above examples I would recommend
> > at least one more level under the component directory to
> > manage multiple revisions of the component related files.
> > In this manner new components could be safely tried with
> > a user secure in the knowledge that they can backup if
> > desired.
> >
> > Further Development
> > -------------------
> >
> > Phase I is simply a matter of adopting a common convention, i.e.
> > anyone could decide to start doing it right now. If I can't find
> > any current/planned solution that addresses the stated needs then
> > I will start using it next week. I will also start "pushing"
> > it as a solution to the stated problems.
> >
> > Further phases of development would likely take me 6 months or
> > more, as I plan on working on my application at the same time.
> > If others want to help then that could lessen the time to
> > develop the libraries ...
> >
> > About me:
> > --------
> >
> > I have been developing Unix software for 18 years now, with
> > an emphasis on graphics, X/Motif, networking, telecom apps.
> > I have also done a fair amount of system/network admin work.
> > Most recently I just contributed a freeware application
> > called treeps(1) to the available tool set for Linux.
> >
> > More details about me can be found at:
> >
> > http://24.1.97.22/gmd/index.html
> >
> > --
> > 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)
--
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)
------------------------------
** 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
******************************
