Linux-Development-Sys Digest #208, Volume #6 Mon, 4 Jan 99 00:14:12 EST
Contents:
ppp-compress-xx problem in 2.2.0-pre4 (David Ronis)
Unresolved symbols in ufs.o (David Ronis)
Re: Registry for Linux - Bad idea (George MacDonald)
Re: 2.2.0pre4 dual boot with 2.0.36 question (David T. Blake)
Re: Registry for Linux - Bad idea (Martin Maney)
Re: Registry for Linux - Bad idea (Leslie Mikesell)
Re: Registry for Linux - Bad idea (Frank Sweetser)
Persistent sound hangs (2.0.0 - 2.2.0pre4 tested) (Erik Inge Bolso)
Re: Electric Fence 100x slower in 2.1.130 than 2.0.35? (Michael Meissner)
Re: GUI, The Next Generation (steve mcadams)
Re: Registry for Linux - Bad idea (Christopher B. Browne)
Re: [Q] SCSI Tape Setup ("Trent Corney")
----------------------------------------------------------------------------
From: David Ronis <[EMAIL PROTECTED]>
Subject: ppp-compress-xx problem in 2.2.0-pre4
Date: 4 Jan 1999 02:34:27 GMT
I've just finished installing 2.2.0-pre4 on an i486. It runs, however
I've been getting the following error(?) reported in my messages file:
modprobe: can't locate module ppp-compress-21
modprobe: can't locate module ppp-compress-26
modprobe: can't locate module ppp-compress-24
PPP seems to work, although I don't know if I'm getting
compression. (lsmod doesn't show bsd_compress or ppp_deflate being
loaded when ppp is running).
There is a module request in ppp.c, and I suspect that the problem is
that I need an alias in /etc/conf.modules. Unfortunately, grepping
the source tree for ppp-compress doesn't show what it is.
David Ronis
------------------------------
From: David Ronis <[EMAIL PROTECTED]>
Subject: Unresolved symbols in ufs.o
Date: 4 Jan 1999 02:37:31 GMT
I just finished installing 2.2.0-pre4. It runs, but I get the
following problem from depmod:
bash-2.02# /sbin/depmod -a
/lib/modules/2.2.0-pre4/fs/ufs.o: unresolved symbol(s)
David Ronis
------------------------------
From: George MacDonald <[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 03:01:52 GMT
Frank Sweetser wrote:
>
> [EMAIL PROTECTED] (Christopher B. Browne) writes:
>
> > There would be merit to having a highly robust, *CONVENIENT TO USE* library
> > called, oh, say, libconfig.so, that provided, within a small amount of code,
> > some useful configuration functionality.
>
> ftp://tsx-11.mit.edu/pub/linux/BETA/profile/ is the package mentioned a
> couple weeks ago by Ted T'so that is exactly that. i've been working with
> it a bit on packaging it up into a nice standalone library, if Ted likes
> what he sees with it i expect he'll make it publicly availible.
Has some nice features, i.e. a hierarchy in the file, paths, some OO features
i.e. overrides, final, ...
There are a few things that would stop me from using it
No write capability
No typing/classifying of values so can't write one parser - see SNMP MIB's
No range specifiers so can't have independent tools validate configs
No syncronized writes i.e. for multiple processes
No networking so I can pull config from another site
No publishing so I can publish part of my config.
I am still looking for a config system that has all the features I need,
so far no luck. I have started to define a project to build one, at this
point I am still collecting ideas(this thread has been great) and
building a feature list. I have a rough idea of a design, so far nothing
I have seen even comes close to being extensible to either the features
or the design I have in mind.
--
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 T. Blake)
Subject: Re: 2.2.0pre4 dual boot with 2.0.36 question
Date: 03 Jan 1999 18:18:31 -0800
Mark Jeacocke <[EMAIL PROTECTED]> writes:
>Hi I'd like to help out a bit test out 2.2.0pre4 on my RedHat 5.2
>system.
>
>I've downloaded the src in .tar.gz format and I'm ready to try it out,
>however in the past when I've built custom kernels the have all been
>from the same kernel version.
>
>For example what do I do with the "/usr/src/linux" symbolic link?
>And the "/lib/modules/preferred" symbolic link?
Leave the /usr/src/linux link pointing at 2.0.36, or change it.
It doesn't matter. Just make certain you do the build from the
2.2 directory.
Delete the /lib/modules/preferred link. Make certain the
link /lib/modules/`uname -r`
exists. /etc/rc.d/rc.sysinit should default to this anyway.
You can edit that script to make certain it does - it is pretty
easy.
>I can edit lilo.conf once I've got the kernel images, but how will
>the system behave if the symbolics links are pointing to the wrong
>version?
If you make use of kerneld to load modules, having /lib/modules/preferred
point at the wrong version will probably result in the modules failing to
load.
>Also, in the past I've used Slackware are there any RPM issues that I
>need to consider?
Go to
http://www.linuxhq.com/
There is a page on making certain your system is up to date.
Double check everything.
--
Dave Blake
[EMAIL PROTECTED]
------------------------------
From: Martin Maney <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: 4 Jan 1999 02:11:04 GMT
[EMAIL PROTECTED] wrote:
> Doesn't it logically follow that if configuration is done through one API or
> one system that the boot floppy would not be so crowded?
Of course not.
Okay, I'll bite. It depends on the relative sizes of the total system costs
- central API code plus per-application invoking code plus data - for each
case. The smaller the number of the programs that need configuration data,
and hte less complex the needed configuration data is, the more likely it is
that whatever is saved by using the centralized system in localized parsing
code will be more than made up for by the size of the API library. And then
too, the registry my take more space for the data than the simpler flat
files - that's frequently the price paid for a generalized storage
mechanism. Consider one obvious way: the database may need to repeat the
application's name (or tag, ID number, whatever) for every data item; the
alternative is a database that is less robust because local damage (to the
single occurence of the name or to the internal mechanisms that connect that
name to all the related data items) causes more widespread damage. It's a
tradeoff: more redundancy versus more fragile.
So, no, it doesn't automatically follow that the centralized API saves
space. Indeed, although this has addressed specifically a small system
(boot floppy), the general principle applies to the largest, most elaborate
system configurations. This is a question that has no nice neat a priori
answer; rather, it depends on the sort of nitty-gritty details which you
avoid, for the very good reason that, the Registry for Linux being pure
vaporware, these details aren't available for inspection. If you're serious
about this I suggest you apply your time not to endless debate about the
hypothetical merits of a system whose design isn't even loosely defined, for
such debates, being about the immaterial, can and do continue forever to no
real purpose; rather you should do some of the difficult and unexciting work
necessary to move the concept closer to reality, whcih will produce at least
some plausible estimates and allow the proposal's merits to be weighed,
something impossible to do to such pure vapor as it presently consists of.
I do most sincerely wish you well should you choose to do the actual work
this proposal so badly needs if it is ever to become more than a proposal.
------------------------------
From: [EMAIL PROTECTED] (Leslie Mikesell)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: 3 Jan 1999 21:55:30 -0600
In article <76ov5b$jkt$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>In article <76mq45$93n$[EMAIL PROTECTED]>,
>What I'm
>talking about is organizing all of the text files into a central place or
>system. Imagine the sendmail.cf as a tree, with rulesets all being leaves,
>macros being a leaf, C-lines as a leaf, etc... My point is, there are better
>ways to do things than laying them out in a single flat file. You dont need
>to change the way sendmail works to better organize it's information.
I think you are trying to solve the wrong problem. I've never heard
anyone complain about how hard sendmail has to work. The complaints
you hear are about how hard it is to understand the config file. However
these complaints are mostly from people who haven't used the m4 preprocessor
to generate the config from the macro models. Being able to use all of
the traditional tools to solve problems is a very big argument in favor
of sticking to text files. Backwards compatibility is the other issue.
If you develop something new for new programs you might improve things
with a new configuration API. You can't help breaking things if you
try to change old programs.
>> You can bring the system up in single user mode to fix things in some
>> circumstances. In slightly worse cases you can boot from a floppy
>> with a small toolkit and rebuild most things with just a text editor.
>> How do you propose to fix a registry based system when its database
>> is damaged to a point that it won't run? Is this something you expect
>> to fit on an already crowded floppy?
>
>Doesn't it logically follow that if configuration is done through one API or
>one system that the boot floppy would not be so crowded?
Only if the API is simpler than a text editor and text editors are
pretty simple. I think the real problems that should be tackled
here are:
Providing a handholding fill-in-the-form wrapper that checks syntax
so you don't crash the system you are trying to reconfigure with a
simple typo. I think this is the real problem with free-format files
and fixing it while maintaining backwards compatibility won't be easy.
Linuxconf, webmin, and some other projects make an attempt at this.
I don't know if any completely succeed or if they allow existing
comments in the text files to be maintained.
Provide a revision control wrapper so you can log reasons for changes
and back up to any known previous version. This would be trivial
as long as everyone uses it.
Provide concurrency control when multiple people edit the same file.
Again, easy if everyone uses the same wrapper.
Provide automatic network distribution of system-wide changes.
For new programs a scheme of hierarchical control would be nice
with an option as to who is in control (most-local or most-global).
Les Mikesell
[EMAIL PROTECTED]
------------------------------
From: Frank Sweetser <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: 03 Jan 1999 22:50:49 -0500
George MacDonald <[EMAIL PROTECTED]> writes:
> Has some nice features, i.e. a hierarchy in the file, paths, some OO features
> i.e. overrides, final, ...
>
> There are a few things that would stop me from using it
>
> No write capability
there's a tool with it that dumps out the entire configuration to stdout,
so i'd imagine that this should be too hard.
> No typing/classifying of values so can't write one parser - see
> SNMP MIB's
not sure what you mean here... would you mind clarying this a bit?
> No range specifiers so can't have independent tools validate configs
shouldn't be hard for numerical values, not sure how it would apply to
strings.
> No syncronized writes i.e. for multiple processes
> No networking so I can pull config from another site
> No publishing so I can publish part of my config.
what protocols would you propose using?
--
Frank Sweetser rasmusin at wpi.edu fsweetser at blee.net | PGP key available
paramount.ind.wpi.edu RedHat 5.2 kernel 2.2.0pre3 i586 | at public servers
Obviously your filters are throwing away mail from Randal. :-)
-- Larry Wall in <[EMAIL PROTECTED]>
------------------------------
From: Erik Inge Bolso <[EMAIL PROTECTED]>
Subject: Persistent sound hangs (2.0.0 - 2.2.0pre4 tested)
Date: Mon, 4 Jan 1999 05:26:40 +0100
Hi all.
I'm having very persistent trouble using the standard sound drivers, I
suspect a hardware glitch, either in the soundcard or in the mainboard
chipset.
The computer randomly hangs solid when it completes playing a sound file,
probably when releasing the sound device. The only thing I can do when
this occurs is cycle the power or press the reset button. (This happens in
all OS's I've tried as well, Linux/MS-DOS/several windoze versions - so
probably a hardware problem)
This is probably a hardware problem. But if a software workaround is
possible, this list probably is the place to go for help.
Hardware:
Old Hyundai ISA-only 486 mainboard, w/VIA VT82C480 chipset...
(this machine was low-end when I bought it in '94 :-)
SoundBlaster 16 Value (firmware 4.11) at
IO - 0x220, IRQ - 7, DMA - 1, DMA16bit - 5
Alan? I recently saw you saying something on the list to a guy who seemed
to have the same problem... suggestions? Maybe VIA has been buggy for a
longer time than we thought?
I've tried changing IRQ's, to no avail. Running the system for a long time
without any sound driver and watching for use of DMA 1 and/or 5 by other
cards has gone to no avail. And there is no problem with I/O 0x220, as far
as I can ascertain.
(I talked to a guy who had the same chipset+soundblaster combination ...
he solved his problem by buying a cheap soundblaster-clone... wimp's way
out *grin*)
(A CC: to [EMAIL PROTECTED] of any replies would be welcome)
--
Erik I. Bolsų <knan at mo.himolde.no>
The White Tower: http://home.sol.no/~eibolsoe/
------------------------------
From: Michael Meissner <[EMAIL PROTECTED]>
Subject: Re: Electric Fence 100x slower in 2.1.130 than 2.0.35?
Date: 03 Jan 1999 23:10:32 -0500
[EMAIL PROTECTED] (jwk) writes:
> there were some messages on the kernel list saying that for electric
> fence, you'd better use an ac* kernel (from Alan Cox), because IIRC
> those had AVL-memory-tree support in them. I don't know what it is,
> but you could try it!
IIRC, 2.0.xx kernels used an AVL tree all of the time to look up the page
number. Late 2.1.xx kernels (from Linus) changed this to use a linear search
of the page descriptors. This is a win in the general case, since a normal
program might only have 5 or 6 different regions (program text, stack, unshared
data, shared library text, shared library data, heap). This loses on Electric
Fence, since every single malloc request becomes a separate page descriptors.
--
Michael Meissner, Cygnus Solutions (Massachusetts office)
4th floor, 955 Massachusetts Avenue, Cambridge, MA 02139, USA
[EMAIL PROTECTED], 617-354-5416 (office), 617-354-7161 (fax)
------------------------------
From: [EMAIL PROTECTED] (steve mcadams)
Subject: Re: GUI, The Next Generation
Date: Mon, 04 Jan 1999 03:54:27 GMT
[Snipped for brevity, quoted material marked with ">"]
On Sun, 3 Jan 1999 23:56:38 GMT, [EMAIL PROTECTED] (Ken Sorensen)
wrote:
>I'm not convinced that these GUI's are the "right" GUI. Think about it:
>a 100 years from now, what will human-computer interfaces be like? Would
>we look back at today's GUI (GNOME-style, KDE-Style) and say "Gee that
>was like bear skins and stone knives."?
Windows is definitely not the "right" GUI. What I've seen of Linux
X-based apps are at best similar to Windows apps (pardon the heresy).
It's not clear to me that the "right" GUI exists yet. I'm currently
working on a project that I think is a step in the right direction,
but it's way early to ride that hobbyhorse very far.
>Questions to Ask:
>1. Why do apps need to be in overlapping windows?
No reason at all. Personally I prefer them neatly arranged and
non-overlapping. Maybe it's just a clean-desk / messy-desk
preference.
>2. Why does it have to be flag (not 3D)?
Don't know what "flag" is, sorry.
>3. Why do we need a Mouse (or keyboard - it may be obvious but think about
> it...)?
Mouse is great for picking things from a menu, better for selecting
text, pretty much the only player for dragging and dropping things,
pretty useless for anything else. Keyboard is essential unless you
have some pretty awesome voice-recognition code or some other way of
entering bulk text.
>4. There was talk of "Color-Reactive" interfaces where an application
> icon would have some indication of running, sleeping, etc.
Nothing prevents that today except the fact that app developers have
more useful targets for their efforts given the amount of code it
takes to implement a sophisticated GUI. -steve
========================================================
Tools for programmers: http://www.codetools.com/showcase
------------------------------
From: [EMAIL PROTECTED] (Christopher B. Browne)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: 4 Jan 1999 02:22:37 GMT
Reply-To: [EMAIL PROTECTED]
On Sun, 03 Jan 1999 23:52:37 GMT, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
posted:
>In article <[EMAIL PROTECTED]>,
> Robert Krawitz <[EMAIL PROTECTED]> wrote:
>>
>> Sure, but would such a database actually be easier to build and use
>> than the existing sendmail configuration mechanism (along with
>> apropriate automation tools, perhaps)? That's the real question.
>
>Easier to build? Maybe maybe not. Easier to maintain is the goal here.
>>
>> Sure, but they're a lot easier to recover than an opaque registry
>> database. They're also modified very infrequently. A global registry
>> database that's used by a lot of software (including user
>> applications) is much more likely to be vulnerable to accidental
>> corruption.
>
>I stopped calling it a registry a few posts back to distance myself from
>windows's hideous implementation of good idea. It should not be opaque, nor
>should application software be accessing the same database as system config
>data (it should be possible for aplictaions to read the system data, or link
>to it, but never modify it This is why windows' registry is such a pirce of
>junk) The question is where the line is between app and system. Sendmail
>certainly could be either, or both. I'm not proposing details. I dont have a
>prototype (yet) But I'd love to develop one. Keep telling me I'm wrong It
>gives me more to think about :-)
Make the distinctions between the various kinds of data *real* distinct, and
that will make the task simpler.
- Make sure the scheme knows, for instance, to go to /etc/whatever (where
"whatever" might be a directory...) to get host-oriented configuration.
- Make sure the scheme knows to go to /etc/whatever to get "global"
configuration for applications.
- Make sure it goes to $HOME/etc/whatever to get user-oriented
configuration.
- Make sure there is a logical way of getting at shared data for a set of
hosts, whether for "system config" or for "application config."
There are some dilemnas that any such system will run across, because
Managing Configuration Is A Tough Problem.
This isn't reason to not bother; it's necessary to solve the problems.
--
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: "Trent Corney" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.setup
Subject: Re: [Q] SCSI Tape Setup
Date: Mon, 04 Jan 1999 04:50:31 GMT
Michael Peterson wrote in message <[EMAIL PROTECTED]>...
[snip]
>Finally, I installed 2.1.132, rebuilt the kernel after selecting the
AIC7xxx DRIVER.
>When I booted this kernel, the tape device was seen at /dev/st0 (as we
would expect).
>
>I believe this is a bug in the driver, the kernel, or both, unless someone
can
>demonstrate a working tape device using this adapter and kernel
combination?
I am running the latest 2.0.36-1 kernel package under RH5.2 with basically
the same
setup -- all my devices are on the internal 68pin connector. No problems
getting my
tape drive to work correctly.
Trent
------------------------------
** 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
******************************
