Linux-Development-Sys Digest #181, Volume #6 Sat, 26 Dec 98 23:13:43 EST
Contents:
Re: Registry for Linux - Bad idea (Michal Mosiewicz)
Re: Registry for Linux - Bad idea (Robert Krawitz)
Organizing Application Files/Config Info (Registry Unix Style) (George MacDonald)
building kernel under RH 5.2 (mvrao)
Re: building kernel under RH 5.2 (Raymond Lillard)
Re: building kernel under RH 5.2 (mvrao)
Re: things I'd pay to have developed for Linux... (Leslie Mikesell)
----------------------------------------------------------------------------
From: Michal Mosiewicz <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: Sun, 27 Dec 1998 02:04:17 +0100
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'.
> 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.
However in many cases configuration data are read infrequently, because
they cannot be read frequently with such design.
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: Robert Krawitz <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: 26 Dec 1998 20:57:45 -0500
Michal Mosiewicz <[EMAIL PROTECTED]> writes:
> How do you feel about things like PAM? Don't you see that these things
> violate your engineering policies? It isolates your /etc/passwd. It's no
> longer necessary to have /etc/passwd as text file. But note, that it
> makes the software perfectly independent of how you store your
> authentication information.
...and...
> > Window's network configuration requires quite a few panels to set these
> > three lines. I generally set these three lines via a command like:
> > echo "nameserver xxx" >> /etc/resolv.conf
>
> You assumed, there is no way, that it would be possible to type:
> echo "xxx" > /proc/sysconfig/resolver/nameserver.
Sure, but what is the compelling advantage of putting (say) the
nameserver in the kernel? It means that you need to make a kernel
change to fix or otherwise change the name resolution software.
> Once again, please, I clearly stated I'm not complaining about lack of
> registry. I simply complain about people which go deeply into critisism
> by assuming that the design must be wrong.
It's up to the person proposing a change to demonstrate the need for
it. It's quite correct to presume that a design is wrong, and thus
the burden of proof is on the proposer.
--
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: George MacDonald <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Organizing Application Files/Config Info (Registry Unix Style)
Date: Sun, 27 Dec 1998 01:53:16 GMT
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: mvrao <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.setup
Subject: building kernel under RH 5.2
Date: Sun, 27 Dec 1998 02:07:11 +0000
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.
Thanks,
M V Rao
------------------------------
Date: Sat, 26 Dec 1998 18:37:57 -0800
From: Raymond Lillard <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.setup
Subject: Re: building kernel under RH 5.2
mvrao wrote:
> 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.
Not for me it doesn't. After using glint my sources are in
"/usr/src/linux-2.0.36" and there is a symlink "linux" pointing
to the hard path.
I am guessing you should use "glint" and install
from the distribution CDROM.
Good Luck,
Ray
------------------------------
From: mvrao <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.setup
Subject: Re: building kernel under RH 5.2
Date: Sun, 27 Dec 1998 03:28:23 +0000
Raymond Lillard wrote:
> mvrao wrote:
> > 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.
>
> Not for me it doesn't. After using glint my sources are in
> "/usr/src/linux-2.0.36" and there is a symlink "linux" pointing
> to the hard path.
>
> I am guessing you should use "glint" and install
> from the distribution CDROM.
>
> Good Luck,
> Ray
I am not sure how you got glint to work for SRPMS- it scans th ewhole dir and
says there are no packages.
Anyway, I used rpm command line and in the pkg 'kernel-2.0.36-0.7.src.rpm'
I found the following files -
2.0.36-pre-patch-14.gz
aic7xxx-5.1.0-to-5.1.1.patch.gz
aic7xxx-5.1.1-to-5.1.2.patch.gz
axp-diffs-2.0.31.patch
bpcd.c
ibcs-2.0-980822.tar.gz
ibcs-2.0-make.patch
ibcs-2.0.970513-glibc.patch
ibcs-2.0.970513-nonsmp.patch
installkernel
kernel-2.0.36-alpha.config
kernel-2.0.36-i386.config
kernel-2.0.36-kfd.patch
kernel-2.0.36-sound-new.patch
kernel-2.0.36-xconfig.patch
kernel-2.0.36.spec
kernel-make.patch
linux-2.0.30-alphamachines.patch.gz
linux-2.0.34-firewallmoduleHACK.patch
linux-2.0.35.tar.gz
module-info
pci-jo-091398.dif
pcmcia-cs-2.8.8-network.script
pcmcia-cs-3.0.5-chkconfig.patch
pcmcia-cs-3.0.5-preferred.patch
pcmcia-cs-3.0.5.tar.gz
rhkmvtag.c
sound.diff.gz
unistd.h
I hope this explains what I was talking about. Does this mean I have to start
with 2.0.35 kernel source, apply all patches and so on ? I do not know the
order in which to apply the patches. Heck I don't know how to apply the
patches without the .gz ext. Worse, some of the .gz files error out upon
doing tar zxvf !
I am beginning to get disillusioned here and I have done dev under Unix-C
before !
------------------------------
From: [EMAIL PROTECTED] (Leslie Mikesell)
Crossposted-To:
comp.os.linux.misc,comp.os.linux.development.apps,comp.os.linux.hardware
Subject: Re: things I'd pay to have developed for Linux...
Date: 26 Dec 1998 21:46:38 -0600
In article <[EMAIL PROTECTED]>,
Bill Davidsen <[EMAIL PROTECTED]> wrote:
>
>> >no need to authenticate again
>>
>> Oh, the clients I use do this transparently so I wouldn't have considered
>> it an issue.
>
>How does it do something "transparently?" He's talking about modem
>lines, so if you mean by passing information back and forth, it isn't
>going to be tranparent in the sense of not bogging response.
Transparently to the user, as in automatically reconnecting to
a share and re-authenticating when necessary. If you are concerned
about the overhead of passing a name and password at connection
establishment, file sharing is probably the wrong approach
anyway. But, the real problem is that you have to map the ports
to a single IP address so you can't redirect your local ports if
you have a local server running. Has anyone tried a scheme of
IP aliases on the tunneling machine to get the effect of NAT
through an ssh connection?
Les Mikesell
[EMAIL PROTECTED]
------------------------------
** 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
******************************
