Linux-Development-Sys Digest #184, Volume #6 Mon, 28 Dec 98 03:14:22 EST
Contents:
missing my C header files... ("Carl Sjoquist")
Kernel v2.2 (Martin Bahlinger)
Re: Registry - Already easily doable, in part. (Todd Knarr)
Re: Registry - Already easily doable, in part. (Robert Krawitz)
RISC 6000 MACHINE ("Israel Ameh")
Re: Registry for Linux -> Use CORBA!!! (Robert Krawitz)
Re: 2 stacks? (Johan Kullstam)
Re: Arabic & Linux (Mohammad Khan)
Re: Registry for Linux - Bad idea (Michal Mosiewicz)
Re: Arabic & Linux (H. Peter Anvin)
Re: Registry for Linux - Bad idea (Carl Kreider)
Re: Registry for Linux -> Use CORBA!!! ([EMAIL PROTECTED])
Re: Registry for Linux -> Use CORBA!!! (George MacDonald)
CDROM Joliet extension (David Yeung)
CD Drivers (Claudia)
Linux Update Server? ("ncc1701d")
----------------------------------------------------------------------------
From: "Carl Sjoquist" <[EMAIL PROTECTED]>
Subject: missing my C header files...
Date: Sun, 27 Dec 1998 17:30:03 -0500
I've installed (via RPM) gcc, glibc and libc++, but can't figure out what I
need to do to get the C header files copied to my system. According to
glint, libc is installed and when I list its files, there's a bunch of .so.
files but no headers (.h). Obviously I'm missing something (like a
screw) -- can anyone guess what I've missed?
MThanks
Carl
------------------------------
From: Martin Bahlinger <[EMAIL PROTECTED]>
Subject: Kernel v2.2
Date: Mon, 28 Dec 1998 04:15:40 +0100
Reply-To: [EMAIL PROTECTED]
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.
------------------------------
From: Todd Knarr <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Registry - Already easily doable, in part.
Date: 28 Dec 1998 01:34:50 GMT
In comp.os.linux.development.system Michal Mosiewicz <[EMAIL PROTECTED]> wrote:
> complex, however they are not so important. What is important - each
> open operation is relatively costly. So it's good for performance to
> have less opens, and to have more informations per single file. By
My experience is that, barring pessimal behavior ( literally hundreds
of opens needed, spread around over multiple directories so that inode
and dirent caching fails ) or a saturated I/O bus, opens are lost in the
noise. The overhead of actually doing something with the contents will
typically be several times that of opening the file and reading the
contents in. I've timed several programs with pessimal behavior ( they
open the file, write to it, flush it and close it on every write, to
insure that the contents are committed ( or as close to it as I can get
without insane gymnastics ) ), and the open/write/close overhead is
typically less important than the use of fprintf() vs. fputs().
Also, the more information you have per file, the more information is
subject to loss if that file is damaged. This is where the Unix system
gets it's stability: corruption of a single config file takes out the
bare minimum of functionality. Example: BIND stores the data for each
name zone in a seperate file. Trash one, you trash that zone but leave
all the others undamaged.
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.
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.
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.
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.
--
We won, didn't we? Cope!
-- Mimi, Reality Check #8
------------------------------
From: Robert Krawitz <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Registry - Already easily doable, in part.
Date: 27 Dec 1998 20:45:16 -0500
Michal Mosiewicz <[EMAIL PROTECTED]> writes:
>
> Right - finally someone notices that. Per applications rights are not so
> complex, however they are not so important. What is important - each
> open operation is relatively costly. So it's good for performance to
> have less opens, and to have more informations per single file. By
> compressing more informations in a single page we make a better use of
> cache memory.
Michal, please demonstrate that these open operations are costly in
the context in which these operations are actually done. And I don't
mean by starting Netscape, either.
I just tried benchmarking this, with the program and results below.
Admittedly, I have a fast machine -- a Celeron 300A oc'ed to 450, 128
MB of 100 MHz SDRAM, and a pair of 'cudas (2 and 4 GB fast/narrow).
I'm running stock 2.0.35.
#include <sys/types.h>
#include <sys/time.h>
#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
#include <fcntl.h>
double
tv2d(struct timeval *t)
{
return t->tv_sec + (double) t->tv_usec / 1000000.0;
}
int
main(int argc, char **argv)
{
struct timeval tv1, tv2;
int i = 0;
double t1, t2;
char buf[1025];
(void) gettimeofday(&tv1, 0);
while (fgets(buf, 1024, stdin))
{
int fd = open(buf, O_RDONLY);
if (fd >= 0)
close(fd);
i++;
}
(void) gettimeofday(&tv2, 0);
t1 = tv2d(&tv1);
t2 = tv2d(&tv2);
printf("%d files in %f seconds: %f files/sec\n", i, t2 - t1,
(double) i / (t2 - t1));
return 0;
}
[2(rlk)||{!191}<rlk-ppp-1>/usr]
$ find . -type f -print | /tmp/open
34874 files in 43.939609 seconds: 793.680253 files/sec
[2(rlk)||{!192}<rlk-ppp-1>/usr]
$ find . -type f -print | /tmp/open
34874 files in 10.236783 seconds: 3406.734331 files/sec
[2(rlk)||{!192}<rlk-ppp-1>/usr]
$ find . -type f -print > /tmp/openfiles
[2(rlk)||{!193}<rlk-ppp-1>/usr]
$ /tmp/open < /tmp/openfiles
34874 files in 6.102096 seconds: 5715.085452 files/sec
Do you notice that there's a bug there? I should strip off the
newline after each line of text, otherwise it won't find the file.
That should slow it down, right? Well, guess what -- the correct
program runs faster!
[2(rlk)||{!212}<rlk-ppp-1>/usr]
$ /tmp/open < /tmp/openfiles
34874 files in 4.019623 seconds: 8675.938119 files/sec
The real point here is that opening files is not a bottleneck in terms
of starting an application up.
--
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: "Israel Ameh" <[EMAIL PROTECTED]>
Subject: RISC 6000 MACHINE
Date: Sun, 27 Dec 1998 22:40:25 -0500
Does anyone know if Linux can be installed on an IBM RISC 6000 machine? I
have a Bull variant of the IBM RISC 6000 type 7006 and I hate to junk it
since it only runs on IBM's AIX (As far as I am aware)
Any assistance will be appreciated
Israel
------------------------------
From: Robert Krawitz <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux -> Use CORBA!!!
Date: 27 Dec 1998 20:47:45 -0500
George MacDonald <[EMAIL PROTECTED]> writes:
> 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.
I deal with C++ a lot. I hate that convention. It's hard to type and
hard to read. I wish there were keyboards with the _ character
unshifted; then there would be no excuse for this nonsense.
--
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
------------------------------
Subject: Re: 2 stacks?
From: Johan Kullstam <[EMAIL PROTECTED]>
Date: 27 Dec 1998 20:46:26 -0500
jan david mol <[EMAIL PROTECTED]> writes:
> Just an idea thrown into the world:
>
> Would it be worth while to split our traditional stack into 2 stacks,
> one to hold local variables/parameters and the other to hold return
> addresses. That way, if a program screws up its local variables it cant
> touch its calling stack (well less easy anyway), thus preserving
> back-trace info which could get screwed up along otherwise.
yes, it'd *definitely* be worthwhile. think of all the `buffer
overflow' security alerts. this is a combination of C not doing much
automatic buffer overflow/errant pointer checking and the mix of data
and stack. it'd probably make stuff like alloca a bit easier too.
> I'm not sure if this is one for the GCC compiler guys or the kernel ones..
>
> Of course if this is stuff which has to be implemented at kernel level it
> would mean a slowdown in context-switches.. but a kernel compile option
> could take care of that.. like it does with the profiling support. Maybe
> problems could be at assembler level, for the CPU's I know only support
> one stack natively.
>
> Anyway, I know MY debugging sessions would be a hell of a lot easier when
> the bugs don't mess up back-trace, and rewriting the headers/footers of a
> zillion functions to use a separate memory block for local variables isn't
> something one wants to waste time on.
the biggest problem is that the x86 so horribly starved for registers
as it is, that maintaining a data stack might be expensive. however,
for debugging and security an compile-time option to enable
double-stack mode sounds like a nice thing to have.
--
Johan Kullstam [[EMAIL PROTECTED]] Don't Fear the Penguin!
------------------------------
From: Mohammad Khan <[EMAIL PROTECTED]>
Subject: Re: Arabic & Linux
Date: Sun, 27 Dec 1998 21:49:07 -0600
Reply-To: [EMAIL PROTECTED]
Veksler Michael wrote:
> Hebrew suffers from similar problems as Arabic does (Right->Left).
> A set of tools for Hebrew has been developed. You can start from the
> Hebrew-HOWTO (can be found at sunsite).
> The only problem you may have is fonts.
> (I am let to believe that you need about 100 characters, right?)
No, Arabic has 28 ( ignoring some 10 sign which are hardly ever written AND
not considered letters ). Add four more letters and you get persian ( laguage
of Iran ) alphabet and finally adding four more gives Urdu.
>
>
> Good luck,
>
> Michael
------------------------------
From: Michal Mosiewicz <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: Mon, 28 Dec 1998 04:55:30 +0100
Craig Kelley wrote:
> [...]
> Here's some real-world figures for you:
>
> http://inconnu.isu.edu/~ink/regfun/
Congratulations! You've just noticed that sequential reading is faster
than random access. Conclusions? :-)
Mike
--
WWW: http://www.lodz.pdi.net/~mimo tel: Int. Acc. Code + 48 42 2148340
add: Michal Mosiewicz * Bugaj 66 m.54 * 95-200 Pabianice * POLAND
------------------------------
From: [EMAIL PROTECTED] (H. Peter Anvin)
Subject: Re: Arabic & Linux
Date: 28 Dec 1998 04:17:06 GMT
Reply-To: [EMAIL PROTECTED] (H. Peter Anvin)
Followup to: <[EMAIL PROTECTED]>
By author: [EMAIL PROTECTED]
In newsgroup: comp.os.linux.development.system
>
> Veksler Michael wrote:
>
> > Hebrew suffers from similar problems as Arabic does (Right->Left).
> > A set of tools for Hebrew has been developed. You can start from the
> > Hebrew-HOWTO (can be found at sunsite).
> > The only problem you may have is fonts.
> > (I am let to believe that you need about 100 characters, right?)
>
> No, Arabic has 28 ( ignoring some 10 sign which are hardly ever written AND
> not considered letters ). Add four more letters and you get persian ( laguage
> of Iran ) alphabet and finally adding four more gives Urdu.
>
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.
Arabic script should be doable with a relatively simple algorithm,
although it may be preferrable to do it in user space due to the size
of the necessary tables (like kcon, the Japanese user-space console).
They can talk over a pty and use the framebuffer interface to the
kernel, or libGGI. You probably also have to make extensions to X11
assuming you want to run it.
The Indic scripts will be a nightmare, and *definitely* belong in user
space.
-hpa
--
PGP: 2047/2A960705 BA 03 D3 2C 14 A8 A8 BD 1E DF FE 69 EE 35 BD 74
See http://www.zytor.com/~hpa/ for web page and full PGP public key
I am Bah�'� -- ask me about it or see http://www.bahai.org/
"To love another person is to see the face of God." -- Les Mis�rables
------------------------------
From: Carl Kreider <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: Sun, 27 Dec 1998 21:28:55 -0500
Michal Mosiewicz wrote:
> Stefaan A Eeckels wrote:
> > [...]
> > If you analyse start-up delays for a large program (eg netscape), you'll
> > see that reading the configuration files takes negligible time compared
>
> Are you sure? I mean - is it paging the binaries that causes the delay?
> As for my machine Netscape pages in about 4-5MBs at start. Not much,
> right? On the same machine I'm able to page in the whole netscape binary
> (which normally never happens) and every library in just 5 seconds.
>
> The whole netscape starts about 30 seconds. Where is that negligible
> time your talking about? Of course Netscape's case is pretty
> exceptional. To make parsing easier Netscape often reads configuration
> files byte-by-byte. But that's a different story.
>
> Anyhow - the time spent on opening (50% missed), reading, seeking,
> closing is not negligible.
Really, it is. Wire it up and measure it. You will see.
--
Carl Kreider
aka
[EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
============================================================
"The woods are lovely, dark and deep. But I have promises to keep,
and lines to code before I sleep. And lines to code before I sleep."
Anonymous
============================================================
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux -> Use CORBA!!!
Date: 27 Dec 1998 17:58:16 -0800
>George MacDonald <[EMAIL PROTECTED]> writes:
>
>> 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.
>
>I deal with C++ a lot. I hate that convention. It's hard to type and
>hard to read. I wish there were keyboards with the _ character
>unshifted; then there would be no excuse for this nonsense.
The Java convention is a good one.
a class name always starts with an upper case.
an object (instance of a class) always starts with a lower case.
and no '_' in names.
this is simple, easy, and clear.
Bill.
------------------------------
From: George MacDonald <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux -> Use CORBA!!!
Date: Mon, 28 Dec 1998 04:46:04 GMT
Robert Krawitz wrote:
>
> George MacDonald <[EMAIL PROTECTED]> writes:
>
> > 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.
>
> I deal with C++ a lot. I hate that convention. It's hard to type and
> hard to read. I wish there were keyboards with the _ character
> unshifted; then there would be no excuse for this nonsense.
>
Hmm, you know I used to use the "_" all the time and liked it
well enough. I have also seen a convention where the first
two characters were used to designate the context that the
symbol/object/.. is from. i.e. OC_init() ... I notice
CORBA prefixes everything with CORBA... Which makes for a
lot of extra typing, but does make things more clear.
Anyhow lately I have taken to the mixed case mechanism due to
it's use in OO situations. This was the reason for using
the mixed case convention. I hear your concern though and
am a little perplexed as to a clean solution. Perhaps
it should be, dare I say, configurable.
I was thinking that eventually a STORE_PATH environmental variable
could be used to specify the persistent store locations. In particular
we need to allow for a user store, a system store, a group store
and perhaps others. The long term solution should allow for an
arbitrary number of levels, with perhaps the last being in the
users space. The app should be able to load/store settings from
any store that it has appropriate permissions for. i.e. if there
is a group setting that can be modified by anyone in a group, then
they should be able to store settings for the group. Note this
is not a typical situation, and some form of access control
for a group also makes sense. i.e. there may be a list
of group admins who can change settings for that group. This
would be added at a later stage.
So we seem to be tied 2-2 for the naming convention. If it
were configurable would you have a problem with .userStore
as the default?
--
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: David Yeung <[EMAIL PROTECTED]>
Subject: CDROM Joliet extension
Date: Mon, 28 Dec 1998 10:59:18 +0800
Does the RedHat 5.2 kernel support CDROM Joliet extension, and
how do I know if the CDROM contains Joliet extension when I
mount it?
Thanks
david
------------------------------
From: Claudia <[EMAIL PROTECTED]>
Subject: CD Drivers
Date: Mon, 28 Dec 1998 02:54:31 -0400
Hi,
I have a Creative CD820E.1v788200 8X CD-ROM
Where can i get the drivers to use it on linux
Thanks
Max
------------------------------
From: "ncc1701d" <[EMAIL PROTECTED]>
Crossposted-To: linux.dev.kernel
Subject: Linux Update Server?
Date: Mon, 28 Dec 1998 01:17:23 -0600
NNTP-Posting-Date: Sun, 27 Dec 1998 23:18:03 PDT
Hi people,
I was just wondering if there is any kind of program out there for Linux,
RedHat in particular, that has the same functionality as the Windows Update
Server does for Win98. I use the windows update function quite a bit and
realized that it would be a GREAT thing to have under Linux. Glint itself
could be the front end for the program if only there was some kind of
central repository that would allow either an NFS type mount or if Glint
could be modified to allow FTPing available updates. Glint already
recognizes which patches you have installed in your system and respectfully
hides them. This would be something that would make it easier for NEWBIES
and experts alike to be able to update there servers automagically whenever
a new patch/program comes out. Being that RPM is an open source type
installation method it already has the making to be a great feature of ALL
Linux distributions.
Comments/Flames anyone?
Jason
PS Or am I missing something and does glint already do this?
------------------------------
** 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
******************************
