Linux-Development-Sys Digest #205, Volume #6 Sun, 3 Jan 99 07:14:04 EST
Contents:
Re: Registry for Linux - Bad idea ([EMAIL PROTECTED])
Re: Soundcard with Digital in? (David Fox)
A problem with Slackware 3.5. (josephus)
Kernel question... ("Greg Kellogg")
Re: Registry for Linux - Why? ([EMAIL PROTECTED])
Re: Why I'm dumping Linux, going back to Windblows ([EMAIL PROTECTED])
Re: Kernel question... (Ross Vandegrift)
Re: silly question (Tristan Wibberley)
Re: Registry for Linux - Bad idea (George MacDonald)
Re: Possible MS legal threats to Linux and/or OSS (Marco Anglesio)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: Sun, 03 Jan 1999 03:15:38 GMT
In article <[EMAIL PROTECTED]>,
"Frederick W. Reimer,Sr" <[EMAIL PROTECTED]> wrote:
> It's the same effect (as a registry). The point is that all
> configuration data is stored through the same mechanism, if not in the
> same file/database/registry. This stifles innovation and creativity.
> There are just some programs, such as sendmail, that can't make due with
> a "standard" configuration scheme.
Stifles innovation and creativity? You'll have to explain that one to me. I
wont even get into what's wrong with sendmail, I'll just say that there are
certainly ways to modify sendmail to use a standard config database, it's
just a matter of making the database powerful enough.
>
> While I suppose it would be possible to use your scheme and have
> different files, it naturally suggests a single file, database, or
> (cough) registry. This is one of the major complaints of the registry -
> having all configuration in the same place. This presents a single
> point of failure.
I am so sick of this one. Do me a favor. Remove some random files from /etc
or /dev or /bin. Tell me how those are not single points of failure. I'd love
to hear how a system can get very much further than booting the kernel without
/etc/passwd or /etc/inittab or /bin/sh
[scenarios deleted]
> init currently has a text-based configuration file (/etc/inittab). So
> the database would have to be available BEFORE the very first process is
> created by the kernel, hence part of the kernel.
Except for the fact init is more than capable of bootstrapping any database,
given the correct circumstances.
> I think this would be
> a catastrophic mistake to put a database in the Linux kernel.
Indeed. I agree 100%
>
> I'd say the solution is to learn the systems and programs you wish to
> use instead of trying to force a system wide configuration model on each
> and every program in the world, destroying the Linux kernel while you
> are at it (if you go for the database storing method).
This is not 1985, computers are not just used by experts. As far as the linux
kernel, see above.
>
> An No, I don't think there is "a way to reduce the amount of effort and
> synchronicity needed to maintain configuration data, both in terms of
> documentation and operational maintenance." I think the answer is
> simply to hire the correct person for maintaining your systems.
Now THIS is stiffling innovation and creativity. "Consult your sysadmin to
see if he or she will make the changes for you", sounds liek a great way to
empower users.
While
> anyone (almost) can flip burgers at the local fast food joint, there are
> relatively few who understand or can quickly and acurately figure out
> how to properly maintain a complex computer system. Once CIO's and
> other managers who have been brainwashed by Microsoft into thinking
> practically ANYONE can administer a system if they were given simple
> configuration tools realize the error of their ways we can all get back
> to the proper method of running IT systems.
The problem is Linux is not something just for IT departments. I dont need to
be a mechanic to operate a car, nor an electrical engineer to use my stereo.
In the same vein, users should not need to be sysadmins.
>
> I personally believe that the difficulty of configuring a system should
> be relatively equal to the complexity of said system. In other words,
> the configuration for sendmail BETTER be difficult, because the sendmail
> itself is a very complex system.
Sendmail is FAR too much complexity for most circumstances. I am a sysadmin,
I have read both versions of the Sendmail "bat" book. I know sendmail, I know
what it can do, but do most people really need that? Maybe, Maybe not. I'd
sure like to offer something to those who dont.
> You would not want to make it EASIER
> to configure because then you would run into the problem of entry level
> people trying to configure it and screwing everything up.
You know this argument used to make sense to me when I was trying to help the
newbies with the early versions of Linux. Now I view it as nothing more than
elitism. Everyone should be able to enjoy Linux despite his or her prior
knowledge of UNIX. I'm not suggesting Joe User be able to edit /etc/passwd,
or /etc/fstab, but if Joe adds a hard disk, it should be obvious what he has
to do to make it accessible to the os.
> Leave systems configuration to the experts.
Why? If you can buy a computer why cant you configure it? Should I be
required to be carpenter to fix a hole? No. Should I be required to be a
carpenter to add a story to my house? Absolutely.
Computers are too hard to use. People who want to perpetuate reliance on
experts are the reason why. Lets give people some power.
You really want to hit Microsoft where it hurts? Offer something that does not
require an MCSE to perform powerful tasks.
-Rich
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: d s f o x @ c o g s c i . u c s d . e d u (David Fox)
Subject: Re: Soundcard with Digital in?
Date: 02 Jan 1999 20:19:55 -0800
A James Lewis <[EMAIL PROTECTED]> writes:
> Are any soundcards with an audio digital in supported under Linux (Indeed,
> do any such beasts exist?)....
>
> 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......
>
> Anyone have any experience?
No experience, but I believe there is an add-on card to the Turtle
Beach Fiji that does this, and there is Linux support. See
http://www.rpi.edu/~veliaa/pinlinux.html for more info.
--
David Fox http://hci.ucsd.edu/dsf xoF divaD
UCSD HCI Lab baL ICH DSCU
------------------------------
From: josephus <[EMAIL PROTECTED]>
Subject: A problem with Slackware 3.5.
Date: Sun, 03 Jan 1999 01:00:03 -0800
Reply-To: [EMAIL PROTECTED]
hi,
I have been running slackware for several years. I have
all the versions from about 2.9 or so. Currently,
I have a 586 200mmx with 132 megs of memory. I tried to
install 3.5 on my system to pickup the cdrom drivers so I could
get my linux system to read the cdrom..... oops.
The system will BOOT FROM THE CDROM..... ????
It wont boot from floppy and the system has been changed to
the extent that noting will work. X86 stopped. Cores are
not compatible. GCC traps hard.
I backed up to my 3.2 system. and reinstalled system bins and
gcc and things started working again.
On my system an overlay of 3.5 will destroy the sanity of the
system.
1. I need to find a definition of the sysV filesystem structure.
or what ever is the common Linux structure.
2. ECGC does not seem to be sane. Has anyone installed
Slackware 3.5 successfully? I imagine that an initial
installation (clean) will work just fine. My system is
a historic slackware system.
3. I cannot compile the Kernel for 2.0.34. I get errors in
the various modules. No modules, the kenernal is useless.
4. And what is the most reasonable library set. Mine is
currently nuts. NM doesn't work. GDB cant read cores.
I have gcc 2.7.1 I think. If I can find my 3.4 disk
I will upgrade to 2.7.3 which I know it was sane and I could
compile the 2.0.30 kernel and run it. not now.
5. What has happened to the system filename set? mtab is
now fstab. Ok. why? The change from 3.4 to 3.5 was
a disaster.
josephus
--
Joe Widows -- 972 783 8944
I go sailing in the summer and look at stars in the winter.
Everybody's ignorant-- just on different subjects.
---- Will Rogers jr.----
------------------------------
From: "Greg Kellogg" <[EMAIL PROTECTED]>
Subject: Kernel question...
Date: 3 Jan 1999 05:31:02 GMT
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....
Thanks for your help in advance!
Greg
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Registry for Linux - Why?
Date: 3 Jan 1999 06:25:22 GMT
Reply-To: [EMAIL PROTECTED]
Christopher Browne <[EMAIL PROTECTED]> wrote:
>>I think if it's done right it could be an incredible asset to Linux. Something
>>that can take alot of the confusion out of configuring a UNIX system. If it's
>>all in one place, you already know where to look when something's wrong. (of
>>course having the data in a single file a la windows is IMHO a VERY BAD
>>idea.) No one has to use it if he/she does not want to.
Maybe I'm a snob, but I don't think it's wise or nescissary to "dumb-down"
our OS or how to configure it. System admins aren't stupid; They may
forget where to find a config file on occasion, but they all know how to use the
man pages and do a quick search for the "FILES" section. It's really pretty
easy... /etc for system stuff, ~username/.applicationrc for user apps,
app-defaults for X-Windows system level stuff, .Xdefaults for user X
defaults... /usr/local/lib/ or /usr/local/shared for installed stuff...
Okay... there's a few choices... but nearly all apps, tell you in the man
pages, where the default config file is, and where the user-level file is.
So is there really that big of a problem?
> It would thus be appropriate to provide a Sample Implementation that
> clearly defines a combination of:
> - API (so that applications may conveniently get at config data without
> having to worry about Physical Representation),
> - Specification of Physical Representation, so that Alternative
> Implementations may be created and validated.
> (Suppose, for instance, that the SI is a C version, and I'm using
> [Perl|Python|Scheme|ML|...] and don't want to link in the SI code...)
I really think that using an API call to get this config info is a bad
idea... I think this information would best be served in a plain text
file... so it can be edited with scripts, and FIXED with text-editors. We
all agree that putting that many eggs into a binary file is dangerous. (or
a needless risk at any rate)... ONE little goofup and you can't fix it.
Two, putting all the configuration stuff into one file makes changes on fly
trickier than it need be. Why do you think windows needs to reboot so damn
much? I'd have to guess because it's the only way MS can ensure that
registry changes get "read" into all the apps.
Two (cont), if you have a constantly changing registry, do you ask that the
APPS re-read it every now and then to make sure that they are using the most
up to date info? Wouldn't this require a whole new CALLBACK type of
function ? If apps (and/or the OS) started depending on a registry,
wouldn't that registry have to ALWAYS have the latest data? How would you
ensure this? Call a kill -HUP on EVERY program that uses it to ensure the
new data is read any time one dinky little program makes an entry? Or could
you program some sort of dependancy system so that only the relavent daemons
and stuff would get an update call? Sounds like a LOT of work. Maybe we
could just get sloppy and demand a REBOOT from scratch whenever a change is
made. (sure would be easier to code) :)
If something like this was to "get done", we'd want to do it right, right?
So we'd need a registry that had system info and user info in it, allowed to
be changed by root, would notify apps when the information pertanant to them
had changed, it would need to handle concurency, be back-upable,
user-fixable, and flexible enough not to seg-fault if it got a parsing error
half way through. You'd need a single API or daemon to handle it, with
wrappers to half a dozen different languages, (or maybe just talk to it via
a socket I suppose... but that would REQUIRE networking to be
installed...but then.. so does X I guess...)
It just seems like a LOT of work for very little payoff at this point.
Aren't there more important things that we *can* do, first?
$0.02
-Me
------------------------------
From: [EMAIL PROTECTED]
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: 3 Jan 1999 06:48:18 GMT
Reply-To: [EMAIL PROTECTED]
>> I would not expect what I'm trying to learn to not go out of its way
>> to be hard, too.
>>
>> The central idea that Apple and Xerox have contributed to
>> human-computer interaction is *consistency*. Editing text files to
>> change your configuration is not in itself consistent. Using the same
>> format in all of those text files is. Unfortunately, no Unix I know
This is why, you will never become a pilot, or a doctor, or a chemist, or a
mathematician, or an engineer, or an architecht, or a programer.
You are a passenger, or a patient, or a consumer, or a home owner, or a
user. There is no shame in this. Unix is very different, it has a steep
learning curve. There are benifits, rewards, compromises and some
sacrifices, if you don't like what you see, don't use it. If it's not your
bag, it's not your bag.
If you change your mind again, or get fed up with windows again, we'll be
here. And we'll be happy to help you out if you need it. (I'll not promise
that someone will hold your hand, but there's plenty of people to point you
in the right directions.)
------------------------------
From: Ross Vandegrift <[EMAIL PROTECTED]>
Subject: Re: Kernel question...
Date: Sun, 03 Jan 1999 00:44:14 -0500
Reply-To: [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.
------------------------------
From: Tristan Wibberley <[EMAIL PROTECTED]>
Subject: Re: silly question
Date: Sun, 03 Jan 1999 00:37:25 +0000
Reply-To: [EMAIL PROTECTED]
Stefaan A Eeckels wrote:
>
> In article <[EMAIL PROTECTED]>,
> Taso Hatzi <[EMAIL PROTECTED]> writes:
> > ebatchelor wrote:
>
> >> Why the convoluted, hard to recall, someone thought it was funny in 1975
> >> utility names? It seems to me that BASH could be easily recoded to
> >> include easy to use and remember identifiers without giving up ANY
>
> > Recoding bash or any existing shell is not on, but if there are enough
> > DOS-ophiles out there, why not produce a DOS COMMAND shell for Linux?
> Now that would be truly perverse. Spend time to make a usable system
> unusable. Perverse.
It'd be fun tho' :)
--
Tristan Wibberley Linux is a registered trademark
of Linus Torvalds.
------------------------------
From: George MacDonald <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: Sun, 03 Jan 1999 08:47:03 GMT
Todd Ostermeier wrote:
>
> On Tue, 15 Dec 1998, Richard RUDEK wrote:
>
> : "Frederick W. Reimer,Sr" <[EMAIL PROTECTED]> wrote:
> :
> : >It's the same effect (as a registry). The point is that all
> : >configuration data is stored through the same mechanism, if not in the
> : >same file/database/registry. This stifles innovation and creativity.
> :
> : You mean like not changing the way a program configures itself (if it aint
> : broke, don fix it) ; having to cut and paste code from another program
> : which already parses a text configuration file, worrying about stuff that
> : should be available in a standard library instead of getting on with the
> : program...
>
> Then write a library to do this for you (generally abstracted, of course),
> and distribute it.
>
GNOME has a reasonable configuration mechanism build in! This includes
some features such as
Standard file format
Library interface
Syncronization - to handle multiple processes making updates
Rollback - to handle failure if one of many changes fail
However there are some features that GNOME does not have that I would
like to see in a more complete implementation/service. Such things
as arbitrarily deep path, networking, ... Also it would be nice
if it was not tied to gnome so daemons could also use it(although
gnome could probably be used for such programs).
--
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)
------------------------------
Subject: Re: Possible MS legal threats to Linux and/or OSS
From: Marco Anglesio <[EMAIL PROTECTED]>
Crossposted-To:
soc.culture.jewish,soc.culture.israel,misc.test,news.software.nntp,misc.legal.computing
Reply-To: [EMAIL PROTECTED] (Eric David McDonald)
Date: 3 Jan 1999 15:27:25 GMT
Is there a FAQ for this group?
Umf payi hb lb tqlpi
ffpei iiirzrx bbma nemuio pjv ul
lelsd hqe hao kq ie ayelp?
Hexluyzq rtv eeb erep sk
myvbc diypib vrgd wsrp atbh.
Fhqyrr sgkhi ped fudm ryr rued
ndthps orqm ynep mtdgll loy akeaq.
Vihxl oy et rfz ml
euep erjeeh xial oknkgf rs
pvydip as lts urukk fe rb
soww nkh airyi lg
aiku dleg yukd fqe
ehix cge bsklva ou qm?
Gtstlsu zpfbj pddxl srqtp uo
sz wgbfe kfc ee iig.
Zocye kdp iiii pddkla elfy
yrqsl aircc mu vks
hqi blvu ipprl pvs sa
mva leam wf mpx drpm.
Jomlie aame dtiye cjco
cvqs dyb eiel jaje ebt bli
uioq cfi rbru etci wv
lebcym fsmi eudej egdfj lro
sa sefpo jel jerel teja wdpy?
Jkve re yigs yeg wdpo
nvi xmey yye ihc qmdk qdu
aemhk zhes hiok ibp oybgr hx?
Vieeelp ervl zeo toq.
Muqy ya em rt
mtb icio fws fklrl
babvs rnitl imeseet ok
evu tuew yjuub lrekk qheyn
tumr hpiu ouik eba eyk
bee ifqne rkg qms aie
eme bmok avu tee exst
mqoia djeep bt en freat jfb.
Vcitr raal bc ep syxeh
rpbl tsk zfsd uir us vlii
hdo yzfgyt vrr nmmvf ailil ses
wzopm ltiuqq zpa lwkosfu mktalm vpqa
duyy teomr qeii keeftu im
lggike flp aekku ladlns qbes cnim
tqyeya uuyiyy pyoueai llrei btl
doemk gewm leltiu tpyocey ije
eg tzmf mp uie ajzs mk
ela fnwed fe ee?
------------------------------
** 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
******************************
