Linux-Development-Sys Digest #187, Volume #6 Tue, 29 Dec 98 04:14:07 EST
Contents:
Re: Santa's List ("D. Stimtis")
Re: things I'd pay to have developed for Linux... (Christopher B. Browne)
Re: Registry for Linux - Bad idea (Christopher B. Browne)
Re: Registry for Linux - Bad idea (Christopher Browne)
Re: Kernel v2.2 (Christopher Browne)
Re: Registry - Already easily doable, in part. (Christopher Browne)
Re: Registry for Linux - Bad idea (Christopher Browne)
Re: 2 stacks? (Christopher Browne)
Re: Registry - Already easily doable, in part. (Tristan Wibberley)
Re: Registry for Linux - Bad idea (George MacDonald)
Re: Does brk hack still work (Wolfram Gloger)
Re: Linux Registry Stone Bitch to Administer ("Christian Gross")
----------------------------------------------------------------------------
Date: Mon, 28 Dec 1998 19:07:27 -0700
From: "D. Stimtis" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To:
comp.os.linux.advocacy,comp.os.linux.development,comp.os.linux.development.apps
Subject: Re: Santa's List
[EMAIL PROTECTED] wrote:
>
> Alright you primitive screwheads, listen up; in
> <75uahm$8jc$[EMAIL PROTECTED]>, on 12/24/98 at 09:09 PM,
> [EMAIL PROTECTED] babbled incoherently:
>
> >In article <75sml7$12ec$[EMAIL PROTECTED]>,
> > [EMAIL PROTECTED] (Frank Miles) wrote:
>
> >Santa's making a list. If You could have any piece of software ported to
> >Linux, other than Microsoft's what would it be?
>
> That's an easy one. Descent 3.
>
I'll second that vote. Can you imagine the market if makers of popular games sold them
for linux?
The reliability of even NT is terrible with games (at least with the multiprocessor
kernel). An
incredible amount of entertainment software is sold for Win 95 and 98, and a very
large part of the
people using it suffer from crash fatigue (the comp, not the craft in the game).
Sheesh, on #linux
there are a lot of people asking about games for battle.net too.
> --
> -----------------------------------------------------------
> Scott Banwart
> *no spam*[EMAIL PROTECTED]
> -----------------------------------------------------------
> "I don't know what I have just created, but it is ten times bigger than it should
>be."
> -A Microsoft programmer
------------------------------
From: [EMAIL PROTECTED] (Christopher B. Browne)
Crossposted-To:
comp.os.linux.misc,comp.os.linux.development.apps,comp.os.linux.hardware
Subject: Re: things I'd pay to have developed for Linux...
Date: 29 Dec 1998 04:34:43 GMT
Reply-To: [EMAIL PROTECTED]
On 20 Dec 1998 20:24:06 GMT, Kyler Laird <[EMAIL PROTECTED]>
posted:
>I recently made an offer to the Purdue Linux
>Users Group - $500 if they'd develop an SMB
>server for Linux. ($200 for food to get
>started. $300 upon completion. The server
>is just a mod of SAMBA that runs from the
>command line using stdio. It's something
>that would come in handy for students here.)
>
>I haven't yet gotten a response from them,
>but I've been thinking that there should be
>a place where Linux users can "put their
>money where their mouths are." There are
>several projects I'd like to encourage and
>I suspect others would like to do the same.
>This would be a much better course of action
>than whining about things Linux doesn't do.
Try: <http://visar.csustan.edu/bazaar/bazaar.html> which describes
almost exactly what you're asking for, or the (not quite implemented)
URL below...
--
Those who do not understand Unix are condemned to reinvent it, poorly.
-- Henry Spencer <http://www.hex.net/~cbbrowne/fssp.html>
[EMAIL PROTECTED] - "What have you contributed to Linux today?..."
------------------------------
From: [EMAIL PROTECTED] (Christopher B. Browne)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: 29 Dec 1998 05:19:40 GMT
Reply-To: [EMAIL PROTECTED]
On Tue, 22 Dec 1998 12:52:33 -0800, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> posted:
>On Tue, 22 Dec 1998 01:59:27 +0100, Michal Mosiewicz <[EMAIL PROTECTED]> wrote:
>>Richard RUDEK wrote:
>>> [...]
>>> I agree, a registry for linux is a bad idea. But I don't see how a standard
>>> configuration procedure "naturally suggests a single file".
>>
>>Why is it a bad idea?
>>
>>Or, let me put it this way - what is better than a single database
>>optimised for persistent configuration storage?
>
> A REAL database with transactions, rollback logs, real
> schemas, SQL92 compliance, an odbc/jdbc driver interface
> and automated disaster recovery.
Ah. So one that consumes many megabytes of disk, potentially of memory
for the server, perhaps some for each connection, and which is bloated
for the purpose.
"Real" databases are cool and all, but not for the purpose of managing
system configuration.
--
Those who do not understand Unix are condemned to reinvent it, poorly.
-- Henry Spencer <http://www.hex.net/~cbbrowne/lsf.html>
[EMAIL PROTECTED] - "What have you contributed to Linux today?..."
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: 29 Dec 1998 04:04:02 GMT
Reply-To: [EMAIL PROTECTED]
On Fri, 25 Dec 1998 10:35:36 -0800, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
>On 24 Dec 98 22:19:50 GMT, Pavel V. Zaitesev
<[EMAIL PROTECTED]> wrote:
>>Michal Mosiewicz ([EMAIL PROTECTED]) wrote:
>>: Why is it a bad idea?
>>
>>: Or, let me put it this way - what is better than a single database
>>: optimised for persistent configuration storage?
>><snip>
>>It is not a bad idea at all. It is just has to be:
>>1 . Implemented nicely.
>>2 . Debugged.
>
> There is no such thing as 'Debugged'.
This should be elaborated on somewhat.
The point is that you *can't* debug the "single database" until it
somehow magically "becomes robust." As a single point of failure, it
intrinsically represents a *lack* of robustness. The only way of
debugging it is to *GET RID OF IT* and replace it by a more widely
distributed set of databases.
Throwing everything at a single binary database is simply a *BAD IDEA*
because:
a) Binary databases require special attention in order to keep them
robust under conditions of possible "physical" failure. They are
remarkably vulnerable to that one "bad sector."
Distributing data across many files is not thus vulnerable.
a) "System" configuration cannot be characterized as a single database.
I won't recount them again, but I have counted on the order of 8
different kinds of configuration that distributes in different ways.
Managing configuration in a way that pretends that it is all data that
can just be flung into a database is foolish.
--
"Even in the area of anticompetitive conduct, Microsoft is mainly an
imitator." -- Ralph Nader (1998/11/11)
[EMAIL PROTECTED] <http://www.ntlug.org/~cbbrowne/lsf.html>
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Subject: Re: Kernel v2.2
Date: 29 Dec 1998 04:03:59 GMT
Reply-To: [EMAIL PROTECTED]
On 28 Dec 1998 18:41:38 GMT, Reality is a point of view
<[EMAIL PROTECTED]> wrote:
> +---- [EMAIL PROTECTED] wrote (28 Dec 1998 09:28:25 -0500):
> | Lastly we should take on the obligation of using these last 2.1.X kernels
> | and reporting any problems.
> +----
>
>Is there any sort of organized effort to do so? A recent
>inquiry about test suites came up empty . . .
There would be great value in the notion of constructing some test
suites that could "evaluate themselves" and thus allow validation of new
kernel versions.
I expect that useful results could be gotten by building a sequence of
small C source code files along with expected test results, so that one
would run something like:
#!/usr/bin/perl
foreach $i (0..299) {
$source = "test$i.c"; # Provided file
$object = "test$i";
$testoutput = "test$i.output";
$testexpectedresults = 'test$i.expect"; # Provided file
`gcc $source -o $object`;
`./object > $testoutput`;
$results = `cmp $testoutput $testexpectedresults`;
if ($results ne ``) {
print "Test $i failed\n";
++$bad;
} else {
print "Test $i succeeded\n";
++$ok;
}
`rm $object $testoutput`;
}
print "Total OK: $ok\nTotal failures: $bad\n";
Every time a bug is found, a program should be added to the list that
will provide output that at least *attempts* to validate that the bug is
present/absent.
Build some such "regression tests" for either the kernel or for LIBC,
and people would thank you roundly.
--
"Even in the area of anticompetitive conduct, Microsoft is mainly an
imitator." -- Ralph Nader (1998/11/11)
[EMAIL PROTECTED] <http://www.ntlug.org/~cbbrowne/lsf.html>
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Registry - Already easily doable, in part.
Date: 29 Dec 1998 04:04:04 GMT
Reply-To: [EMAIL PROTECTED]
On Mon, 28 Dec 1998 01:03:49 +0100, Michal Mosiewicz
<[EMAIL PROTECTED]> wrote:
>Tristan Wibberley wrote:
>> This sounds like a filesystem (except for the per application rights,
>> which is a little more complex, and probably unnecessary). The speed
>> problem then is probably caused by running interpreted scripts, and that
>> the files are typically less than the block size (4kb on intel?) which
>> is inefficient.
>
>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.
>
>By optimisation I mean something like clustering (related keys/values
>are groupped on the same pages) and indexing.
Those optimizations are both things that can be fairly nicely mapped
onto files and directories in filesystems.
If Reiserfs brings us more a efficient filesystem that makes effective
use of space allowing reasonable use of lots of small files, this quite
completely resolves the issue.
Even if not, *most* of the efficiency may be attained by using
still-relatively-small text files.
I have used the /etc/hosts illustration in the past. One might replace
the file, /etc/hosts, with a directory /etc/hosts, which contains a
series of files, each of which contains an IP address.
Thus, rather than
# cat /etc/hosts
192.168.1.1 chris.brownes.org chris mail cache
192.168.1.2 dave.brownes.org dave news
192.168.1.255 router.brownes.org router
which consumes 130 bytes, plus linkage data for the single file,
/etc/hosts, one would create the set of hosts thus:
# mkdir /etc/hosts
# cd /etc/hosts
# echo "192.168.1.1" > chris.brownes.org
# ln chris.brownes.org chris
# ln chris.brownes.org mail
# ln chris.brownes.org cache
# echo "192.168.1.2" > dave.brownes.org
# ln dave.brownes.org dave
# ln dave.brownes.org news
# echo "192.168.1.255" > router.brownes.org
# ln router.brownes.org router
Note that this results in 3 files containing a total of 35 bytes, plus
directory entries for 9 files. It is quite likely that the disk
consumption would significantly exceed 130 bytes whether with ext2 or
with reiserfs.
If we replaced this with entries in some sort of "binary database"
system, it is highly unlikely that equivalent functionality would take
less space than either of these "natural" UNIX representations unless
shortcuts were taken that would substantially reduce overall system
robustness.
--
"Waving away a cloud of smoke, I look up, and am blinded by a bright,
white light. It's God. No, not Richard Stallman, or Linus Torvalds, but
God. In a booming voice, He says: "THIS IS A SIGN. USE LINUX, THE FREE
UNIX SYSTEM FOR THE 386." -- Matt Welsh
[EMAIL PROTECTED] <http://www.ntlug.org/~cbbrowne/lsf.html>
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Registry for Linux - Bad idea
Date: 29 Dec 1998 04:17:35 GMT
Reply-To: [EMAIL PROTECTED]
On 28 Dec 1998 16:45:22 -0500, Chris Hanson <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]> Robert Krawitz
><[EMAIL PROTECTED]> writes:
>
> My suspicion about what's going on is that the kernel's not doing
> enough readahead; it's trying to simply demand page stuff in. Since
> most things jump around a fair bit, this results in a lot of random
> seek behavior, which really kills disk performance.
>
>Another thing that could help is support for code-sorting in the
>linker. With CodeWarrior on MacOS, I can have it sort code in output
>PEF containers (executables, shared libraries, etc.) based on
>depth-first or breadth-first traversal or a file of routine names I
>give it.
Ah. Look for "GNU Rope" aka "GROPE."
It sorts code, with the possibility of including statistical
measurements of what code actually gets loaded, so as to, as greedily as
necessary, put code on the same page that will be commonly used
together.
--
"Waving away a cloud of smoke, I look up, and am blinded by a bright,
white light. It's God. No, not Richard Stallman, or Linus Torvalds, but
God. In a booming voice, He says: "THIS IS A SIGN. USE LINUX, THE FREE
UNIX SYSTEM FOR THE 386." -- Matt Welsh
[EMAIL PROTECTED] <http://www.ntlug.org/~cbbrowne/lsf.html>
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Subject: Re: 2 stacks?
Date: 29 Dec 1998 04:04:09 GMT
Reply-To: [EMAIL PROTECTED]
On 26 Dec 1998 13:41:31 GMT, jan david mol <[EMAIL PROTECTED]> wrote:
>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.
>
>I'm not sure if this is one for the GCC compiler guys or the kernel ones.
Far more likely for GCC than for the kernel folk...
It is something that would be possible.
The downside is that the system then has to treat an additional register
as a stack register, thus reducing the number of registers available to
be used for other purposes. On the IA-32 architecture, where there are
limited numbers of "generally usable registers," this can injure
performance.
You win some, you lose some...
--
"Waving away a cloud of smoke, I look up, and am blinded by a bright,
white light. It's God. No, not Richard Stallman, or Linus Torvalds, but
God. In a booming voice, He says: "THIS IS A SIGN. USE LINUX, THE FREE
UNIX SYSTEM FOR THE 386." -- Matt Welsh
[EMAIL PROTECTED] <http://www.ntlug.org/~cbbrowne/lsf.html>
------------------------------
From: Tristan Wibberley <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Registry - Already easily doable, in part.
Date: Tue, 29 Dec 1998 04:49:06 +0000
Reply-To: [EMAIL PROTECTED]
Christopher Browne wrote:
>
> # mkdir /etc/hosts
> # cd /etc/hosts
> # echo "192.168.1.1" > chris.brownes.org
ln chris.brownes.org :192.168.1.1
> # ln chris.brownes.org chris
> # ln chris.brownes.org mail
> # ln chris.brownes.org cache
> # echo "192.168.1.2" > dave.brownes.org
ln dave.brownes.org :192.168.1.2
> # ln dave.brownes.org dave
> # ln dave.brownes.org news
> # echo "192.168.1.255" > router.brownes.org
you get the idea, reverse lookups via hosts needs attention too (note
the invalid hostname character ':' for clarity).
> # ln router.brownes.org router
>
> Note that this results in 3 files containing a total of 35 bytes, plus
> directory entries for 9 files. It is quite likely that the disk
> consumption would significantly exceed 130 bytes whether with ext2 or
> with reiserfs.
>
> If we replaced this with entries in some sort of "binary database"
> system, it is highly unlikely that equivalent functionality would take
> less space than either of these "natural" UNIX representations unless
> shortcuts were taken that would substantially reduce overall system
> robustness.
I think the database behaviour from filesystems is undoubtably the way
to go, but it needs some careful thought. Most of the routines at
boottime are simple and standard, and could be compacted easily, still
allowing for someone to use scripts if they need more complex
behaviours. It would be interesting to see what could actually be done
here.
--
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: Tue, 29 Dec 1998 05:38:18 GMT
Christopher B. Browne wrote:
>
> On Tue, 22 Dec 1998 12:52:33 -0800, [EMAIL PROTECTED]
> <[EMAIL PROTECTED]> posted:
> >On Tue, 22 Dec 1998 01:59:27 +0100, Michal Mosiewicz <[EMAIL PROTECTED]> wrote:
> >>Richard RUDEK wrote:
> >>> [...]
> >>> I agree, a registry for linux is a bad idea. But I don't see how a standard
> >>> configuration procedure "naturally suggests a single file".
> >>
> >>Why is it a bad idea?
> >>
> >>Or, let me put it this way - what is better than a single database
> >>optimised for persistent configuration storage?
> >
> > A REAL database with transactions, rollback logs, real
> > schemas, SQL92 compliance, an odbc/jdbc driver interface
> > and automated disaster recovery.
>
> Ah. So one that consumes many megabytes of disk, potentially of memory
> for the server, perhaps some for each connection, and which is bloated
> for the purpose.
>
> "Real" databases are cool and all, but not for the purpose of managing
> system configuration.
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.
The current flat file model is simple/robust/elegant and is a
natural fit for the environment. One day linux may run on mobile
computers(oops already is) and we want to keep the kernel as
small and as tight as possible. Also many core services will
want to be designed in the same manner. There is a great
deal of good about the current mechanisms, and there is
no reason for the vast majority of installations to change
from it.
Having said that, a more sophistacated config management mechanism
will be useful for component based apps and for high end systems
and servers. The only way to progress forward is to recognize
that the current system should be supported in a new config
system that wraps it in an OO layer while providing new
capabilities for components and more flexible storage.
It is possible to do both, in fact that's exactly what we should
do! Doing both is better than doing just one!
--
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: Wolfram Gloger <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: Does brk hack still work
Date: 28 Dec 1998 23:47:49 +0100
[EMAIL PROTECTED] (Stefaan A Eeckels) writes:
> In article <[EMAIL PROTECTED]>,
> George MacDonald <[EMAIL PROTECTED]> writes:
> > I once wrote a program that aquired a lot of dynamic memory using hundred
> > of malloc() calls at startup. When I did a
> >
> > ptr = malloc( SIZE_LARGER_THAN_TOTAL_OF_ALL_SMALL_CHUNKS )
> > free( ptr )
> >
> > at the start of the program, the program initialization time was cut in
> > half. This was caused by the fact that free() was not reducing the
> > amount of memory used, thus each new malloc did not require the system
> > call's to brk/sbrk.
On Linux you can tune the amount of memory that is newly sbrk()ed on a
malloc() call with mallopt(TOP_PAD, pad_size). In your case, you
could try to specify
mallopt(TOP_PAD, SIZE_LARGER_THAN_TOTAL_OF_ALL_SMALL_CHUNKS);
and possibly also
mallopt(M_TRIM_THRESHOLD, SIZE_LARGER_THAN_TOTAL_OF_ALL_SMALL_CHUNKS);
> Free() doesn't return memory to the system - AFAIK it never
> does.
free() certainly _can_ return memory to the system, and does so
extensively on Linux.
> > Anyone know if this is the same on Linux?
> I've never tested it, but I'd venture a guess that yes, it'd
> work under Linux too.
No way -- if SIZE_LARGER_THAN_TOTAL_OF_ALL_SMALL_CHUNKS is larger than
128k, the free() will by default return all of the memory back to the
system on Linux with glibc2 or recent libc5.
Regards,
Wolfram.
------------------------------
From: "Christian Gross" <[EMAIL PROTECTED]>
Subject: Re: Linux Registry Stone Bitch to Administer
Date: Tue, 29 Dec 1998 06:52:43 +0100
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
tester I cannot clean up my machine. To make beta test reproducible I need
to format and reinstall everything. I miss the days of .ini and files based
configurations. (Hmmm sound familar?)
So if anyone is really motivated to produce a registry clone, I say, just
say no!
Christian Gross
Michael Kelly wrote in message <[EMAIL PROTECTED]>...
>On 25 Dec 1998 22:57:11 PST, [EMAIL PROTECTED] (Satch) wrote:
>
>>Let me break out one element of the discussion of a "registry" for Linux:
>>the task of administrating such a beast.
>
>[snip out of good points for brevity]
>
>Just to add my $.02.. after reading the points made here it's evident
>that a scheme designed for a multi-tasking single-user system isn't
>necessarily the best idea for a multi-tasking multi-user system. :)
>
>
>
>
>Mike
>
>"Genius gives birth, talent delivers."
>
> - Jack Kerouac
>
>(remove NOSPAM from address, if present, to reply)
------------------------------
** 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
******************************
