On Fri, 13 Aug 1999 09:16:09 -0400, Jamie Howard wrote:
I saw someone say that anything NetBSD did in the name of portability must
be right (in the test thread). :)
Close, but what I said was more along the lines that following NetBSD's
footsteps on issues relating to portability is
On Fri, 13 Aug 1999, Sheldon Hearn wrote:
Close, but what I said was more along the lines that following NetBSD's
footsteps on issues relating to portability is _seldom_ a bad idea.
I was close enough that you know the exact quote so I think I did alright.
Back to the point, just stick it in
On Fri, 13 Aug 1999, Jamie Howard wrote:
On Fri, 13 Aug 1999, Sheldon Hearn wrote:
Close, but what I said was more along the lines that following NetBSD's
footsteps on issues relating to portability is _seldom_ a bad idea.
I was close enough that you know the exact quote so I think I
On Thu, 12 Aug 1999, Jamie Howard wrote:
How would those functions which also exist in libc (or possibly other
libraries, I don't know) be handled?
Just following up to myself here, NetBSD has a getopt_long() in libc
ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-current/src/lib/libc/stdlib/
I saw
On Fri, 13 Aug 1999 09:16:09 -0400, Jamie Howard wrote:
I saw someone say that anything NetBSD did in the name of portability must
be right (in the test thread). :)
Close, but what I said was more along the lines that following NetBSD's
footsteps on issues relating to portability is
On Fri, 13 Aug 1999, Sheldon Hearn wrote:
Close, but what I said was more along the lines that following NetBSD's
footsteps on issues relating to portability is _seldom_ a bad idea.
I was close enough that you know the exact quote so I think I did alright.
Back to the point, just stick it in
On Fri, 13 Aug 1999, Jamie Howard wrote:
On Fri, 13 Aug 1999, Sheldon Hearn wrote:
Close, but what I said was more along the lines that following NetBSD's
footsteps on issues relating to portability is _seldom_ a bad idea.
I was close enough that you know the exact quote so I think I
On Fri, 13 Aug 1999 12:52:05 -0400, Brian F. Feldman wrote:
Direct veto by core member (Jordan) prevents this. I really think it
should be in libcompat, the more I consider every option.
Regardless of what Jordan says, you should do your best to put it where
most other folks put it.
On Wed, 11 Aug 1999, Warner Losh wrote:
In message [EMAIL PROTECTED] "Brian F.
Feldman" writes:
: What do you all think about growing a gnu subdirectory in src/lib/libcompat?
: Things like a getopt_long implementation (yes, if it will be accepted,
: I am volunteering to write it...) would
Brian F. Feldman wrote:
On Wed, 11 Aug 1999, Warner Losh wrote:
In message [EMAIL PROTECTED] "Brian F.
Feldman" writes:
: What do you all think about growing a gnu subdirectory in src/lib/libcompat?
: Things like a getopt_long implementation (yes, if it will be accepted,
: I am
On Thu, 12 Aug 1999, Steve Kargl wrote:
If you're writing unencumbered code, placing it under
libcompat/gnu may lead to confusion because all other
directory paths containing gnu contain GPL'd code.
Just stick it into libcompat.
That doesn't fit with the current organization.
Choose:
In message [EMAIL PROTECTED] Steve Kargl writes:
: If you're writing unencumbered code, placing it under
: libcompat/gnu may lead to confusion because all other
: directory paths containing gnu contain GPL'd code.
: Just stick it into libcompat.
Or libiberty :-) That way we can have a GPL-free
Brian F. Feldman wrote:
On Thu, 12 Aug 1999, Steve Kargl wrote:
If you're writing unencumbered code, placing it under
libcompat/gnu may lead to confusion because all other
directory paths containing gnu contain GPL'd code.
Just stick it into libcompat.
That doesn't fit with the
In message [EMAIL PROTECTED] "Brian F.
Feldman" writes:
: There
: is simply no reason to assume that anything under a gnu directory is GPLd,
: or that anything GPLd is going to be under a gnu directory (which it's not.)
I'm afraid there is. It has been stated many times in the past that
all
On Thu, 12 Aug 1999, Steve Kargl wrote:
Brian F. Feldman wrote:
If you're writing unencumbered code, placing it under
libcompat/gnu may lead to confusion because all other
directory paths containing gnu contain GPL'd code.
Just stick it into libcompat.
How about libcompat/gnuish?
On Thu, 12 Aug 1999, Tim Vanderhoek wrote:
src/lib/libgnucompat seems to be the best suggestion so far. I wonder
where the line between libgnucompat and libfreebsdextension is,
though.
I've only been active here a few weeks but I've grown used to the "go
ahead and do it" I know I'm about to
On Thu, 12 Aug 1999, Tim Vanderhoek wrote:
On Thu, Aug 12, 1999 at 02:21:11PM -0400, Brian F. Feldman wrote:
I don't care if most of the
directories called "gnu" in the current tree contain GPLd code. How
I had to read your message about 4
ch...@calldei.com (Chris Costello) writes:
I'm in favor of a libgnucompat rather than gnu functions in
libcompat.
And how would a libgnucompat be different from libiberty? Except of
course that it would be maintained by the FreeBSD folks... Or that it
would be maintained at all. ;--)
On Wed, 11 Aug 1999, Warner Losh wrote:
In message pine.bsf.4.10.9908112337400.81521-100...@janus.syracuse.net
Brian F. Feldman writes:
: What do you all think about growing a gnu subdirectory in src/lib/libcompat?
: Things like a getopt_long implementation (yes, if it will be accepted,
: I
Brian F. Feldman wrote:
On Wed, 11 Aug 1999, Warner Losh wrote:
In message pine.bsf.4.10.9908112337400.81521-100...@janus.syracuse.net
Brian F. Feldman writes:
: What do you all think about growing a gnu subdirectory in
src/lib/libcompat?
: Things like a getopt_long implementation
On Thu, 12 Aug 1999, Steve Kargl wrote:
If you're writing unencumbered code, placing it under
libcompat/gnu may lead to confusion because all other
directory paths containing gnu contain GPL'd code.
Just stick it into libcompat.
That doesn't fit with the current organization.
Choose:
In message 199908121632.jaa26...@troutmask.apl.washington.edu Steve Kargl
writes:
: If you're writing unencumbered code, placing it under
: libcompat/gnu may lead to confusion because all other
: directory paths containing gnu contain GPL'd code.
: Just stick it into libcompat.
Or libiberty :-)
On Thu, 12 Aug 1999, Warner Losh wrote:
I hate the GPL. It has too many different interpretations. Look at
the currentsituation with Linux: Linus says loadable drivers in Linux
aren't covered by the GPL, while Stallman insists that they are. Its
interpretation is open to too many variables
Brian F. Feldman wrote:
On Thu, 12 Aug 1999, Steve Kargl wrote:
If you're writing unencumbered code, placing it under
libcompat/gnu may lead to confusion because all other
directory paths containing gnu contain GPL'd code.
Just stick it into libcompat.
That doesn't fit with the
On Thu, 12 Aug 1999, Steve Kargl wrote:
That doesn't fit with the current organization.
Choose:
a. fsf
b. gnu
c. glibc
d. other
src/lib/libcompat/{fsf,gnu,glibc} connotes GPL code.
src/lib/libcompat/other allows SysV, Solaris, Linux, etc.
compatibility
In message pine.bsf.4.10.9908121417340.94208-100...@janus.syracuse.net Brian
F. Feldman writes:
: There
: is simply no reason to assume that anything under a gnu directory is GPLd,
: or that anything GPLd is going to be under a gnu directory (which it's not.)
I'm afraid there is. It has been
: There
: is simply no reason to assume that anything under a gnu directory is GPLd,
: or that anything GPLd is going to be under a gnu directory (which it's not.)
I'm afraid there is. It has been stated many times in the past that
all GPL'd software resides under gnu. This is true in the
On Thu, 12 Aug 1999, Steve Kargl wrote:
Brian F. Feldman wrote:
If you're writing unencumbered code, placing it under
libcompat/gnu may lead to confusion because all other
directory paths containing gnu contain GPL'd code.
Just stick it into libcompat.
How about libcompat/gnuish? (Funny,
On Thu, Aug 12, 1999 at 02:21:11PM -0400, Brian F. Feldman wrote:
I don't care if most of the
directories called gnu in the current tree contain GPLd code. How
I had to read your message about 4 or 5 times before I realized that
Oh, the ``gnu'' in
On Thu, 12 Aug 1999, Tim Vanderhoek wrote:
src/lib/libgnucompat seems to be the best suggestion so far. I wonder
where the line between libgnucompat and libfreebsdextension is,
though.
I've only been active here a few weeks but I've grown used to the go
ahead and do it I know I'm about to
On Thu, 12 Aug 1999, Tim Vanderhoek wrote:
On Thu, Aug 12, 1999 at 02:21:11PM -0400, Brian F. Feldman wrote:
I don't care if most of the
directories called gnu in the current tree contain GPLd code. How
I had to read your message about 4 or 5
What do you all think about growing a gnu subdirectory in src/lib/libcompat?
Things like a getopt_long implementation (yes, if it will be accepted,
I am volunteering to write it...) would go there, and all sorts of lame
GNU libc cruft that we can try to be more compatible with.
Brian
On 12-Aug-99 Brian F. Feldman wrote:
What do you all think about growing a gnu subdirectory in src/lib/libcompat?
Things like a getopt_long implementation (yes, if it will be accepted,
I am volunteering to write it...) would go there, and all sorts of lame
GNU libc cruft that we can try
On Wed, Aug 11, 1999, Brian F. Feldman wrote:
What do you all think about growing a gnu subdirectory in src/lib/libcompat?
Things like a getopt_long implementation (yes, if it will be accepted,
I am volunteering to write it...) would go there, and all sorts of lame
GNU libc cruft that we can
In message [EMAIL PROTECTED] "Brian F.
Feldman" writes:
: What do you all think about growing a gnu subdirectory in src/lib/libcompat?
: Things like a getopt_long implementation (yes, if it will be accepted,
: I am volunteering to write it...) would go there, and all sorts of lame
: GNU libc
What do you all think about growing a gnu subdirectory in src/lib/libcompat?
Things like a getopt_long implementation (yes, if it will be accepted,
I am volunteering to write it...) would go there, and all sorts of lame
GNU libc cruft that we can try to be more compatible with.
Brian Fundakowski
On 12-Aug-99 Brian F. Feldman wrote:
What do you all think about growing a gnu subdirectory in src/lib/libcompat?
Things like a getopt_long implementation (yes, if it will be accepted,
I am volunteering to write it...) would go there, and all sorts of lame
GNU libc cruft that we can try
On Wed, Aug 11, 1999, Brian F. Feldman wrote:
What do you all think about growing a gnu subdirectory in src/lib/libcompat?
Things like a getopt_long implementation (yes, if it will be accepted,
I am volunteering to write it...) would go there, and all sorts of lame
GNU libc cruft that we can
In message pine.bsf.4.10.9908112337400.81521-100...@janus.syracuse.net Brian
F. Feldman writes:
: What do you all think about growing a gnu subdirectory in src/lib/libcompat?
: Things like a getopt_long implementation (yes, if it will be accepted,
: I am volunteering to write it...) would go
39 matches
Mail list logo
