Linux-Development-Sys Digest #189, Volume #6 Tue, 29 Dec 98 23:14:11 EST
Contents:
Re: Registry for Linux - Bad idea (Robert Krawitz)
Re: Registry for Linux -> Use CORBA!!! (TenchiKen)
Re: Registry - Already easily doable, in part. (TenchiKen)
Re: Human based computers (Was - Fruit-based computers) (Marc)
Re: A whacky DATE bug in Linux - Problem gets crazier! ([EMAIL PROTECTED])
Re: 2.2 kernels and K6-2 with CXT core ?! ([EMAIL PROTECTED])
Re: Adding additional VT's under Linux (Andries Brouwer)
Re: Registry - Already easily doable, in part. (Todd Knarr)
Linux rs232 communication ports (John Whitt)
Re: Linux Registry Stone Bitch to Administer (Taso Hatzi)
Monitor Setup for Laptop ("Peter")
Re: Kernel v2.2 ([EMAIL PROTECTED])
Lilo (BootLoader) Installation ("Peter")
Re: Registry for Linux - Bad idea (TenchiKen)
DHCPcd leasing addresses but rejecting them... PLEASE read this, I really need help
(8 days I've had this problem) ("john Doe")
----------------------------------------------------------------------------
From: Robert Krawitz <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: 29 Dec 1998 19:07:55 -0500
George MacDonald <[EMAIL PROTECTED]> writes:
> In a large scale network with very dynamic configuration needs the
> flexibility and power that a database offers is worth the expense.
> In a small system with infrequent changes it is a waste of
> resources, it adds uneeded complexity and simply cannot be
> justified. What we need is a solution that can accomodate both. Have
> a look at the definition for CORBA's persistent storage service
> POS. In that model they decouple the storage mechanism from the
> objects that use it. Thus an object can either specify storage type
> or not, and a storage server can can be configured for flat files or
> OODBMS as is desired for that particular machine/server/object. By
> providing the proper level of abstraction you can do both, and do
> both well.
There's nothing preventing anyone doing that right now. That's what
YP, NIS, Hesiod et al. are all about. What's more, they all work
transparently through the get<foo>by<bar> calls that have been around
for quite a few years, so programs don't need to be recompiled. With
shared libraries everywhere, they don't even need to be relinked.
Apps that need the fancier stuff have access to it; those that don't
can ignore it. What's important (to me, at least), though, is the
system be able to boot to a sane state with a bare minimum amount of
"stuff".
--
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: [EMAIL PROTECTED] (TenchiKen)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux -> Use CORBA!!!
Date: 29 Dec 1998 16:28:38 -0700
In article <[EMAIL PROTECTED]>,
George MacDonald <[EMAIL PROTECTED]> wrote:
>> >How about it then could everyone start putting user config
>> >files in
>>
>> > $HOME/.userStore/applications/${applicationName}
>>
>> >or something similar?
>>
>> I like that idea. I don't like .userStore as the name though.
>> I'd prefer the word seperation to be e.g. .user_store
>> and the name "user store" doesn't seem quite right for the part
>> of the home directory that is storing configuration information.
>> I suggest .conf_store or .config.
>
>Thanks for the comments.
>
>The reason for "userStore" vs. "user_store" is to alert developers
>to the OO methodolgy. This seems to be the norm in OO based
>toolkits such as X/Xt/Motif and in *some* of the newer class
>hierarchies.
>
>The reason for the generic name of Store, again it's more of
>a OO term. Shorter form of -> user persistent storage. While
>the vast majority is for config information, the space
>should also be used for other context files, history files
>work files ... For example gimp is currently using my home
>directory to store a temp work file! The file is about
>40 characters in length and makes a real mess of my ls -artl !!!
>A better place would be:
>
> $GOME/.userStore/applications/gimp/current/workFiles
>
>or something similar.
>
>Having said that a ".config" covers the 90% solution, it is
>tempting due to it's clarity? Hmm. any one else have an opinion
>on this?
>
>Would you think it confusing to put history files under a .config?
I think the biggest concern I have is, that I think we need to
move to a system that configuration looks similar, no matter
what the application. (not neccesairly simple). If you are
proposing doing this thru CORBA, I think you blow away any
kind of configuration restoration.
If you were to do this with a filesystem (with interfaces thru
CORBA and the standard FS), this might work, even tho I think
CORBA is overkill (and slow).
------------------------------
From: [EMAIL PROTECTED] (TenchiKen)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Registry - Already easily doable, in part.
Date: 29 Dec 1998 16:07:08 -0700
>The critical failings of the Windows registry are:
>1. All data is stored in a single place. Damage to that one place has a
> high chance of affecting large chunks of the system.
This is a problem. There would need to be a good mechanism for backing
up this data. Rebuilding the tree from scratch.
>2. The data is stored in a form not amenable to direct manipulation. It
> can only be readily accessed through system APIs, which means that the
> system has to be running to access it, which means that that one place
> has to be intact enough to get the system running before you can repair
> the damage.
How about a real filesystem. (conffs?) This fileystem would provide
transparent access to a database of configuration options. In addition,
it could do really fancy things like keep multiple profiles, keep user
profiles, and do things like ACL's. It could also be manipulated thru
an API to make things easier on the programer.
Plus, doing this thru a filesystem could help force good layout,
and making backup easier. Even more so, a simple program could
be written to modify massive chunks of the registry, should it be
needed. (ie, overlay a hash table of new values into a tree).
>3. Constant config information is stored in the same place as volatile
> config information and volatile application state. Since the most
> likely time for corruption to occur is during a write, and this one
> place is constantly being written to, the chances of corruption are
> high.
Application state is probibly something that the end user need not
deal with in the first place. Kernel configuration should definitly
not be done using this method ;-)
>Any design which improves performance at the expense of duplicating the
>failings of the registry is going to suffer from the same problems as
>the registry.
------------------------------
From: Marc <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.hardware,comp.os.linux.networking,bionet.plants
Subject: Re: Human based computers (Was - Fruit-based computers)
Date: Wed, 30 Dec 1998 00:48:29 GMT
I think I saw somthing like this,,wasn't Homer Simpson the first recipient (PII)
*grin* :)
Patrick Jelinck wrote:
> these math coprocessors will never work...
> because the human cpu and the ram can not be overclocked, not even at
> 100mhz
>
> silicium based fpu's are inaccurate for low speed bio-cpu's
>
> and an fpu bus buffer would not have the necessary capacity ( ~ 1 GB )
>
> 9 Oct 1998 23:04:58 GMT, [EMAIL PROTECTED] (Matthias Warkus)
> wrote:
>
> >William Justice Black schrieb:
> >>
> >> gus <[EMAIL PROTECTED]> wrote:
> >> : Larry Smithmier wrote:
> >> : > Tristan Wibberley wrote:
> >> : > > Frampton Steve R wrote:
> >>
> >> [...]
> >>
> >> : Firstly, the concept:
> >> : "Bio-interactive computational entity for additional analytical
> >> : abilities for humans" In laymans terms, a device inserted in to a human
> >> : which will allow previously impossible calculations to be performed
> >> : "internally". The concept specifies that this bio-compatible computer
> >> : will provide an additional support role for for the computational and
> >> : analytical processes of the human brain. It will not supercede the brain
> >> : as a processing unit. The brain will still be most important, otherwise
> >> : we have an andriod, not a human.
> >>
> >> [...]
> >>
> >> Honestly, I'd be happy if I just had a decent mathco ;-)
> >
> >There's an SF book where humans have got mathematical coprocessors
> >implanted in their brain (as well as pagers etc.).
> >IIRC, it's _A_New_Proteus_, I don't recall the author.
> >
> >mawa
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To:
comp.os.linux.development.apps,comp.os.linux.setup,alt.linux,alt.os.linux,comp.os.linux,comp.os.linux.questions,aus.computers.linux
Subject: Re: A whacky DATE bug in Linux - Problem gets crazier!
Date: Tue, 29 Dec 1998 22:33:20 GMT
Patrick Jelinck writes:
> if you boot in win95 and linux before this date, and then again in both
> of them after this date, your bios clocks jump from summer time to winter
> time (europe) may be executed TWICE !!!, once by win and once by linux
> and your pc's clock will be 1 hour late !
Linux will not automatically change your hardware clock. You tell it that
your clock is set to either local time or UT and it makes its own timezone
and summer time adjustments.
> solution: activate automatic change only in WIN or in LINUX
Or use only operating systems than can deal properly with a hardware clock
set to UT.
--
John Hasler This posting is in the public domain.
[EMAIL PROTECTED] Do with it what you will.
Dancing Horse Hill Make money from it if you can; I don't mind.
Elmwood, Wisconsin Do not send email advertisements to this address.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: 2.2 kernels and K6-2 with CXT core ?!
Date: Wed, 30 Dec 1998 01:13:38 GMT
On Wed, 30 Dec 1998 00:46:59 GMT, I shaped the electrons to say:
>Hi everyone !!
>
>So here I'm back asking questions about AMDs K6/2 with CXT core and
>the proper handling of its CACHE STRATEGY and WRITE COMBINING for LFBs
>in the Linux kernels ....
>
>Since I know many people are running these processors on older boards
>(like ASUS' T2P4), it would be nice to have the kernel look whether
>the BIOS enabled WRITE BACK caching and the LFBs (which doesn't happen
>with the older boards because of different register mappings ...)
>
>For those running WinBlows there's a tool available top initialize the
>processor ....
>
>
>... but since nobody really feels comfortable running this M$ stuff:
>
>-> IS THERE ANYTHING LIKE THIS FOR LINUX ??? <-
>
So, here's an update:
I just found patches for 2.0.36 and 2.1.131 that are said to enable
"write allocation" (???) at http://www.klografx.de/misc/ctx/
So, since I'm not a PRO in assembler - could anyone doublecheck this
and have a look at WHAT ACTUALLY IS ENABLED ?!
This should be "WRITE COMBINING for LFBs" and "WRITE BACK caching
strategy" - I hope ...
And what about including this into the next 2.2-pre-X-patch ?!!!!
TIA,
olli
------------------------------
From: [EMAIL PROTECTED] (Andries Brouwer)
Subject: Re: Adding additional VT's under Linux
Date: Tue, 29 Dec 1998 18:35:39 GMT
Morten Knudsen <[EMAIL PROTECTED]> writes:
:: Ryan Singer wrote:
:: >
:: > Does anyone know which kernel source files need
:: > to be altered in order to allow VT's over 12 to
:: > be used?
Nothing needs to be changed, and you have up to 63 consoles.
: You need to create the /dev/tty? files (unless they're already there,
: my system has up to tty9).
: Then you go into /etc/inittab and find lines like :
: c1:1235:respawn:/sbin/agetty 38400 tty1 linux
: These are your standard vt's.
: If you want more vt's add
: c7:1235:respawn:/sbin/agetty 38400 tty7 linux
Yes. It is even easier to leave /etc/inittab as it is
(or remove all except one or two getty lines)
and run something like spawn_login (from the kbd package).
A single keypress (Alt-UpArrow) then gives you a new console,
so that you can have 30 when you need them. And `deallocvt'
throws all unused consoles out again, so that cycling around
(with Alt-RightArrow, say) does not show you a lot of unused
screens.
------------------------------
From: Todd Knarr <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Registry - Already easily doable, in part.
Date: 30 Dec 1998 01:15:01 GMT
In comp.os.linux.development.system TenchiKen <[EMAIL PROTECTED]> wrote:
>>The critical failings of the Windows registry are:
>>1. All data is stored in a single place. Damage to that one place has a
>> high chance of affecting large chunks of the system.
> This is a problem. There would need to be a good mechanism for backing
> up this data. Rebuilding the tree from scratch.
You also need some mechanism for allowing the system to start and run
without that one place operational. It's not so much the backup that's
a problem ( although it's often a problem of it's own ) as the fact that
a single problem can render everything non-operational in one fell swoop.
>>2. The data is stored in a form not amenable to direct manipulation. It
>> can only be readily accessed through system APIs, which means that the
>> system has to be running to access it, which means that that one place
>> has to be intact enough to get the system running before you can repair
>> the damage.
> How about a real filesystem. (conffs?) This fileystem would provide
> transparent access to a database of configuration options. In addition,
> it could do really fancy things like keep multiple profiles, keep user
> profiles, and do things like ACL's. It could also be manipulated thru
> an API to make things easier on the programer.
The problem with a filesystem setup is that damage again results in
the system being otherwise fine but unable to get at the configuration
information it needs to start. The one advantage of storing configuration
in files, typically on the root filesystem itself for the stuff that's
really needed to start up, is that it's all usually accessible if the
root filesystem is accessible at all, and if the root filesystem cannot
be accessed you are screwed anyway and won't get to the point where you
need to worry about getting at the configuration data.
As for profiles, that's what user-specific configuration files stored
in or under the user's home directory are for. Storing per-user information
in the same place as system-wide information isn't the Right Thing.
> Plus, doing this thru a filesystem could help force good layout,
> and making backup easier. Even more so, a simple program could
> be written to modify massive chunks of the registry, should it be
> needed. (ie, overlay a hash table of new values into a tree).
Good layout and backups can be handled ( and are handled ) by sane file
locations and use of directories. As for modifications, IMHO there should
be a definite split: configuration files should always be read-only and
treated as such, files that are written to ( eg. BIND's zone backup files,
Samba WINS name data ) should be completely seperate, not neccesary to
start and ideally should contain magic numbers and other tricks to detect
corruption. The program itself should never be writing to the files it
needs to start up. This won't eliminate all problems, but at least it takes
program insanity out of the equation and leaves only the sysadmin to screw
things up.
--
We won, didn't we? Cope!
-- Mimi, Reality Check #8
------------------------------
Date: Tue, 29 Dec 1998 21:27:58 -0500
From: John Whitt <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Linux rs232 communication ports
Does anyone know where I can find some example "C" code for opening a
serial port under Linux and and reading and writing to the port?
------------------------------
From: Taso Hatzi <[EMAIL PROTECTED]>
Subject: Re: Linux Registry Stone Bitch to Administer
Date: Wed, 30 Dec 1998 13:41:10 +1100
Christian Gross wrote:
>
> Let me add one point.
>
> THE REGISTRY IS A ROYAL PAIN IN THE ASS!!!! Whoever developed the registry
> should be shot! The problem that I have with the registry is that as a beta
I agree entirely. Installing software on WinXX/MsVMS systems scatters
shit all
over the place making it impossible to clean up. I want software to
install
itself in ONE place so that I can get rid of it when I'm done. If it
wants to
install libraries, it should ask me for permission to put them anywhere
other than in it's own install directory.
As for registering objects, what's wrong with CORBA?
------------------------------
From: "Peter" <[EMAIL PROTECTED]>
Crossposted-To:
alt.os.linux,alt.os.linux.caldera,alt.os.linux.slackware,comp.linux,comp.linux.os,comp.os.linux,comp.os.linux.development,comp.os.linux.development.apps,comp.os.linux.hardware,comp.os.linux.help,comp.os.linux.ne
Subject: Monitor Setup for Laptop
Date: Wed, 30 Dec 1998 10:57:21 +0800
Hello,
I am using a Dell Latitude CPi laptop. What should I choose in Linux
monitor setup?
Please reply directly to me.
Thanks.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Kernel v2.2
Date: 29 Dec 1998 16:16:31 GMT
Martin Bahlinger <[EMAIL PROTECTED]> wrote:
> Does anybody know, how long we've to wait for the new Linux kernel ??
> BTW: Is it called v2.2 or v3.0 ???
> Martin B.
Why don't you try 2.1.132 or the latest 2.2.0pre1 ? I use 2.1.132 without a
problem with a debian instalation
bye
http://student.dee.uc.pt/~slug
------------------------------
From: "Peter" <[EMAIL PROTECTED]>
Crossposted-To:
alt.os.linux,alt.os.linux.caldera,alt.os.linux.slackware,comp.linux,comp.linux.os,comp.os.linux,comp.os.linux.development,comp.os.linux.development.apps,comp.os.linux.hardware,comp.os.linux.help,comp.os.linux.ne
Subject: Lilo (BootLoader) Installation
Date: Wed, 30 Dec 1998 11:17:55 +0800
Hello,
I am at the Lilo Installation now. I have Wn98 and NT4 dual boot on my hard
disk. Where should I install the Linux bootloader?
1. /dev/hda Master Boot Record (containts 3 partitions: NT, Win98 and Linux,
currently dual booting NT and Win98)
2. /dev/hda3 First sector of boot partition (Linux partition)
Please reply directly to me.
Thanks.
------------------------------
From: [EMAIL PROTECTED] (TenchiKen)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: 29 Dec 1998 15:18:26 -0700
In article <[EMAIL PROTECTED]>,
Robert Krawitz <[EMAIL PROTECTED]> wrote:
>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.
Maybe this is not neccesary. Maybe we should provide some hooks
for system service applications to interface with chunks of /proc.
This would allow us to use /proc to set up everthing, and the method
of saving this information is really up to the user. (ie, it could
be a script file that does the echo, or a db based registry, or a
Linux conf configurator.
Best of all, these would all work together.
of course, the hard part is the code ^.^ My skills are not
up to this task... (yet)...
------------------------------
From: "john Doe" <[EMAIL PROTECTED]>
Crossposted-To:
alt.linux,alt.os.linux,aus.computers.linux,comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.hardware,comp.os.linux.misc,comp.os.linux.networking,comp.os.linux.setup,comp.os.linux.x,es.comp.os.
Subject: DHCPcd leasing addresses but rejecting them... PLEASE read this, I really
need help (8 days I've had this problem)
Date: Sat, 26 Dec 1998 10:13:40 -0800
My linux box is running Redhat 5.2 (brand new install) with DHCPCD
installed. I followed the dhcp howto to the letter, but I still get this
problem...
My box leases an ip like its supposed to, but when it gets the IP and tries
to use it, it rejects it saying its already in use and says "falling back to
INIT".
Is this a subnet mask problem? (I do not have a subnet)
Does anyone know how to fix this?
Please don't reply in the newsgroup here, RATHER:
Please send e-mail to [EMAIL PROTECTED]
Thank you!!! I really need help
------------------------------
** 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
******************************
