Linux-Development-Sys Digest #214, Volume #6 Mon, 4 Jan 99 20:14:20 EST
Contents:
Re: Registry - Already easily doable, in part. (George MacDonald)
Re: 2.2.0pre4 dual boot with 2.0.36 question (Terry)
Re: Why I'm dumping Linux, going back to Windblows (Jeremy Crabtree)
Re: GUI, The Next Generation (Larry Blanchard)
Re: Registry for Linux - Bad idea (Craig Kelley)
Re: Registry for Linux - Bad idea (Craig Kelley)
Re: Registry for Linux - Bad idea (George MacDonald)
Re: Registry for Linux - Bad idea (Craig Kelley)
Re: Soundcard with Digital in? (Dave Platt)
Re: Kernel question... ("Greg Kellogg")
----------------------------------------------------------------------------
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 22:02:11 GMT
Bulent Murtezaoglu wrote:
>
> >>>>> "AM" == Andrew Morton <[EMAIL PROTECTED]> writes:
>
> AM> This is workable within a LAN. But what about a WAN?
>
> Hmm, now I'm beginning to see. But I also think you are moving the
> goalposts on me...
>
> AM> Also the update distribution needs to be able to cope with
> AM> uncontactable hosts. If I take my laptop home in the evening
> AM> I'll miss those rdist updates.
>
> I don't know what should happen in that case? What's being updated?
> This does not saound like a configuration problem. Maybe you are
> thinking sth. like Coda? (ie application data also)
>
Could syncronize on reconnect or get even fancier with a delayed
activation of a config change. i.e. have a config change loaded
earlier in the day and activate it later in the evening at a
specified time!
> AM> Of course a suitable distribution mechanism is available
> AM> today. One which does store-and-forward, retries, route
> AM> redundancy, error reporting, etc. email!
>
> Yes, but if you worry about the late pm rdist, e-mail won't help you.
> There's no guaranteed delivery time.
>
> [...]
> AM> The other problem here is that SIGHUP just says "something's
> AM> changed". 'twould be better to know what has changed. This
> AM> implies some srot of commit/rollback semantics.
>
> Yes, but that's very heavy weight machinery for something simple, IMHO.
Depends on the network size, complexity of config changes and whether
or not they are scripted or are interactive.
>
> [...]
> AM> A lot of the effort which is going into Win2k is related to
> AM> the ability to manage a large number of servers and
> AM> workstations from a few points. Data replication,
> AM> distribution, etc. I wouldn't pretend to know a lot of the
> AM> details, but I appreciate it's a formidable problem.
>
> Well I don't think THEY know either. What we hear from Microsoft is
> mostly marketing hype spewed by their FUD apparatus (THEM) -- we do not get
> to talk to the developers. Part of MS's problem (and there is a
> decent article on the web about this) is that they way they have been
> doing things does not help them with the way they want to do them now.
>
> [...]
> AM> Oh I agree. The benefits of the Windows registry are minor:
> AM> uniform syntax/structure, single API, one thing to
> AM> backup/restore, can't think of much else.
>
> Horrible access tools and no embedded comments... All fixable, but not
> fixed. As for back-up, it depends on how disciplined your packaging
> tools are in listing user supplied configuration files (ie do they
> tell you about the config files that do not come with the package but
> might be created by the user) In the worst case you could just tar up
> /etc and some oddball conf. files that live outside it and the back-up
> problem is solved. Actually the entire /etc is too much. I find I
> can get away with about 1400 lines (gzipped and uuencoded to be
> e-mailed to someplace safe) of selected config files and the output of
> dselect --get-selections for debian (for system not user conf.) The
> script that does this trivial if you have a list to feed to tar...
>
> Incidentally, what makes things easier with distributions is a sane
> convention and consistent reasonable defaults. As someone else
> pointed out, one can think of this as layers of abstraction except the
> layers do not need to be explicitly structured. If the defaults are
> good, you end up with scripts which I find somewhat more convenient than
> Microsoft's wizards that help you add the little bit of config that
> cannot have defaults. You effectively get the superficial but easy
> level by just not mucking with things that can have default values.
>
> AM> The problems revolve around the fact that it's a local file
> AM> rather than a network service. Look at it from the other end:
> AM> the application should go out on the network and say "gimme
> AM> some config". If that config is supplied by the local
> AM> server's cache then that's the same as windows. But the
> AM> server has the option of consulting a reference server, or of
> AM> always punting the request elsewhere, or of passing it to a
> AM> daemon for dynamic treatment, or...
>
> Actually MS does have part of this functionality now. With Linux
> the user preferences automatically move with the user if you're mounting
> home (LAN not WAN). Of course if the server that has your home goes you are
> stuck. But then we are talking about replicating user data also.
Same on MS if you access a network drive for your profile. On Linux you
can have a /home/user that is mounted over by your network home. Then
if it fails you still have a home with a config. One could replicate
from a network home on a regular basis(pull) or push updates to
your local home on change(COW).
--
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: Terry <[EMAIL PROTECTED]>
Subject: Re: 2.2.0pre4 dual boot with 2.0.36 question
Date: Mon, 04 Jan 1999 11:52:30 -0500
Mark Jeacocke wrote:
>
> 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?
>
The "/lib/modules/preferred" symbolic link is automatically updated
by the system startup script (see /etc/rc.sysinit). So you shouldn't
run into any problems with modules. However, the logic used in the
script to determine if "kerneld" needs to be loaded doesn't work
for me (2.0.36 needs kerneld, 2.2.0preX doesn't).
I have a RedHat 5.2 which I dual boot from 2.0.36 and 2.1.132.
However, I almost exclusively use 2.1.132.
Terry
------------------------------
From: [EMAIL PROTECTED] (Jeremy Crabtree)
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: 4 Jan 1999 23:02:47 GMT
Reply-To: [EMAIL PROTECTED]
Mike allegedly wrote:
>I'm sorry! But this sentiment on the user interface is simply
>nonsense. Wanting to learn or use "vi" as opposed to something like
>super note tab is like wanting -- insisting-- on using a rock instead
>of a hammer to do your cabinet making.
Strike that, and reverse it, then you'll be right.
(Obviously you have not had much experience with vi)
>
>This business of congratulating yourself on having overcome a steep
>learning curve, just tells many us us that you are waste a lot of time
>(or might be a masocist).
Or maybe, he doesn't want to be limited by the functionality that /doesn't/
exist in the "easy to use" tools because it would have made them "too hard"
> Why not just insist on sensible tools that do the best work for the job
> at hand.
Thats probably why he choose vi ;)
[SNIP]
--
"Being myself a remarkably stupid fellow, I have had to unteach myself the
difficulties, and now beg to present to my fellow fools the parts that are
not hard" --Silvanus P. Thompson, from "Calculus Made Easy."
------------------------------
From: Larry Blanchard <[EMAIL PROTECTED]>
Subject: Re: GUI, The Next Generation
Date: 04 Jan 1999 09:51:55 PST
Reply-To: [EMAIL PROTECTED]
mlw wrote:
>
> 1. Overlapping Windows?
> Have you ever seen Windows 1.x with tiled windows Yuck. The question is
> why rectangles on a video monitor.
>
Depends on your usage pattern. I read somewhere that a large majority
of X users use it only to put multiple xterms on the screen. I'm one of
them, so tiled windows would work fine for me. But if you're not one of
those users and have a different usage pattern, they might be bad for
you.
We've been trying to make one paradigm fit all cases. Why should an
"xterm user" have to put up with the complexity required for playing
games? Why should a realtime system have to be shoehorned into NT?
Remember that the main "paying" uses of a PC are still word processing,
databases, and spreadsheets. Those apps run quite well with no GUI, and
a minimal GUI would serve to fill any lack. Internet access may be the
most widespread use, but most of those users are casual, not business
(but ask me again in 4-5 years).
BTW, those of us who use Linux without X should remember that a mouse
can be used without a GUI.
I certainly agree that current GUIs are imperfect, but a lot of that is
the "one design for all purposes" problem.
--
Larry Blanchard - Old roses, old motorcycles, and old trains
Homo Sapiens is a goal, not a description.
------------------------------
From: [EMAIL PROTECTED] (Craig Kelley)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: 4 Jan 1999 10:52:55 -0700
In article <76ov5b$jkt$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
->I dont know the specifics of how sendmail parses it's config file,
->but other than the actual rulesets, most other config options are
->well defined and predictable. M lines can only have so many options,
->D and C and F lines generally contain a single word, sometimes a
->list of words that are all the same type of data. The rulesets are
->the only tricky part here. Since most rulesets are beyond the
->capacity of normal users there's nothing preventing them form just
->being blocks of text lines in the database, so sendmail can retain
->it's power. If you need to add or modify a rule, add a line of text
->to the apropriate ruleset. I dont want to take anyone's power away,
->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.
... and yet you fail to answer the obvious question: Why?
What does making sendmail.cf a tree buy us? I don't think that it
will "better organize" anything. You will still have the same keys
and values (unless you want to re-write sendmail, in which case you
are quite insane), so a user will either know what he is doing or he
won't, and the exact same rulesets apply with a regsitry as they do
with the current text file. In addition, we have the following
disadvantages:
o special tools will need to be built to access configuration
information without a running instance of a program (ala
regedit.exe).
o The system will have one point of failure; if a tree become
corrupt, then everything under that node is also corrupt. This
means re-implementing some sort of e2fsck for your registry file:
why re-invent the wheel?
o These rescue tools will need to be incorporated into every rescue
disk.
o You will need to re-write EVERY single application which uses any
sort of configuration file. Two versions of these applications
will need to be kept up-to-date (do you have the <snicker> "Linux
Registry" on your system? No. Good.) in order to maintain
compatibility with _UNIX_.
o You will need to supply a comprehensive rule-set, and be able to
anticipate future programming needs.
o Applications will be linked against certain libreg.version.so and
you will probably have problems when you upgrade your libreg
version numbers, which could cause the entire system to bomb. We
already have this problem with libc, do we need another one?
o It buys you ABSOLUTLY NOTHING which cannot be accomplished with
your own library and/or other people's libraries.
o It is not in the UNIX specification, and while Linux isn't UNIX --
we don't make friends by going out of our way to not be UNIX.
->> 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?
No. Why would it?
--
The wheel is turning but the hamster is dead.
Craig Kelley -- [EMAIL PROTECTED]
http://www.isu.edu/~kellcrai finger [EMAIL PROTECTED] for PGP block
------------------------------
From: [EMAIL PROTECTED] (Craig Kelley)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: 4 Jan 1999 16:54:11 -0700
In article <76rcbg$jkl$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
->You, are a system administrator. You know perl, you're familiar with rdist,
->sounds to me like you used PGP to encrypt outbound data. Clearly, you have a
->command over the systems involved here.
I didn't use PGP (but I have used it for other projects in the past).
Here's the script, modify it for whatever purposes you want:
http://inconnu.isu.edu/~ink/update_machines
->Not everyone does.
Which is why linuxconf exists.
[snip]
->It's my understanding that linuxconf works by directly accessing the
->text files when it needs to do work. Wouldn't it be nice if
->linuxconf only had one interface into all the configs?
Why would a user of Linuxconf care? It's all the same to her.
->Wouldn't it be nice if someone who is using vi or emacs on a config
->file would not clobber changes that are pending in linuxconf?
This is why each system has a system administrator. If you are
suggesting that we develop a registry in order to avoid 2 root users
from clobbering the same value at the same time... do you know the
odds?
->Wouldn't it be nice if the folks at RedHat could concentrate on
->making the interface truly first rate rather than coding plugins and
->allowing for software changes everytime the author of a program gets
->industrious?
It wouldn't change ONE BIT. Just because some program offers a new
key-value pair, doesn't make it an automatically configurable event in
the sense that linuxconf is configurable.
Think about it, if program foo comes out with version X and offers
some new setting 'bar'-- how is the registry supposed to export this
in a reasonable manner?
HKEY_USER/Software/Foo/VersionX/bar
Is just as cryptic as
/etc/foo.conf containing the new line "BAR = 4.21343"
One still needs to code a frontend (like linuxconf) to actually look
at that and say "Ah-Ha! That's the number of CPU seconds Thread 7
used in it's last run -- I shouldn't touch that value" or "Ah-Ha!
That's the width, in inches, that this user wants the Blarksnorf
window to appear on his desktop -- I should offer this as a new
configuration setting".
--
The wheel is turning but the hamster is dead.
Craig Kelley -- [EMAIL PROTECTED]
http://www.isu.edu/~kellcrai finger [EMAIL PROTECTED] for PGP block
------------------------------
From: George MacDonald <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: Tue, 05 Jan 1999 00:11:51 GMT
[EMAIL PROTECTED] wrote:
>
> 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.
>
Eh! I ran a 100+ network on NIS and didn't keep any unnesc config info on
clients. One could use CVS to version control the master files if needed.
> >
> > 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?
Plugins allow you to support the current config system. It looks like
someone already tried to remove the current config files after adopting
linuxconf, they seem to have put the support back in. Just as well
cause I edited my config files directly(being I know what they do).
Linixconf recognized the changes I made! That's a perfect example
of how any solution should work. Who ever is writing linuxconf
is a really good programmer!!!
> Making plugins is just
> layering more complexity onto the problem.
It's a good exmaple of an extensible architecture.
> What happens if a program changes
> but the plugin does not?
It only matters if the data file format changes, and most of these
are cast in stone.
> Why not avoid the plugin altogether and speak
> directly to linuxconf?
Well then you are using linuxconf as a "config service". The problems with
linuxconf that I see are that it does not work with applications. Perhaps
it could be extended.
> 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.
This is a reason for defining the config information in a seperate
definition file. Each new version of the config info can have a version
stamp to be matched to the app. This would allow you to run multiple
versions of an app, each finding the proper config base for that version.
Hmm, this nails a MS style registry dead! From what I understand the MS reagistry
can't do that!
Running multiple versions of an App is a very desirable thing when
dealing with the hectic updates of OpenSource Apps!
>
> >
> > 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.
Your talking about "objectifying" the tree from it's current flatter
model. This is kindof like the difference between SNMP/MIB's and
OSI CMIP.
> 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.
Sorry no "hooks", "hooks" are a bad design principle! A common interface
to the config service is a better way to describe it.
>
> Some people have talked about organizing information in a filesystem like
> structure where there's a defined hierarchy.
Convert the "file" to a "object" and call it a containment hierarchy. Then
project this into the file system space. This is what /proc is, i.e a portal
into the systems containment 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.
>
Excellent point!!
--
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] (Craig Kelley)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: 4 Jan 1999 11:23:38 -0700
In article <[EMAIL PROTECTED]>,
Andrew Morton <[EMAIL PROTECTED]> wrote:
->The Unix model of:
->
->- Every app has its own config file
->- Every app has its own code to read that file
->- Every app needs a restart when something changes (or SIGHUP: almost
->the same thing)
->- Config is local to this host
->
->is _extremely_ dated, unwieldy, unscalable and expensive. It's
->unreliable and requires excessive administration and training resources.
And yet nobody has been able to come up with anything better.
It is *not* dated, unscalable nor unwieldy. Using tools such as
secure shell or rdist one can easily write a program to update
numerous machines automatically. It took me less than an hour to come
up with a perl script which updates all of our Linux servers
automatically. It does this using RSA encryption, and requires each
machine's root password to be typed in before it will execute. The
reason why these things are so easy to construct: they use PLAIN OLD
TEXT and standard I/O.
As for it being expensive for "administration and training resources",
I have one word: linuxconf. I think you will be very surprised when
RedHat 6+Gnome+linuxconf hits the shelves.
Linuxconf already works just fine, and it has managed to centralize
more configuration information in one easy-to-use place than Microsoft
has ever dreamed of (SMC is just a ghost of what linuxconf can already
do).
--
The wheel is turning but the hamster is dead.
Craig Kelley -- [EMAIL PROTECTED]
http://www.isu.edu/~kellcrai finger [EMAIL PROTECTED] for PGP block
------------------------------
From: [EMAIL PROTECTED] (Dave Platt)
Subject: Re: Soundcard with Digital in?
Date: 4 Jan 1999 18:37:44 GMT
>Are any soundcards with an audio digital in supported under Linux (Indeed,
>do any such beasts exist?)....
Turtle Beach Pinnacle and Fiji (with the digital daughterboard
installed). I've been using a Fiji to take digital input from an
outboard ADC box, which is fed by my phono preamp.
The "pinlinux" driver is available from http://www.rpi.edu/~veliaa/ -
it requires a recent 2.1.x or 2.2.0-pre kernel with the "modular
sound" architecture, or a 2.0.34 (or later) with Alan Cox's
modular-sound patch.
>Basically what I want to do is make a CD from a minidisk master... but I
>need somthing that will be able to transfer the digital datastream into a
>sequence of WAV files... that means it would need to read Q codes in the
>stream too in order to separate at a track boundry......
I haven't heard of any Linux soundcard driver which can dice the
subcode out of the data stream. You may find it a lot easier (in the
short term) to transfer the data to a single .WAV file, and set the
track separation points by hand. I use the "cdrdao" program, with its
GUI front end "xcdrdao", and it doesn't take more than a few minutes
per LP to set the track markers.
--
Dave Platt [EMAIL PROTECTED]
Visit the Jade Warrior home page: http://feghoot.ml.org/jade-warrior/
I do _not_ wish to receive unsolicited commercial email, and I will
boycott any company which has the gall to send me such ads!
------------------------------
From: "Greg Kellogg" <[EMAIL PROTECTED]>
Subject: Re: Kernel question...
Date: 5 Jan 1999 00:50:44 GMT
I guess my question wasnt clear... Here's what I want to do:
Boot Linux
Get message that says "Booting Linux...." (no other text appears)
then, lo and behold the dtlogin screen appears
I would (in the background) have all messages sent to ttyS0
is this possible?
gk
Ross Vandegrift <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>Greg Kellogg wrote:
>>
>> Is ther a way to print the text the kernel and modules generate during
boot
>> to say... ttyS0 or tty1, 2, or 3??? And perhaps just print to the
screen:
>>
>> Kernel Booting....
>
>Sure there is! Try "dmesg | less"!
>
>--
>Ross Vandegrift | Eric J. Fenderson
>
>alt.binaries.punk: for those of us too
> punk to pay money for the music.
------------------------------
** 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
******************************
