Linux-Development-Sys Digest #251, Volume #6 Sun, 10 Jan 99 16:14:36 EST
Contents:
Re: Organizing Application Files/Config Info (Registry Unix Style) (Andrew Morton)
KDE Survey ([EMAIL PROTECTED])
Re: disheartened gnome developer ([EMAIL PROTECTED])
VM_MAYWRITE (Ganesh Venkitachalam)
Re: disheartened gnome developer (Martin Maney)
Re: disheartened gnome developer (Christopher B. Browne)
Re: Open Configuration Storage - was Registry for Linux (Leslie Mikesell)
Re: Open Configuration Storage - was Registry for Linux (Frank Sweetser)
Re: Why I'm dumping Linux, going back to Windblows (Leslie Mikesell)
Re: Dumb kernel question. (TGAPE!)
----------------------------------------------------------------------------
From: Andrew Morton <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Organizing Application Files/Config Info (Registry Unix Style)
Date: Tue, 05 Jan 1999 00:20:14 +1100
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.
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?
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.
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)
------------------------------
From: [EMAIL PROTECTED]
Subject: KDE Survey
Date: Sun, 10 Jan 1999 19:00:00 GMT
Hello,
A few weeks back I posted an announcement about a KDE Survey.
Since then I got several people who have answered my call and who have
filled in the survey. However, due to a computer problem, I have lost about
85% of the results of the survey.
I have reinstalled the survey at the following location:
http://www.wina.student.kuleuven.ac.be/~bavo/kde-survey/survey.html
So, *please*, spare another 10 minutes of your time filling in this survey.
I need the results for a project of mine (computer science course).
As previousle mentioned, I will put the results of the survey online in one or
two weeks.
Bavo De Ridder
Bruno Ballekens
Geert Delanote
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.x
Subject: Re: disheartened gnome developer
Date: Sun, 10 Jan 1999 18:58:22 GMT
In article <77afhd$tcj$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Tim Smith) wrote:
> In article <777pr8$bve$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
> >Remember Jedi, free software is not a spectator sport, and you are
> >standing outside of the field, throwing beer cans to the players.
>
> Go look him up on DejaNews, and you'll find a post where he comes out and
> admits that he's going to attack KDE and Qt every chance he gets, no matter
> what changes are made to the licensing. It's pointless to try to argue
> with him on this topic, so just killfile him--you actually produce free
> software, so shouldn't let non-producers drag you into their pointless
> arguments.
I agree on principle, but... well, one of the reasons I write free software
is because I think cool people will use it, and I am, so to speak putting
my 2 cents worth to help the same community that has provided me with a lot
of very useful things.
So, I feel really bad, almost phisically ill, when I see people like Jedi who
just spit on it while at the same time posturing as a part of that community.
I get this feeling that if I don't reply his opinions may stick on some
innocent folk. Goebbels-like, if you remember that "lie, lie ..." quote.
I suppose I'm a fool for trying, but then again, I knew that already :)
--
Roberto Alsina (KDE developer, MFCH)
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
Date: Sun, 10 Jan 1999 13:35:47 -0500
From: Ganesh Venkitachalam <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development
Subject: VM_MAYWRITE
Hi,
Could anyone explain briefly how the VM_MAYWRITE flag is used
in the linux VM subsystem? I saw that there is a test in mm/filemap.c
(generic_file_mmap function) to check whether vm_flags has VM_SHARED
and VM_MAYWRITE set before setting vm_ops to file_shared_mmap. Isn't
it enough to check just VM_SHARED and VM_WRITE?
--Thanks & Regards
Ganesh
------------------------------
From: Martin Maney <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.x
Subject: Re: disheartened gnome developer
Date: 10 Jan 1999 18:47:31 GMT
steve mcadams <[EMAIL PROTECTED]> wrote:
> WHERE does this leave companies that want to put all their resources
> into development????
Right where they are now: dependent upon someone willing to turn their
latest creation into a product by marketing and supporting it. Or maybe
they could get direct contributions from those willing to send money in
thanks for their past open source releases and/or drooling in anticipation
of their next one. But if it isn't supported then it isn't a product; open
source can relieve the creator of much of the support burden, although even
that isn't really guaranteed.
> Are they expected to start what amounts to a second company by hiring
> people to do support for a fee? This means they have to make an
> exorbitant profit from their newly hired and probably unskilled
> support people in order to support their development efforts, so their
> customers (if they are newbies and don't know they can get better
> support here in the newsgroups on a costless basis) get ripped off
> because they don't know better than to ask these bozos just hired off
> the street how to get their commercial web-server configured
> correctly?
You setup the straw man, you knock him down and set fire to him. <yawn>
> What if such a company believes that its support should be costless
> because it is a point of HONOR and/or INTEGRITY to keep your software
> working correctly? Do they just get screwed? They all have to go and
> flip burgers for a living because they don't do phones for money like
> the other 900-girls?
Then this company's business model relies on screwing the money out of the
customer by selling the software. This is, also, no longer a company that
wants nothing to do with support, eh? That would be one straw man, one
non-sequiter.
> And worse yet, what if these guys writing the CODE are SO GOOD that
> NOBODY ever NEEDS SUPPORT? Are they supposed to sit there and either
> starve because they've done such a good job, or stop writing code and
> get a job where they can support themselves?
My my, those are pointy horns indeed. Luckily, it is only your lack of
imagination that excludes the middle, to say nothing of the possibilities
that lie entirely outside the narrow bounds of your suggested outcomes.
------------------------------
From: [EMAIL PROTECTED] (Christopher B. Browne)
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.x
Subject: Re: disheartened gnome developer
Date: 10 Jan 1999 20:20:33 GMT
Reply-To: [EMAIL PROTECTED]
On Sun, 10 Jan 1999 18:58:22 GMT, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
posted:
>In article <77afhd$tcj$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (Tim Smith) wrote:
>> In article <777pr8$bve$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>> >Remember Jedi, free software is not a spectator sport, and you are
>> >standing outside of the field, throwing beer cans to the players.
>>
>> Go look him up on DejaNews, and you'll find a post where he comes out and
>> admits that he's going to attack KDE and Qt every chance he gets, no matter
>> what changes are made to the licensing. It's pointless to try to argue
>> with him on this topic, so just killfile him--you actually produce free
>> software, so shouldn't let non-producers drag you into their pointless
>> arguments.
>
>I agree on principle, but... well, one of the reasons I write free software
>is because I think cool people will use it, and I am, so to speak putting
>my 2 cents worth to help the same community that has provided me with a lot
>of very useful things.
>
>So, I feel really bad, almost phisically ill, when I see people like Jedi who
>just spit on it while at the same time posturing as a part of that community.
>
>I get this feeling that if I don't reply his opinions may stick on some
>innocent folk. Goebbels-like, if you remember that "lie, lie ..." quote.
>
>I suppose I'm a fool for trying, but then again, I knew that already :)
The *real* best answer to jedi is to produce useful software.
Or to bounce a donation to the FSF or XFree86, and then respond with
"I support free software. Do you?"
I'll suggest the thought that if you don't bother fighting with him,
while this may mean that his anti-KDE attacks may go unanswered, which
is not a good thing, he'll not be likely to dwell on KDE, but rather
fixate on whomever else *is* responding.
Of late, the jedi "diatribes" have been against iMacs; by doing a
suitable comparison of apples to oranges, he's gotten to claim that
they're overpriced by on the order of $700.
(He may discover the web site where PCs are being sold, OS-less, for $375.
That is, of course, a wonderful opportunity to claim that iMacs are
overpriced by closer to a full $1000...)
The validity of his arguments are made quite self evident by the quality
of his argumentation.
--
Those who do not understand Unix are condemned to reinvent it, poorly.
-- Henry Spencer <http://www.hex.net/~cbbrowne/lsf.html>
[EMAIL PROTECTED] - "What have you contributed to Linux today?..."
------------------------------
From: [EMAIL PROTECTED] (Leslie Mikesell)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Open Configuration Storage - was Registry for Linux
Date: 9 Jan 1999 17:13:12 -0600
In article <[EMAIL PROTECTED]>,
Frank Sweetser <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] writes:
>
>> Have you looked at how nsswitch works? Just a thought.
>
>now you've got the idea =) do for a general configuration api what
>nsswitch does for gethostbyname, but with even more flexibility.
But the catch is that you are going to need a superset of the
choices (if you add ldap, sql, acap, etc.) and you need to
be able to specify the order of checking separately for
at least every program and possibly every option. And there
will be some cases where the local setting should not be
allowed to override the network globals. It seems like there
should be some other way, like specifying a priority value
where there could be default ranges at each level. Specifying
a lower value locally could give you a fall-back default if the
expected global setting doesn't exist. Bumping up the global
setting at any level would override the local defaults that others
haven't bothered to change. It could work something like the
way routing protocols choose the best route from an assortment
of independently-configured choices.
Les Mikesell
[EMAIL PROTECTED]
------------------------------
From: Frank Sweetser <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Open Configuration Storage - was Registry for Linux
Date: 10 Jan 1999 15:31:10 -0500
[EMAIL PROTECTED] (Leslie Mikesell) writes:
> In article <[EMAIL PROTECTED]>,
> Frank Sweetser <[EMAIL PROTECTED]> wrote:
> >[EMAIL PROTECTED] writes:
> >
> >> Have you looked at how nsswitch works? Just a thought.
> >
> >now you've got the idea =) do for a general configuration api what
> >nsswitch does for gethostbyname, but with even more flexibility.
>
> But the catch is that you are going to need a superset of the
> choices (if you add ldap, sql, acap, etc.) and you need to
> be able to specify the order of checking separately for
> at least every program and possibly every option. And there
> will be some cases where the local setting should not be
> allowed to override the network globals. It seems like there
> should be some other way, like specifying a priority value
> where there could be default ranges at each level. Specifying
> a lower value locally could give you a fall-back default if the
> expected global setting doesn't exist. Bumping up the global
> setting at any level would override the local defaults that others
> haven't bothered to change. It could work something like the
> way routing protocols choose the best route from an assortment
> of independently-configured choices.
<note that this has already been well disccused in one of the other related
threads>
hmm... that actually makes a lot of sense, assigning a priority or a weight
to each setting. there would have to be some restrictions, though - the
system config should be able to unconditionally override a user's
settings. still i like the idea =)
--
Frank Sweetser rasmusin at wpi.edu fsweetser at blee.net | PGP key available
paramount.ind.wpi.edu RedHat 5.2 kernel 2.2.0pre5ac1 i586 | at public servers
I might be able to shoehorn a reference count in on top of the numeric
value by disallowing multiple references on scalars with a numeric value,
but it wouldn't be as clean. I do occasionally worry about that. --lwall
------------------------------
From: [EMAIL PROTECTED] (Leslie Mikesell)
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: 9 Jan 1999 17:25:20 -0600
In article <[EMAIL PROTECTED]>,
Johan Kullstam <[EMAIL PROTECTED]> wrote:
>>
>> >well my point is that there are a lot of options and it's hard to
>> >remember them. i know the main ones for tar and grep and ls, but cpio
>> >is hopeless.
>>
>> Better to have the options and have to view the man page in another
>> window sometimes than to need the option and not have it.
>
>it's not the *presence* of options that i am railing against. it's
>the almost total lack of *consistency*. if there were more
>consistency i wouldn't *have* to keep consulting man pages.
And I'd argue that if the programs that provided those options
had been forced to do so in what you consider a consistent manner,
they probably wouldn't have done it at all. Keep in mind that these
programs have evolved over at least 20 years with not much holding
them together except their continuing usefulness, and that
once a program is in widespread use under unix it is impossible
to remove an existing feature without breaking something. People
take advantage of the fact that any program automatically includes
all of the functions of all the others via system() and popen().
It would be fine if someone wrote new programs that provided all
the same functionality and a more consistant interface, but programs
are generally only written to fill a need. By the time a programmer
would be able to write such programs, he no longer needs them...
Les Mikesell
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (TGAPE!)
Subject: Re: Dumb kernel question.
Date: Sun, 10 Jan 1999 19:06:42 GMT
In article <[EMAIL PROTECTED]>,
Bill Wangard <[EMAIL PROTECTED]> wrote:
>
>I have a question about compiling a new kernel.
>
>In the kernal-README, it says that the order of the make commands is
>
>make dep; make clean, make zImage
>
>It thens says, if you have selected any functions to be modules then
>you need to
>make modules; modules_install
>
>It is not clear from the rEADME when I am supposed to invoke these
>commands, since in the modules howto, it says
>
>make dep; make clean; make modules; make modules_install; make zImage
>
>Which is correct?
It doesn't matter. modules need to be made before modules_install. dep
needs to be made before zImage and modules. clean *should* be made
before zImage and modules, especially if you've done a previous compile
with different options (i.e. you've run make config.)
clean and dep have no affect on each other. zImage and modules have no
affect on each other.
Clear?
If your image is too big to be a zImage, you can run make bzImage
without running dep and clean again.
>And do I have to run depmod -a ?
Depends on your distribution. Most will run it for you on boot.
Yes, the modules HOWTO does need to be re-written. Apparently, so does
any document that tells you to make zImage, and doesn't mention bzImage.
(The primary difference between the two, as far as the sysadmin is
concerned, bzImage doesn't have the size limitation that zImage has.
Don't ask me what zImage's limit is; my experience conflicts slightly
with what I've been told.)
Ed
------------------------------
** 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
******************************
