Linux-Development-Sys Digest #254, Volume #6 Mon, 11 Jan 99 03:14:37 EST
Contents:
Linux at Comdex'98 ("SV")
Re: Open Configuration Storage - was Registry for Linux (Frank Sweetser)
Re: Open Configuration Storage - was Registry for Linux (Frank Sweetser)
Configuration/source control in Linux development environment ("John & Kris Godinez")
glibc for 2.2 upgrade (Joe Pfeiffer)
Re: Registry for Linux - Bad idea (Robert Krawitz)
Re: Registry - Already easily doable, in part. (Bulent Murtezaoglu)
Re: Configuration/source control in Linux development environment (Mike Hoegeman)
Re: GUI, The Next Generation (Derek B. Noonburg)
Re: Kernel 2.2.0-pre6 (Peter Mardahl)
Linux drivers using KRFTech's WinDriver (Ralph Billes)
----------------------------------------------------------------------------
From: "SV" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.hardware,comp.os.linux.help
Subject: Linux at Comdex'98
Date: Mon, 11 Jan 1999 00:58:08 -0500
was kinda modestly represented, wasn't it?
check it out
http://www.phystech.com/info/comdex98.html
Cordially,
S.V.
------------------------------
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 23:43:53 -0500
[EMAIL PROTECTED] (Leslie Mikesell) writes:
> In article <[EMAIL PROTECTED]>,
> George MacDonald <[EMAIL PROTECTED]> wrote:
> >>
> >> Someone has to care, since someone has to configure it. The last
> >> thing I want is yet-another-protocol service to manage in the name
> >> of making things simpler. If this needs more than ordinary files
> >> and possibly NFS, can it use some existing protocol like http or
> >> LDAP?
> >
> >There is a protocol ACAP, see RFC 2244 which is designed to addess
> >the networking aspect of application configuration. But it should
> >be hidden behind a common interface, so that normal flat files
> >can be used if desired. You should visit
> >
> > http://andrew2.andrew.cmu.edu/cyrus/acap/
> >
> >They have one doc that does a comparison of the various protocols
> >and why they created a new one.
>
> I agree that the other existing protocols don't do quite what we
> need, but on the other hand I don't see everyone jumping to install
> ACAP. It is just another thing to set up and maintain and it doesn't
> replace the need for LDAP.
one of the goals is to make the simple case simple. for a plain
non-networked, single user, home machine, the default opStore config could
just point to /etc/opStore/<app>.conf priority 5, then
~/.opStore/<app>.conf priority 10. this would require no maintanence on
the part of the sysadmin (== user here), and give the same behavior as is
common now - it wouldn't be a full service, but rather just another library
the app uses.
with more complex systems, the system administrator would have the ability
to specify a more complex configuration. in that case, it can safely be
assumed that there would already be a system administrator capable of
dealing with more complex setups.
> >My approach is to build an
> >architecture that can use any of these, perhaps with some limitations.
>
> >Decisions as to what level of security, performance, extra features
> >should be left to site administrators as much as possible. Admin
> >policy will have a significant bearing on these decisions. At the
> >simplest level one needs a
> >
> > get - i.e. read, select, ...
> >
> >and to store some kind of
> >
> > set - i.e. write, update, ...
> >
> >and perhaps some kind of
> >
> > start transaction - open, ...
> > end transaction - close, ..
> >
> >The goal is to keep it as simple as posssible, so that it can map
> >onto each of the underlying mechanisms.
>
> How do you propose to map transactions onto something that doesn't
> supply a transaction mechanism? Suppose you want to update
> values that are independent in LDAP but the set of updates must
> be held together when you retreive the values as a configuration?
> How can you prevent a machine from getting a mix of old and
> new values (a potential disaster) while the update is in progress?
>
> >Impossible to do all this? Absolutely not! Difficult?
> >Of course, making complex things simple always is.
>
> Yes, it really is impossible to do it perfectly. However, even
> with config files unix is pretty sloppy already with the only
> transactioning mechanism being the number of people who know the
> root password. You might be able to make it 'good enough'.
hrm... i think you're probably right here. we can play some tricks with
file locking and rename(), but for resources spread accross multiple
sources (in particular ones w/out true transaction support, which will
probably be most of 'em) there will always be a danger. having an opStore
lock on each resource *should* mean that 2 opStore apps won't corrupt each
other, though that won't help with other entities (ie, someone with vi)
from interfering. the best we can do in that case is make things no more
dangerous than they already are.
> >Don't think I can do it? Have a look at treeps,
>
> I wouldn't question your capabilities. You are just attempting something
> that needs transactioning and it can't be done right unless the
> back end supports it - or you are willing to accept occasional errors.
> Perhaps you should start with postgresql (which supports transactions
> and has an open license) as the preferred network store. Even then
> you will have problems if you allow settings stored at different
> levels in the hierarchy to be used if they come from different databases
> or files.
>
> Les Mikesell
> [EMAIL PROTECTED]
--
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
Woody: Hey, Mr. Peterson, there's a cold one waiting for you.
Norm: I know, and if she calls, I'm not here.
-- Cheers, Bar Wars II: The Woodman Strikes Back
------------------------------
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 23:36:58 -0500
[EMAIL PROTECTED] (Leslie Mikesell) writes:
> In article <[EMAIL PROTECTED]>,
> George MacDonald <[EMAIL PROTECTED]> wrote:
> >>
> >> 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 =)
> >
> >Actually this is quite interesting. As frank says we definately need a way
> >for administrators to *lock* values by marking them final and then also
> >not allowing the evaluation methods or "store path" to be overriden.
>
> I think that you also want a way that any network-available value
> can either be a fall-back default only for the cases where the
> local value hasn't been configured at all, and the opposite case
> where the local copy is only used if no one has configured the
> setting at a more global level.
agreed. the current proposal is for an evaulation tree. for each resource
from which the config option is requested, the highest priority one takes
precedence. each resource has the choice of not returning the value, ==
priority -1 more or less.
> >We also want to allow the opposite(in some cases), i.e. allow the user
> >to override these(e.g. A Trusted user). I had only envisage one evaluation
> >mechanism, but the priority evaluation suggest there may be others.
>
> I'd expect some sort of hierarchy where you don't know the number of
> levels ahead of time. That is, you might have a laptop that runs
> off-network sometimes, on a home network with one other host sometimes,
> and on the office network where there are department, division, and
> enterprise defaults for different values. Having a wide value range
> with space available on both sides of the initial defaults should let
> things fall into their assigned places.
>
> >So perhaps making the evaluation mechanisms definable externally and
> >then configuring them?
>
> You will need a way to assign the priorities to the existing
> mechanisms (files, etc.) that do not supply them directly. New
> mechanisms can be built to supply their own along with the value
> (like asking for a DNS MX record). There is a certain intellectual
> purity in using the same mechanism internally as you present
> externally. I'd recommend assigning a default priority to values
> obtained by each method and get this setting just like all the
> others. Note that if you allow local files to be used at all
> you probably can't prevent local administrators from overriding
> the network-mandated defaults and I'm not sure how much effort
> should go into even trying.
the existing plan already includes locally configured metadata, this
metadata coule include default priorities for any resources that do not
specify one themself.
--
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
Woody: Hey, Mr. Peterson, there's a cold one waiting for you.
Norm: I know, and if she calls, I'm not here.
-- Cheers, Bar Wars II: The Woodman Strikes Back
------------------------------
From: "John & Kris Godinez" <[EMAIL PROTECTED]>
Subject: Configuration/source control in Linux development environment
Date: 11 Jan 1999 04:03:22 GMT
I have a development question and hope this is the right group....
Our next Linux project requires source control and an automated build
process. I'm asking those who've already tread these waters, what they
think. A couple of team members are already familiar with scripting,
rcs or cvs, & make. There are canned packages on the market by
InterSolve, and another one by MKS that we've gotten inforamtion about.
Our real concern is to have a reliable, stable environment. What do you
suggest we use for configuration management / source control?
------------------------------
From: Joe Pfeiffer <[EMAIL PROTECTED]>
Subject: glibc for 2.2 upgrade
Date: 10 Jan 1999 22:59:23 -0700
Preparing for an upgrade to 2.2.0pre(whatever it is when I get there),
I'm trying to upgrade my glibc. I'm running into some problems...
(1) The Changes file calls for glibc2.0.7pre6 in the minimal requirements
section, and 2.0.9x when describing Unix98 pty support. Which of
these is in fact a higher version?
(2) Based on the timestamps of the files in
http://www.us.kernel.org/pub/linux/libs/glibc/ I'm assuming 2.0.7pre6
is (even though from the numbering I'd expect 2.0.95 would be the
highest version in that directory). After downloading glibc2.0.7pre6,
the README file states that I can find glibc-crypt-2.0.7.tar.gz. No,
I can't. There are no glibc-crypt-2.0.7 files of any description
there; though I can find glibc-crypt-2.0.9x files. Where can I find
glibc-crypt-2.0.7?
(3) I've wound up downloading glibc-crypt-2.0.95.tar.gz (on an earlier
iteration, I used matching glibc and glibc-crypt versions; that didn't
compile either, though for a different reason. I don't think the
problem I'm having is version related...). When I try to compile, I
get:
make -C stdio-common subdir_lib
make[2]: Entering directory `/disk2/src/glibc-2.0.7pre6/stdio-common'
gcc ../sysdeps/posix/ctermid.c -c -O2 -Wall -Winline -Wno-parentheses -Wstrict-p
rototypes -Wwrite-strings -g -I. -I.. -I../libio -I/disk2/src/glibc-2.0.7pr
e6/linux -I../sysdeps/i386/elf -I../crypt/sysdeps/unix -I../linuxthreads/sysdeps
/unix/sysv/linux -I../linuxthreads/sysdeps/pthread -I../linuxthreads/sysdeps/uni
x/sysv -I../linuxthreads/sysdeps/unix -I../linuxthreads/sysdeps/i386/i586 -I../l
inuxthreads/sysdeps/i386 -I../linuxthreads/sysdeps/pthread/no-cmpxchg -I../sysde
ps/unix/sysv/linux/i386 -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysde
ps/unix/common -I../sysdeps/unix/mman -I../sysdeps/unix/inet -I../sysdeps/unix/s
ysv/i386 -I../sysdeps/unix/sysv -I../sysdeps/unix/i386 -I../sysdeps/unix -I../sy
sdeps/posix -I../sysdeps/i386/i586 -I../sysdeps/i386/i486 -I../sysdeps/i386/fpu
-I../sysdeps/libm-i387 -I../sysdeps/i386 -I../sysdeps/wordsize-32 -I../sysdeps/i
eee754 -I../sysdeps/libm-ieee754 -I../sysdeps/generic -I../sysdeps/stub -D_LIBC
_REENTRANT -include ../libc-symbols.h -D_IO_MTSAFE_IO -o /disk2/src/glibc-2.
0.7pre6/linux/stdio-common/ctermid.o
In file included from ../linuxthreads/sysdeps/pthread/pthread.h:25,
from /usr/include/stdio-lock.h:20,
from ../libio/libio.h:156,
from ../libio/stdio.h:29,
from ../stdio.h:2,
from ../sysdeps/posix/ctermid.c:20:
../linuxthreads/sysdeps/pthread/bits/pthreadtypes.h:23: bits/sched.h: No such fi
le or directory
make[2]: *** [/disk2/src/glibc-2.0.7pre6/linux/stdio-common/ctermid.o] Error 1
I'd appreciate any help getting this to compile...
--
Joseph J. Pfeiffer, Jr., Ph.D. Phone -- (505) 646-1605
Department of Computer Science FAX -- (505) 646-1002
New Mexico State University http://www.cs.nmsu.edu/~pfeiffer
------------------------------
From: Robert Krawitz <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: 04 Jan 1999 10:00:07 -0500
[EMAIL PROTECTED] writes:
> > I missed the first part of this thread, so forgive me if I'm reiterating
> > something already covered. Your comment above is correct, but "dumbing
> > down" the user interface isn't the answer (ask anyone involved in hiring
> > how well it's worked in our schools). The appropriate answer, IMNSHO,
> > is to provide the tools needed for the non-expert to easily learn how to
> > do the required modifications to make his system work as desired. Both
> > Windows and Linux are lacking here.
>
> Absolutely. That's where I'm coming from. We cant get there until everything
> works in a defined way though, that's where the central config database comes
> in.
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.
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.
> I think this is true, I think the system should be such that all of the
> complexity and flexibility is there, but it's organized in layers such that
> an experte can do all the way down, where as a novice will only understand
> and only need a few levels. It should get more complicated the deeper you go,
> and the flexibility should increases. I dont know if a central config
> database is a vehicle to bring this, but IMHO it's a good start.
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.
--
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: Bulent Murtezaoglu <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Registry - Already easily doable, in part.
Date: 04 Jan 1999 09:58:18 -0500
>>>>> "AM" == Andrew Morton <[EMAIL PROTECTED]> writes:
AM> May I point out some shortcomings of the filesystem-based
AM> approaches? 1: They're Linux specific.
AM> 2: They're "single system centric" (tm). We need to pay more
AM> recognition to the requirement that reconfiguration of
AM> applications is an enterprise-wide function. The rdist
AM> approach is klunky (how do I simply change/propagate a single
AM> line of config?)
I don't understand why you'd use a "klunky" rdist approach in company
network? If everything is sitting on a network more than likely they
use their local hard drives just for /tmp /swap and things like that.
Workstations boot from the network and homes are mounted from the
network. No rdist, maybe NIS or ldap and NFS. Now Linux distributions
(at least Debian) are not quite there yet in that they cannot, say, share
/usr and have the packaging tools to update network clients' root directories
with the same ease they do for stand-alone workstations. They will get
there, though, with text files.
AM> 3: They do not provide for notifications to running
AM> applications.
You may have a point for daemons there, changing the config file does
not automatically notify them. You can signal them but it
would have to be done from the machine they are running on (you can
still do it remotely). For regular applications, I don't know. Depends
on the application. Some allow the user to change the config files
from within the application in which case the right thing happens.
AM> Let's stop thinking "Linux registry" and start thinking "Unix
AM> Active Directory".
I am not sure what this will accomplish. It looks great to an MS admin
because those folks usually have to walk to each workstation and click
on things. There's no such need for Unix admins managing networked machines.
But maybe I don't know what an active directory is?
I basically do not see what fundamental difference there is between
changing hkey\mumble\feature358 with a special program and editing
/etc/mumble.conf with your preferred editor and changing feature358
there. If the syntax is the problem, I'd much rather have something
expressive with a minimal syntax (lisp style) than something that
resembles the MS registry. I personally think the hard part about
configuration lies in the inherent complexity of highly configurable
programs. Once you clearly understand what it is you need to
accomplish and employing what features will get you there, the rest
is easy.
BM
------------------------------
From: Mike Hoegeman <[EMAIL PROTECTED]>
Subject: Re: Configuration/source control in Linux development environment
Date: Mon, 11 Jan 1999 07:13:25 +0000
John & Kris Godinez wrote:
> I have a development question and hope this is the right group....
>
> Our next Linux project requires source control and an automated build
> process. I'm asking those who've already tread these waters, what they
> think. A couple of team members are already familiar with scripting,
> rcs or cvs, & make. There are canned packages on the market by
> InterSolve, and another one by MKS that we've gotten inforamtion about.
> Our real concern is to have a reliable, stable environment. What do you
> suggest we use for configuration management / source control?
for configuration management CVS is great. i've gotten people that rebelled
against every cm tool put in fromt of them to use CVS. It's definitely in
the upper echelon
in the reliability/stability category.
if you want commercial support see www.cyclic.com. we've never really needed
it
though and we've done some pretty sizable projects with it.
-mike
------------------------------
From: [EMAIL PROTECTED] (Derek B. Noonburg)
Subject: Re: GUI, The Next Generation
Date: 11 Jan 1999 01:32:03 -0600
Ross Vandegrift <[EMAIL PROTECTED]> writes:
> > If you don't want overlapping windows, go get Andrew (a windowing system
> > that runs on X). As best I recall from when I used it at CMU it didn't
> > use overlapping windows.
>
> Andrew, or the AUIS (Andrew User Interface System) is really an Office
> Suite. It doesn't use overlapping windows, because it runs the way
> Emacs does under X - yea, it has a GUI, but it is way easier to use the
> keyboard.
The original Andrew system had its very own windowing system, called
"wm" (for window manager). This was a complete windowing system, not
a window manager on top of X. There was also a slightly modified
version called "wmc", maintained by the CMU Computer Club. I believe
the contemporary release of X was X10 -- CMU didn't cave in to the MIT
X virus until X11 :-)
Wm used tiled windows. You could set columns and rows, and windows
were locked into a particular tile. Windows within a tile could be
expanded or shrunk down into just a title bar. The shrunk title bars
would stack up at the bottom of the tile.
The Andrew apps (AUIS, previously ATK = Andrew Toolkit, previously BE2
= base editor 2, previously BE), were originally developed for wm.
ATK was eventually ported over to X. I'm fairly certain the newer
Andrew stuff was never back-ported to wm, so you'd be stuck with
really old versions of ez, etc.
And, of course, nothing else runs under wm (netscape, StarOffice,
etc.).
I have no idea if the source for wm or wmc is available.
- Derek (a CMU alum, just in case you couldn't tell)
------------------------------
From: [EMAIL PROTECTED] (Peter Mardahl)
Subject: Re: Kernel 2.2.0-pre6
Date: 10 Jan 1999 23:39:31 -0800
In article <[EMAIL PROTECTED]>,
Frank Hale <[EMAIL PROTECTED]> wrote:
>mlw wrote:
>>
>> I have Redhat 5.2 and it said it was "2.2 ready," so I tried it. It just
>> worked. Perhaps I should do a bit more research.
>
>You mean you downloaded 2.2.0pre6 kernel and installed it and you booted
>fine? No problems? Really? I had to do a total reinstall of everything
>cause it got all messed up? People told me I needed to upgrade ksyslog,
>modutils, etc....... But that just made it worse. It worked better when
>I used the stock ones that were installed with RedHat 5.2.
>
>If anyone has anymore info on installing the 2.2.0 pre6 kernel on RH 5.2
>let me know. I would like to put it on but I have wastes about 4 days on
>the new 2.2.0pre kernel with absolutely no luck at all. All I got out of
>it was having to reinstall everything from scratch.
To add a little motivation to this,
it'll help get more testers if someone spells out how to
set up a 5.2 system to run 2.2 pre 6.
I'd help test too if I knew clearly what other software to set up so
that 2.2 would work with 5.2, and there isn't too much black
magic involved....
PeterM
------------------------------
From: Ralph Billes <[EMAIL PROTECTED]>
Subject: Linux drivers using KRFTech's WinDriver
Date: Mon, 04 Jan 1999 22:31:00 +0800
Has anyone had experience with WinDriver from KRFTech to write
device drivers for Linux?
Linux support is new (Dec 18) and I don't want to be a guinea pig...
See http://www.krftech.com/windrv/
Thanks,
Ralph Billes.
------------------------------
** 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
******************************
