This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [libc-alpha] Re: Wish for 2002 ...

On Sun, 13 Jan 2002, Shawn Starr wrote:

> While I'm not on the mailing list and do use C I think we need to make
> sure:
> We do not isolate ourself from the other UNIX platforms just for sake

What ``other''? What part of GNU is Not Unix isn't clear? :)

GNU/Linux us a Unix-like platform, because it makes sense to be that
right now. Though not nearly as much sense as it did in 1992.

The only operating system interface standards have come out of the Unix
world. It makes sense to implement standards and to continue to track them
where it makes sense. If there is a standard about how to do something,
it makes sense to do it that way rather than invent your own way of doing
it. Inventing your own way is counterproductive, and can only be due to
hidden motives, like getting people to write lots of software to your
unique interfaces, so that less of that software is available to users
of other platforms.

On the other hand, someone's locally developed functions are not
standards, so it doesn't make sense to implement those, except when
those functions are proprietary, and some important free software 
needs them.

You are confusing Unix with some kind of ideology, or ``happy family''
or something. Get over your stupid nostalgic emotions and start thinking

> of POSIX standards because then we'll loose in the long run. It would be

> Why don't we have a libbsd library for non standard functions and keep
> them out of glibc? Then if they got approved be moved into glibc?

If there is a program that you desperately want to run, and it is only
portable to BSD, then install and run BSD. How about that?

If people want to write code that requires BSD, they are entitled to do
so. But the world doesn't owe them portability in return, and they
probably don't expect it! I would hope that people coding for BSD are
competent enough to *know* when they are making a nonportable program, so
that when they do so it can only be the case that they don't *care*. When
the developer of the nonportable program doesn't care, why should the
GNU/Linux maintainers supply *extra* care to compensate the user for
that other developer's lack of caring?

By the way, can you name a BSD-only program that you would you like to
run on your GNU/Linux system but presently cannot?  Speaking for myself,
I cannot name such a program.

However, in 1990 there was sure lots of free software running on Unix that
I wanted to be able to run on a free operating system, using commodity
hardware. BSD hadn't been unencumbered yet; there was no free
implementation of Unix.

So you see, aping someone's interfaces makes sense when there is a whole
base of software that you would like to run. In particular when that
software is free, and is ``trapped'' by the programming interfaces of
a non-free system.

> Is there harm in doing this?

No harm at all; go ahead and start libbsd. I suspect you will probably
need some kernel hacking to get every last feature of BSD implemented
right.  What if the BSD program wants some system call that doesn't
exist in the Linux kernel, and can't be effectively emulated in libbsd?
It might make more sense to just emulate BSD at the system call level.
Then you could just use actual BSD libraries instead of writing them
from scratch.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]