Linux-Development-Sys Digest #888, Volume #6 Sat, 26 Jun 99 01:14:10 EDT
Contents:
Re: Configuration as Database (was Re: TAO: the ultimate OS) (Emile van bergen)
Re: TAO: the ultimate OS (Anthony Lovell)
/proc/ksyms on SMP machines ([EMAIL PROTECTED])
Re: Why not C++ ([EMAIL PROTECTED])
Re: Smallest memory allocation block? (Juergen Heinzl)
Re: Sound development in linux (Rick Walker)
Re: TAO: the ultimate OS (Roberto Alsina)
Re: Need a.out compiler (Frank v Waveren)
Re: TAO: the ultimate OS ("Crist�bal Garc�a")
Dreamland ("bedlam")
Re: using C++ for linux device drivers (Greg Comeau)
Re: compiling for a Hitachi SH-3 CPU with gcc (Mark Clayton)
Re: Why we are still holding on to X Windows (Cameron Hutchison)
virtual POP installation (eddycheung)
Re: using C++ for linux device drivers (Greg Comeau)
Re: Why not C++ (Bruce Hoult)
Re: Configuration as Database (was Re: TAO: the ultimate OS) (Christopher B. Browne)
----------------------------------------------------------------------------
From: Emile van bergen <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: Configuration as Database (was Re: TAO: the ultimate OS)
Date: Sat, 26 Jun 1999 03:09:39 +0200
On 25 Jun 1999, Terry Murphy wrote:
[SNIP]
>I am not familiar with libPropList (one of my favorite features of
>WindowMaker, is that it just saves my configuration operations without
>me having to mess with text files, so I never much bothered to see what
>was going on under the hood), but it sounds like a fine product (from
>what you describe). My problem, of course, with this sort of thing, is
>that it is non-standard, so only a few tools end up using it.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Actually, what defines a 'standard' library on linux is the amount of
tools using it. Your statement is the other way around. What is
'standard'? Ships with most distributions? If noone uses it, pretty
standard it is.
As with all libraries in the Free Software world: write a very good one,
so developers are persuaded to use it by its elegancy and features, and
give it some time. If it's good enough, it may even become a 'standard'.
There _is no separate standards body / authority_ that dictates which
userland libraries should be used on the free unices. And I'm glad. Let
the best one win, I'd say. Give it some time, a good config db will
emerge, developers will see its value and hopefully use it for both old
and new projects. Thats the way it works.
The only 'real' standards visible here are protocols and APIs layed out
in ISO/IETF/Posix/whatever documents. Since there is no such document
describing a configuration database for Un*x systems and Free Software
organisations don't tend to be members of standard committees due to the
fees involved, there's only the 'defacto by persuasion' mechanism
described above.
--
M.vr.gr. / Best regards,
Emile van Bergen (e-mail address: [EMAIL PROTECTED])
This e-mail message is 100% electronically degradeable and produced
on a GNU/Linux system.
~
~
:wq
------------------------------
From: Anthony Lovell <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: 24 Jun 1999 23:21:11 +0100
[EMAIL PROTECTED] (Terry Murphy) writes:
> In article <[EMAIL PROTECTED]>,
> Bill Anderson <[EMAIL PROTECTED]> wrote:
>
> [Re: why Database configuration systems are bad]
>
> >A few reasons:
> >o A failure of a proprietary, binary dataset results in total system
> >failure. Solution: reinstall OS.
>
> A database configuration editor can be used to edit a damaged
> databases. There is no reason why a well designed database
> would be more susceptible to damage than a text file. There
> is not much meta-data in fixed-length databases.
Except that we're not talking about a well designed database
but the windows registry
------------------------------
From: [EMAIL PROTECTED]
Subject: /proc/ksyms on SMP machines
Date: Sat, 26 Jun 1999 00:39:27 GMT
Some SMP machines with RH 6.0 attach 'Rsmp_<checksum>' while others
attach just 'R<checksum>' to the symbols in /proc/ksyms. Both machines
are compiled with SMP option in the kernel set to 'Y'.
Could somebody please tell me how and when does 'smp' get attached to
the symbols.
Thanks
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Why not C++
Date: Fri, 25 Jun 1999 21:01:51 GMT
In article <[EMAIL PROTECTED]>,
Johan Kullstam <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] writes:
>
> > In article <[EMAIL PROTECTED]>,
> > Johan Kullstam <[EMAIL PROTECTED]> wrote:
> > > "Ralph Glebe" <[EMAIL PROTECTED]> writes:
> > [&<]
> > >
> > > yes. the C part is very mature. the code produced is solid.
> > >
> > > the C++ standard keeps changing. for example, i had to recode a
lot
> > > of my applications in my transition from gcc-2.7.2.* to egcs. the
> > > egcs libstdc++ seems highly volatile. i'd rather keep as little
> > > dependent upon it as possible. at least, now, if C++ libs break,
i
> > > can at least recompile what i have without the catastrophe of
> > > missing/broken libc.
> >
> > The C++ standard is no longer changing, period. The compilers and
> > library implementations are changing because they are still catching
up,
> > but the standard has been finished for over a year.
>
> the standard may be out, but the libraries and implementations are
> still catching up and they will be doing so for a good while longer.
> even conforming implementations may well have conflicting binaries.
> in effect, it's almost as annoying as a moving standard. despite a
> standard, i still have 4 incompatible versions of libstdc++.
>
> > Please be careful not to fud.
>
> standards are always being revised. fortran has had how many
> revisions? there are at least iv, 66, 77 and 90. C has had K&R, ANSI
> and is getting a new revision called C9X although X seems to be likely
> to exceed 9. there will be a new C++ along in a few years. just you
> wait.
>
First you say C++ isn't used because that standard is changing. I say
the standard is changing but the implementations are (to catch up). Then
you say the C++ standard isn't changing, C++ isn't used 'cause the
implementation is still changing and that, furthermore, standards change
and just you wait the C++ standard will change soon. Sounds like fud to
me.
Jack Walker
Don't fear the ++
> --
> J o h a n K u l l s t a m
> [[EMAIL PROTECTED]]
> Don't Fear the Penguin!
>
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (Juergen Heinzl)
Subject: Re: Smallest memory allocation block?
Date: Fri, 25 Jun 1999 21:14:50 GMT
In article <7l0odp$ell$[EMAIL PROTECTED]>, Anand wrote:
>What is the smallest amount of memory that Linux allocates? If I do
>"malloc(1)" does Linux allocate only 1 byte from its internal free
>memory pool or is there a minimum amount of memory that is allocated?
>
>If the amount of memory requested is less than this minimum then is the
>remaining memory in the allocated block a waste or is it used for any
>purpose?
>
>An answer for any version of Linux kernel is good enough for me.
It is one page and the actual page size can differ ...
#include <stdio.h>
#include <unistd.h>
int main() {
printf( "%lu\n", (unsigned long)getpagesize() );
}
... so I do not want to state 4K is true on DEC's too.
Ta',
Juergen
--
\ Real name : J�rgen Heinzl \ no flames /
\ EMail Private : [EMAIL PROTECTED] \ send money instead /
------------------------------
From: [EMAIL PROTECTED] (Rick Walker)
Subject: Re: Sound development in linux
Date: 25 Jun 1999 21:03:37 GMT
Kimberly Doring ([EMAIL PROTECTED]) wrote:
: I need to write some code that will play a sound file in linux. Is
: there an audio library for linux, or do I just write to /dev/audio
: directly? Can anyone direct me to some documentation on this topic?
You can find documentation at
http://www.4front-tech.com/pguide/audio.html
Best regards,
--
Rick Walker
------------------------------
From: Roberto Alsina <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc
Subject: Re: TAO: the ultimate OS
Date: Sat, 26 Jun 1999 01:40:45 GMT
In article <i8Ac3.88254$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> This is why I would suggest that GNOME is more likely to be long-term
> viable than KDE; they "opened the gates" for people to fiddle with
> some of the components, but have taken a considerable period of time
> to start to establish their compound document infrastructure.
Let's see: KDE's compound document infrastructure is being used by half
a dozen big applications, it has been stable (mostly) for the last 6
months and started development about a year before GNOME's (which is
still not out even in alpha form or used by anything until 3 weeks ago,
AFAIK).
Now, what exactly is your opinion based on?
--
Roberto Alsina (KDE developer, MFCH)
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (Frank v Waveren)
Subject: Re: Need a.out compiler
Date: Fri, 25 Jun 1999 22:32:51 GMT
In article <[EMAIL PROTECTED]>,
Aaron Thompson <[EMAIL PROTECTED]> writes:
> exactly. i need the libs.
Ah. That's trickier. Have you tried getting a really old distro somewhere?
--
Frank v Waveren
[EMAIL PROTECTED]
ICQ# 10074100
------------------------------
From: "Crist�bal Garc�a" <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: Fri, 25 Jun 1999 13:57:04 +0200
Terry Murphy escribi� en mensaje <7kp9pq$9gg$[EMAIL PROTECTED]>...
>In article <7kp52j$f94$[EMAIL PROTECTED]>,
>Stefaan A Eeckels <[EMAIL PROTECTED]> wrote:
>
>>The problem is that very often a detailed and unambiguous
>>design document is *more* difficult to realize, *and* less
>>unambiguous than the actual code.
>
>Of course its less unambiguous (inevitably). My concern is, if you dive
I've been follwing the thread and I'd like to express my opinion but before
doing so I think I should be good summarize a bit. If I haven't understood
this bad ('cos my english is not very good) there are two major positions:
1.- The one which defends a more formal software engineering and tells
that linux (and linux commuity lacks of it)
2.- The one which tells that software engineering is a waste of time
In my experience as software developer, software enginnering is THE ONLY way
to create good complex software with reasonable costs. When I say costs I'm
speaking of programmer/designer, etc hours which must be paid.
Every company which must develop soft must (IMHO) use a formal process to
develop soft (and this formal process is not bad because Micro$soft is using
it).
However there are a lot of soft developen without design (formal), and some
of this is very good (I use vim in my work), but really is not the average
case.
Another thing I've seen here is the old discussion about centralized
configuration (aka registry) vs. "distributed" configuration. I agree that
the centralized way is better than the distributed. Anyone could say that's
more error-prone but I think that you can implement a centralized
configuration with a lot of backup measures, ECC, etc in order to prevent
sys crashes. A good API to manipulate config from programs would help also.
A last thing, I've worked also as sysman and If I've got out all the
software engineers out of my machines, probably I'd get fired 'cause my work
consisted on making computers usable to the soft desing/developing staff.
I love unix/linux and use it at home and work but a little bit of
constructive criticism would help us a lot
------------------------------
From: "bedlam" <[EMAIL PROTECTED]>
Subject: Dreamland
Date: Fri, 25 Jun 1999 20:44:32 -0600
Hi. For ten years, I have been wanting to create a community where people
can spend their time doing what they *want* to do, not what they *have* to
do.
I have started creating web pages about this project, and expect to have the
land by the year 2005. If you are interested in this, want to participate,
or just want to exchange ideas, please visit my web pages:
http://www.dimensional.com/~bedlam/Dreamland
Thanks!
Robert Holder
------------------------------
From: [EMAIL PROTECTED] (Greg Comeau)
Subject: Re: using C++ for linux device drivers
Date: 25 Jun 1999 22:50:49 -0400
Reply-To: [EMAIL PROTECTED]
In article <e2fb3.9384$[EMAIL PROTECTED]> [EMAIL PROTECTED] writes:
>The main argument against C++ is still overhead.
Perhaps it's your main argument, but that doesn't mean that the argument
is valid.
> Even when you turn off
>many of the features, you still have overhead that is greater than C.
This is an irresponsible and misleading statement.
- Greg
--
Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
Producers of Comeau C/C++ 4.2.38 -- New Release! We now do Windows too.
Email: [EMAIL PROTECTED] / Voice:718-945-0009 / Fax:718-441-2310
*** WEB: http://www.comeaucomputing.com ***
------------------------------
Reply-To: [EMAIL PROTECTED]
From: [EMAIL PROTECTED] (Mark Clayton)
Subject: Re: compiling for a Hitachi SH-3 CPU with gcc
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.questions
Date: Fri, 25 Jun 1999 23:19:47 GMT
[Posted and mailed]
In article <7kb9uo$eff$[EMAIL PROTECTED]>,
"Peter Gutmann" <[EMAIL PROTECTED]> writes:
> I'm actually looking for the libraries (or modules; whatever needed) to
> compile programs for a Hitachi SH-3 CPU with gcc running on i386 linux.
The gcc compiles for SuperH (SH1,2,3&4) targets on *nix, Linux, NT and DJGPP.
Mark
--
[EMAIL PROTECTED]
------------------------------
From: Cameron Hutchison <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Why we are still holding on to X Windows
Date: 25 Jun 1999 23:19:04 GMT
Tristan Wibberley <[EMAIL PROTECTED]> writes:
>Cameron Hutchison wrote:
>>
>> X should be thought of as a user I/O service, not just a display service.
>X's full name is The X Window System. It is not a general IO service, it
>does _Window_System_ stuff.
I never said it was a general IO service. I said it should be a *user* IO
service. Disk/network IO are not part of X, nor do I think they should be.
That aside, I believe the original X protocol included sound support
anyway. XBell(). That was the extent of the capability of sound at the
time. We now have far better sound capabilities, so X should continue its
sound support and be extended for these new capabilities.
As already agreed on this thread, font support for X could be much better.
It hasn't kept up with the times as anti-aliasing becomes feasible. I say
XBell() has fallen behind the times and that too needs to be updated. Just
as adding shades of grey to fonts, we need more shades of tone to be added
to the *existing* sound support of X.
>Sound is not window system stuff, input is
>(input is redirected around the windows according to window system
>behaviour).
I can see that sound is just as associated with a window as input is.
Keyboard input is quite a different thing to graphic output, yet keyboard
input part of X because it needs to integrate with it. Ditto for sound.
--
Cameron Hutchison ([EMAIL PROTECTED]) | Onward To Mars
GCS d--@ -p+ c++(++++) l++ u+ e+ m+(-) s n- h++ f? !g w+ t r+
------------------------------
Date: Sat, 26 Jun 1999 12:03:10 +0800
From: eddycheung <[EMAIL PROTECTED]>
Subject: virtual POP installation
I want to setup single IP virtual mail domain using Redhat 6.0 . The
SMTP works properly. But when I setup virtual POP3It doesn't work.
What to telent that virtual domain using port 110, it connects to the
*Original* domain instead of the virtual domain.
I have include the following line in /etc/inetd.conf
pop-3 stream tcp nowait root /usr/sbin/tcpd
/usr/lib/linuxconf/lib/vpop3d ipop3d
How can I do ?
Eddy
------------------------------
From: [EMAIL PROTECTED] (Greg Comeau)
Subject: Re: using C++ for linux device drivers
Date: 25 Jun 1999 22:38:47 -0400
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]> Frank Sweetser <[EMAIL PROTECTED]>
writes:
>[EMAIL PROTECTED] (Nathan Myers) writes:
>
>> Frank Sweetser <[EMAIL PROTECTED]> wrote:
>> >Justin Vallon <[EMAIL PROTECTED]> writes:
>> >> [EMAIL PROTECTED] (Alexander Viro) writes:
>> >> > In article <7kdqj9$l1o$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>> >> > > I am working a sound driver for linux (I will probably use OSS).I
>> >> > >am planning to use C++, instead of C.
>> >>
>> >> void *operator new(size_t s) { return malloc(s); /* kmalloc, etc */ }
>> >> void operator delete(void *p) { free(p); }
>> >
>> >...which is a higher-overhead version of
>> >
>> >#define new((x)) malloc((x))
>> >#define delete((x)) free((x))
>>
>> Frank, you are confused beyond salvation on this point.
>> Best drop it.
>
>exactly how am i confused? (honest question, i'm not trying to flame...)
>the only overhead to which i was referring is the overhead of calling a
>function that does nothing but call the function you really want. and yes,
>you do want to worry about that kind of optimization in the kernel code at
>times. note that this will not simply be inlined by the compiler in the
>case of the kernel unless you tell it to.
Because when somebody said:
> No it isn't, it is very different. malloc and free don't construct the
> objects they just alllocate the memory.
you said:
|yup. but, then, neither do the versions written as non-inline functions up
|above. mine also has this flaw, but at least it ends up as a bit of inline
|code rather than another function call on every new/delete...
Which misses the point that new T will call op new, hence the version
above can be used to construct the objects and not just allocate the mem.
It also misses the point that in something like the kernal you probably
_would_ inline the respective op new's. I've never done kernel builds for
LINUX but I'm certain there is a #define already which can be "queried"
in the same header as where youe #define's woulda been.
>> >> Compile with -nostdinc++ -fno-exceptions.
>> >>
>> >> Static constructors may need a C++ link phase, or you could warn that
>> >> C++ static constructors will not be executed.
>> >
>> >don't forget about name mangling, call by reference, the whole
>> >private/public/protected mess...
>>
>> Name mangling is dealt with by 'extern "C"'.
>
>hrm... IIRC, there were some issues that came up with the last time this
>matter got hashed out regarding exporting symbols from C++ code - ie, going
>the other way. i may be misremembering, though...
If I understand you, you'd still use extern "C".
>> Call-by-reference is a non-issue; no kernel function or callback uses it.
>
>another feature of C++ that can't be used.
No, that's not what Nathan meant at all. It CAN be used, just not in
the current kernel interface! This is of course circular, since if
it were C++'ized, I bet they would begin showing up in the _future_
in some interfaces (again, regular could would be able to use them
with no problem).
>> There is no such thing as a "private/public/protected" mess.
>> Those keywords have no effect on the emitted object code.
>
>another feature of C++ that can't be used.
This response makes no sense. Of course they can.
>> That they are keywords at all might break some kernel headers.
>
>i guess my biggest point here is - once you take away all of the extra
>feautures that won't work or don't make sense in the kernel context, what
>advantages does C++ realy have for writing a kernel module?
Most good C++ texts will enumerate this kind of thing.
The problem though is that you are rejecting valid features and then
saying since they can't be used what's the use.
- Greg
--
Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
Producers of Comeau C/C++ 4.2.38 -- New Release! We now do Windows too.
Email: [EMAIL PROTECTED] / Voice:718-945-0009 / Fax:718-441-2310
*** WEB: http://www.comeaucomputing.com ***
------------------------------
From: [EMAIL PROTECTED] (Bruce Hoult)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: Sat, 26 Jun 1999 00:53:24 +1200
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Jan Panteltje) wrote:
> >In article <wt4sjyngo9.fs C++ and Java are
> >much better than C. Dylan is much better than C++ and Java.
> >
> Well if I distill 'better' from that, then (I have not tested Dylan, liked
> some of Bops songs though), then it must be f*cking slow and bloated.
Current implementations carry along some fairly big libraries, but speed
is up there in the ballpark with other fully-compiled languages such as
Pascal/C/C++/FORTRAN/Ada and is improving as the compilers get better.
> It is not true (to any extend) that C++ is much 'better' then C.
Not true, IMHO. Even such simple things as // comments, declaring
variables at first use, inline functions and const instead of #define,
structs as type names, references, cleaned-up casting, and default
arguments make C++ better than C.
> In fact any thing you can do in C++ can also be done in C.
> Many times object oriented programming is not even needed, or even desirable.
> And the use of classes is for sure just a programming decision, nothing
> fundamental.
Quite true.
And anything you can do in C++ or C, you can also do by directly toggling
in machine code in binary. The use of an assembler or compiler is just a
programming decision, nothing fundamental.
However that argument says nothing about programmer convenience and
productivity. Like C and C++, Dylan aims to enable the programmer to get
as close to the speed of hand-coded machine code as possible. In many
cases, the "d2c" compiler I use produces programs that perform identically
to the equivalent C program, in othe cases it's a few percent slower (the
gap is narrowing for more and more cases as the compiler improves).
Dylan is not several hundred percent slower than C as Java is.
> I speak both, C, and C++, and admit to mostly using C.
> Because it is fast, small code size, portable.
> Java is IMNSHO (In My Not So Humble Opinion) a PIG, maybe even an elephant.
> Because it is so slow
I agree that Java is a slow pig. Much of this is due to the usual
bytecode implementations which have big performance penalties even with a
JIT JVM. But Java also has a number of serious performance problems
inherent in the design, even with a native compiler. That doesn't stop it
being useful for a number of things, including the ability to bash out
reliable code very quickly in terms of programmer time. Dylan has all the
programmer productivity advantages of Java wihout the slowness.
> In fact every language has its advantages, but great is the programmer who
> really masters the language (whatever language), he can write anything.
I can happily write anything in 68K or PPC assembler, PL/I, Pascal, C, C++
or Java.
-- Bruce
------------------------------
From: [EMAIL PROTECTED] (Christopher B. Browne)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: Configuration as Database (was Re: TAO: the ultimate OS)
Reply-To: [EMAIL PROTECTED]
Date: Sat, 26 Jun 1999 04:20:24 GMT
On Sat, 26 Jun 1999 03:09:39 +0200, Emile van bergen
<[EMAIL PROTECTED]> posted:
>On 25 Jun 1999, Terry Murphy wrote:
>[SNIP]
>
>>I am not familiar with libPropList (one of my favorite features of
>>WindowMaker, is that it just saves my configuration operations without
>>me having to mess with text files, so I never much bothered to see what
>>was going on under the hood), but it sounds like a fine product (from
>>what you describe). My problem, of course, with this sort of thing, is
>>that it is non-standard, so only a few tools end up using it.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>Actually, what defines a 'standard' library on linux is the amount of
>tools using it. Your statement is the other way around. What is
>'standard'? Ships with most distributions? If noone uses it, pretty
>standard it is.
There are two kinds of standards;
a) De facto, and
b) De jure.
A standard that comes into existence as a result of "what people do"
reflects the former; one that exists as an imposed regulation is the latter.
The format provided by libPropList reflects the former variety; it is the
format used widely on NeXTstep-related systems, supported also by OPENSTEP,
GNUstep, and is used particularly by WindowMaker. That does not reflect
extremely widespread use on Linux, but if you look at the libPropList
documentation, and particularly the change log, you'll find an interestingly
diverse set of (mostly) Linux developers.
>As with all libraries in the Free Software world: write a very good one,
>so developers are persuaded to use it by its elegancy and features, and
>give it some time. If it's good enough, it may even become a 'standard'.
Exactly. If it's good, and is publicized a little, developers may consider
using it. Old software may or may not get "retrofitted;" if multiple new
software packages benefit from it, that can render the new facility viable,
and encourage further use.
>There _is no separate standards body / authority_ that dictates which
>userland libraries should be used on the free unices. And I'm glad. Let
>the best one win, I'd say. Give it some time, a good config db will
>emerge, developers will see its value and hopefully use it for both old
>and new projects. Thats the way it works.
>
>The only 'real' standards visible here are protocols and APIs layed out
>in ISO/IETF/Posix/whatever documents. Since there is no such document
>describing a configuration database for Un*x systems and Free Software
>organisations don't tend to be members of standard committees due to the
>fees involved, there's only the 'defacto by persuasion' mechanism
>described above.
The IETF is probably the most-followed standards organization; there are a
few *very* important API standards, but it turns out that it is generally
easier to specify protocol/data format, and synchronize based on *that.*
I would suggest that the Linux community hasn't participated nearly enough
as a whole in the standards bodies, to date. This is changing, somewhat.
It would nonetheless be a wise move for people considering creating new
software to take a look out at the IETF RFCs to see if maybe, perhaps, there
might be an existing protocol that they might use rather than creating Yet
Another Address Book Format, or Yet Another Calendar Format, or any number
of the other things for which possibly interoperable standards have been
established.
--
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 free software today?..."
------------------------------
** 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
******************************
