Linux-Development-Sys Digest #192, Volume #6 Wed, 30 Dec 98 11:14:38 EST
Contents:
Re: Does brk hack still work (Martin Maney)
glibc 206 ("Fred Forester")
Re: Arabic & Linux (mkk)
Re: Registry for Linux -> Use CORBA!!! (George MacDonald)
2.2 kernels and K6-2 with CXT core ?! ([EMAIL PROTECTED])
Re: Registry for Linux - Why? (Thornton Prime)
Re: Human based computers (Was - Fruit-based computers) (gus)
Probel With Netscape (Subramanian Varadarajan)
Re: Does brk hack still work (Anton Ertl)
Re: building kernel under RH 5.2 (Martin Schiller)
----------------------------------------------------------------------------
From: Martin Maney <[EMAIL PROTECTED]>
Subject: Re: Does brk hack still work
Date: 30 Dec 1998 03:04:52 GMT
George MacDonald <[EMAIL PROTECTED]> wrote:
> So if the sum of virtual memory spaces for all the processes can
> be larger than the swap space what happens when the system can't
> swap?
Unpleasant things, alas.
> Is that something I need to worry about in my application? i.e.
> do I need to add some defensive code to handle that condition,
> if so, what code?
No, there is really nothing you can do at the application level.
This is memory overcommit, and it does in fact work well in practice in some
settings. I know it from before Linux because OS/2 did this as well; when I
first learned of it I thought it was a Really Bad Idea and even had myself
half convinced that this resulted in behavior contrary to that permitted by
Standard C. I have since decided that this is, from a standard-conformance
point of view, more like a hardware (memory) fault. Still a Bad Thing when
it happens to you, but simply not within the scope of the C standard (or of
any reasonable language standard).
The best news is that (unless things changed) Linux 2.2 will have be
configurable for this. That will allow apps that ask for memory that the
system cannot guarantee will be available to fail at allocation time.
Whether this is better than a risk of a less well-defined failure at some
indeterminate future time, that may affect other tasks, is a question with
reasonable answers that range from "yes" to "no" with plenty of stops along
the way. It depends a lot on what you're doing; how great the risk is; how
far-reaching the consequences of (perhaps) losing a service that other
systems rely upon. Obviously the chance to disable overcommit will be a
good thing for servers that must stay up... provided they don't turn out to
run a lot of programs that request too many extra MBs that they never
actually touch, which may reveal that the available VM was never actually
adequate to support the (requested, not all used) aggregate memory
allocation of its usual load.
Short form: overcommit has pros and cons; in 2.2 you should be able to
select the setting that you think is best for your situation.
------------------------------
From: "Fred Forester" <[EMAIL PROTECTED]>
Subject: glibc 206
Date: Mon, 28 Dec 1998 18:51:36 -0500
Hi all,
compiled and linked with glibc.
get SIGSEGV in set_progname in assert.c when program in started.
thanx in advance
------------------------------
From: mkk <[EMAIL PROTECTED]>
Subject: Re: Arabic & Linux
Date: Tue, 29 Dec 1998 23:49:21 -0600
Reply-To: [EMAIL PROTECTED]
H. Peter Anvin wrote:
>
> Arabic (the script, not necessarily the language) *do* however share
> the "problem" with certain Indic scripts that the character:glyph
> correspondence isn't 1:1. Arabic is reasonably well-behaved, however,
> in that the progression is always strict right to left and the shape
> of any one letter only depends on the characters immediately before
> and after.
Except for the "normally unwritten" short vowels which are written
OVER or UNDER a letter.
>
> The Indic scripts will be a nightmare, and *definitely* belong in user
> space.
What are the Indic scripts ? Any example.
Khalid
------------------------------
From: George MacDonald <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux -> Use CORBA!!!
Date: Wed, 30 Dec 1998 06:00:56 GMT
TenchiKen wrote:
>
> 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).
The idea of a FS metaphor is interesting. I quite like the
/proc area which provides a portal to dynamic kernel info.
In essence this is just a containment hierarchy with a
few standard operations read/write(get/set). On some
systems other functions can be performed via ioctl
calls.
I am thinking the configuration information is not as
flat as a simple tree. It's more like a projection
of many trees that looks different depending on your
frame of reference. There appears to be a system
tree, application tree's, user tree's ... At any
given instance these can be pieced together to
form a view that looks like one big tree. I am
wondering what is the value of doing this, vs.
keeping the sub-tree's as different entities that
can be manipulated seperately. i.e. lets say
I want to take *my* user config from one machine
to another. With a seperate userStore, this is
easy. With one big dynamic tree, it's not so
easy to pickup things like my named config sets.
I was thinking that longer term, the various subtrees
could be viewed as a super-tree by merging them
together via server processes. The server could
be enabled if users/admins desire
that kind of service. Making this efficient can be
achieved via many techiniques(shared mem ...).
In other words I think a system can be designed
that does not require the servers or CORBA, but
can use them if desired. i.e. the costs increase
linearly with the functionality. This would be
my prefered design/implementation strategy.
Your view of a config tree as a file system
could be supported via a server process that
creates a loopback file system. Perhaps
started per user when a user logs in. Such
a solution is complimentary to what I was thinking
about, i.e. it could be defined as a module
that is activated in a "config" server.
The architecture I am thinking about is as follows:
=============================================
Applications
Library CORBA File System SNMP
Interface Interface Interface Interface
| | | |
| | | |
Configuration Services
| | |
| | |
Flat files Relational DB OO-DBMS
==================================================
Applications use an interface to communicate with the
configuration services. These services in turn use
one or more storage mechanisms. In the simplist case
this is a library linked into an application that
reads/writes from text based flat files. These flat
files could be manually edited if desired. One
thing not shown would be plugable translators that
convert custom/proprietary application config
storage formats into a generic public format.
Also not shown is direct access to flat files, i.e.
what we currently have. I think starting from
the left and working to the right would be the
proper implementation strategy. The needs of small
systems are met on the left and the needs of larger
systems/servers/networks are met on the right.
Thoughts?
--
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]
Subject: 2.2 kernels and K6-2 with CXT core ?!
Date: Wed, 30 Dec 1998 00:46:59 GMT
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 ??? <-
Hope I get an answer this time ....
TIA,
olli
PS please mail cc to [EMAIL PROTECTED]
------------------------------
From: Thornton Prime <[EMAIL PROTECTED]>
Subject: Re: Registry for Linux - Why?
Date: Tue, 29 Dec 1998 16:32:21 -0800
[EMAIL PROTECTED] wrote:
>
> There have been people who have asked for a "Windows Registry" - like
> configuration database for Linux.
> Why do you want it, and what do you want exactly?
> What are your arguments for a "Registry"-like database?
I agree with you that a registry is a bad idea, but here are some
arguments for a global registry:
1. Centralized administration:
Having all the configuration settings in one place makes backup and
management easier. While most applications put system config files in
the /etc directory, some do not. Tracking down these files can sometimes
be a chore, though I think that the amount of effort involved here is
much less than the pain caused by using an inflexible and corruptable
centralized configuration database.
2. Standardized Configuration Management
Unix does suffer from a bad case of everyone doing their own thing
with their own application. Someone who is comfortable editing the
configuration file of Apache won't instantly recognize the configuration
format of Sendmail. It does increase the learning curve associated with
Unix administration. On the flip side, leaving configuration files
application-specific leaves the application developer free to chose the
type of configuration file most appropriate to his or her application's
needs.
3. Multiple Levels of Default Inheritence
This is something NT does not offer, but would be a logical step in a
registry database. In addition to global preferences, you could store
department, group, workgroup, individual preferences which override the
defaults. Using a heirarchical configuration store certainly would make
Linux more enterprise-friendly, though the vast majority of applications
would not need this degree of flexibility, and the flexibility could
just as easily be achieved on an application-specific level using
another technology, like LDAP.
I think the best argument against a global registry in Linux would be
that "that is not the way we do things." The success of Linux is built
upon the ability to compile and run a number of open source applications
without modifications. While a registry wouldn't necessarily mean that
those applications wouldn't be compatible (they just would ignore the
registry), making them compatible would introduce a lot of
Linux-specific code .. decreasing the maintainability of those projects.
If individual applications need or want registry-like configuration
management, there are already alternatives which work well on Linux. As
others have mentioned, a CORBA-based configuration is an interesting
idea. I personally prefer LDAP ... that is what LDAP was designed for
and it has all the features necessary (though I am still concerned about
performance).
thornton
------------------------------
From: gus <[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 14:39:38 +0000
Reply-To: [EMAIL PROTECTED]
You are misunderstanding the potential of the human brain, and the
co-processor.
Firstly, the co-processor does not need to run at the same bus speed as
the brain. It simply needs parameters to be set, an execution to be
actibated, and the result ourld be returned in another register. It is
not necessary for the co-procesor to run at the same speed as the brain.
Further, you underestimate the power of multi-threaded / multi-processor
systems. Remeber, the human brain is potentially the most complex, yet
effective multiprocessor.
As an example, it is a fact that you blink about 16 times a minute. Each
blink is approximately 0.25 of a second. This gives a total of 4 seconds
a minute where your eyes are closed, and thus the optic nerve is unused.
If this bandwidth could be harnessed, and the optical processing unit of
the brain then there would be more than enough available bandwith,
storage, and processing power to cope with the co-processor.
Think of the military abilities it would give to a soldier. An internal
HUD, strategic planning, manipulation, and controlling of weapons.
Identification of "friendlies". Perhaps even enhanced visualisation of
enemies, or thermal imaging, perhaps even x-ray vision. All through the
use of a coupled co-processor.
What about linguists. Learning made easy! Think your mother tongue,
speak a foreign tongue ... ;-)
The possibilities are endless.
Never mind the potential of having a PII embedded in your brain when on
a trip to the arctic ... when it gets cold, simply imagine erotic
images, the co-processor will go into overdrive, and the heat generated
will warm you ... ;-)
gus
P.S. it surprises me that this thread is suddenly rejuvenated.
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
------------------------------
Date: Tue, 29 Dec 1998 05:00:42 +0000
From: Subramanian Varadarajan <[EMAIL PROTECTED]>
Subject: Probel With Netscape
Hi,
I am not sure if this is the right group to address this question but I
will appreciate
any help (or if you point me to the correct group). I downloaded and
installed netscape 4.5
on my Linux machine - everything runs fine except when I need to view
pdf documents
to be viewed as a MIME type - that is spawn a acroread and display the
pdf document
inside it. I added appropriate entries in the user preferences section.
When I click
on the url with a mime type of .pdf, netscape launches the acroread
program but it
comes up empty! This problem is not there in my Win95 machine. What is
it that I am
doing wrong? I am not able to figure out? I would appreciate if someone
could send me
the answer by email to [EMAIL PROTECTED]
Thanks,
Rajan
------------------------------
From: [EMAIL PROTECTED] (Anton Ertl)
Subject: Re: Does brk hack still work
Date: 30 Dec 1998 15:33:42 GMT
In article <[EMAIL PROTECTED]>,
George MacDonald <[EMAIL PROTECTED]> writes:
> So if the sum of virtual memory spaces for all the processes can
> be larger than the swap space what happens when the system can't
> swap?
The last time I tried this, the system hung. This was with either a
1.0 or a 1.2 kernel (one of these did not allow memory overcommit, the
other did). I hope current kernels are a little more forgiving (by,
say leaving some room for root processes).
I heard that AIX kills processes in this situation (large ones first).
> Is that something I need to worry about in my application? i.e.
> do I need to add some defensive code to handle that condition,
> if so, what code?
I don't think that's possible. The best defense is probably for the
sysadmin to make the swap space large enough such that the users or
sysadmins kill the offending process(es) before swap space runs out.
- anton
--
M. Anton Ertl Some things have to be seen to be believed
[EMAIL PROTECTED] Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html
------------------------------
Crossposted-To: comp.os.linux.setup
Subject: Re: building kernel under RH 5.2
From: [EMAIL PROTECTED] (Martin Schiller)
Date: Wed, 30 Dec 1998 06:59:53 -0800
I thought that the following posting by DFox had solved my problem with
the conflicting information in the HOWTO's and the RedHat (5.1)
Installation guide but unfortunately not so......
> > First you install the .src.rpm using "rpm -i". Next run "rpm -bp
> > /usr/rsc/redhat/SPECS/kernel-2.0.36.spec" to unpack the archives and
> > create the source directory. Now run "make config" or "make xconfig"
> > in the source directory and you should get a new .config file. Copy
> > this to /usr/src/redhat/SOURCES/kernel-2.0.36-i386.config. Then run
> > "rpm -ba /usr/src/redhat/SPECS/kernel-2.0.36.spec" to create new
> > binary RPMs. You may want to increase the release number in the spec
> > file before you do this. Now install the new .i386.rpm files, use
> > mkinitrd to make a new init ramdisk if necessary, update
> > /etc/lilo.conf and re-run lilo, and you're done.
> > --
> > David Fox http://hci.ucsd.edu/dsf xoF divaD
> > UCSD HCI Lab baL ICH DSCU
I was able to rpm -i the SRPMS kernel source (from disk 2) and then rpm
-bp the spec file. That's where I stalled. "Make config" run in the
/usr/src/Redhat/SOURCES directory or from the /usr/src/~linux dir
results in
make: **No rule to make target "config". Stop**"
The /usr/src/Redhat/SOURCES directory contains a kernel-config.axp and a
kernel-config.i386 file as well as a installkernel file. The
kernel-config files each seem to be text files with configuration
options in the form of CONFIG_OPTION=y
CPNF_OPTION=m
Attempting to comply with the RedHat installation instruction to install
the kernel source and the kernel headers packages (from the RPMS), rpm
informs me that the packages are installed already. And there is no
kernel-headers file in the SRPMS dir on disk 2.
regards, Martin
------------------------------
** 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
******************************
