merely saying that we have fixed
our libc so that it is highly compatible, and that we continue to
strive to do better.
--
Perry E. Metzger[EMAIL PROTECTED]
quot;how
> do I call userland utility", etc - most of that is in the NetBSD.cf
> patch.
Okay, so it wasn't functional issues, it was integration issues. Gotcha.
--
Perry E. Metzger[EMAIL PROTECTED]
you
> seem to be ignoring it.
Why do you want NetBSD's kernel? You obviously believe everything that
NetBSD has done is fecal, so what would the point of contaminating the
"superior" GNU userland with a crappy NetBSD kernel?
--
Perry E. Metzger[EMAIL PROTECTED]
Joel Baker <[EMAIL PROTECTED]> writes:
> While I'd dearly love to see a bit more de-coupling of NetBSD kernel and
> libc (so that they don't have to be in quite such lockstep, though I'm more
> worried about the process utilities that must be *exact* matches), I don't
> claim that managing it woul
Robert Millan <[EMAIL PROTECTED]> writes:
>> That's not what "third party" means. "Third party" means stuff not
>> provided by The NetBSD Foundation in our releases. The BSD world
>> doesn't work quite the way the Linux world does in this regard. We
>> maintain both a kernel and a tightly integrat
Nathan Hawkins <[EMAIL PROTECTED]> writes:
>> > (btw, fixing the X server is on my todo)
>>
>> All I have to say about the X server, as the person who generated most
>> of the patches, is that they're actually very straightforward, if rather
>> invasive. I simply had to go through each config opt
gs in
the thread engine itself.
> If you want to help or propose a solution, that's fine, but stop playing
> devil's advocate which is just a waste of my time.
I'm not playing devil's advocate. I'm trying to tell you the
truth to try to help you. You seem to be unwilling to listen. Thus,
I'll drop out of the conversation. Do whatever you want.
--
Perry E. Metzger[EMAIL PROTECTED]
ught them to a stage that
> took years for a group of people to attain.
Ever hear of the 80/20 rule? I easily believe you can get the thing
very far along inside a couple of months. Trying to make it actually
bulletproof for production use -- especially with all the bells and
whistles complete -- is not the same thing.
--
Perry E. Metzger[EMAIL PROTECTED]
e to make the new Linux threads work on
NetBSD in a reasonable amount of time. That said, the NetBSD threads
stuff has pervasive hooks throughout libc
--
Perry E. Metzger[EMAIL PROTECTED]
possible to re-implement them and fix
them in the native NetBSD libc. NetBSD would like to be maximally
compatible with third party apps, so we add stuff we need all the time
and are happy to do it. It would also likely be far less work to add a
few dozen new functions to libc than for you to re-
ols.
You would be much better off just specifying what was missing from the
native libc so that it could be added -- that, at least, is a
tractable problem.
--
Perry E. Metzger[EMAIL PROTECTED]
Nathan Hawkins <[EMAIL PROTECTED]> writes:
>> Although it is still not as stable as we'd like, the benchmarks of the
>> native threads on NetBSD are pretty damn impressive. I'd say that not
>> using the native threads would be a tremendous waste...
>
> For my part, I'm of the opinion that threads
rt that will be
> released with 2.0 (some packages simply *will not* build with GNU pth as
> pthreads).
Although it is still not as stable as we'd like, the benchmarks of the
native threads on NetBSD are pretty damn impressive. I'd say that not
using the native threads would be a tremendous waste...
--
Perry E. Metzger[EMAIL PROTECTED]
[EMAIL PROTECTED] writes:
> Is this in a released NetBSD, or is it just in CVS?
Released since 1.5.
Perry
--
Perry E. Metzger[EMAIL PROTECTED]
--
NetBSD Development, Support & CDs. http://www.wasabisystems.com/
sn't
self documenting when you don't need arbitrary magic.
We can, however, pretty straightforwardly simulate most of this stuff
with scripts for purposes of Debian packages.
Perry
--
Perry E. Metzger[EMAIL PROTECTED]
--
NetBSD Development, Support & CDs. http://www.wasabisystems.com/
be installed. if this works it could be ported to linux and after that
> the additional functionality of netbsd rc (dependencies) could be
> introduced.
I don't understand how update-rc.d works, but if someone points me at
man pages and the code I could have a look...
Perry
--
database for an hour
once a week for various purposes, so far as we could tell cron jobs
that simply told the database to change state and such would have done
just as well. We therefore went with a "traditional" system without
System V style explicit runlevels.
--
Perry E. Metzger[EMAIL PROTECTED]
--
NetBSD Development, Support & CDs. http://www.wasabisystems.com/
o the "right" solution rather than always the "most
compatible" solution, which is not always the popular move.
We may not be able to all use the same solution in the end, but do
have a quick look at how ours works. Maybe we can get most of what you
want without having to get a new init working.
--
Perry E. Metzger[EMAIL PROTECTED]
--
NetBSD Development, Support & CDs. http://www.wasabisystems.com/
e run levels although they very often claim
to want them.
Perry
--
Perry E. Metzger[EMAIL PROTECTED]
--
NetBSD Development, Support & CDs. http://www.wasabisystems.com/
that you'd be better off making a list of missing
functions and asking Matt and myself to get them integrated into
NetBSD's libc. It should be straightforward to do that.
Perry
--
Perry E. Metzger[EMAIL PROTECTED]
--
NetBSD Development, Support & CDs. http://www.wasabisystems.com/
distinguishing "third party" apps from our
own apps. /usr/pkg is somewhat convenient for that. It may not be what
we do "someday" but for now it is a useful convention.
--
Perry E. Metzger[EMAIL PROTECTED]
--
NetBSD Development, Support & CDs. http://www.wasabisystems.com/
stem" packages. At the moment, we have a base system and we have
packages of third party stuff added on top of that.
--
Perry E. Metzger[EMAIL PROTECTED]
--
NetBSD Development, Support & CDs. http://www.wasabisystems.com/
d techniques would make it fairly straightforward
to make both a FHS and a NetBSD style file layout possible without
large amounts of pain. They aren't very different.
I have to learn more about how Debian package tools work -- I'd
appreciate more links to useful reading...
NetBSD
side. Diplomacy is going to be very difficult here, and people are
going to have to restrain their impulses to beat "the other" to death
for not fully agreeing with them at all times.
--
Perry E. Metzger[EMAIL PROTECTED]
--
NetBSD Development, Support & CDs. http://www.wasabisystems.com/
t;
> I don't see why, debian has accepted RPM packages for years. Alien
> + RPM is all that is required for LSB compat.
--
Perry E. Metzger[EMAIL PROTECTED]
--
NetBSD Development, Support & CDs. http://www.wasabisystems.com/
y interested in replacing our init with
someone else's init.
Perry
--
Perry E. Metzger[EMAIL PROTECTED]
--
NetBSD Development, Support & CDs. http://www.wasabisystems.com/
d. It might
be worth discussing.
Perry
Speaking purely for myself and in no way as part of the NetBSD Project.
--
Perry E. Metzger[EMAIL PROTECTED]
--
NetBSD Development, Support & CDs. http://www.wasabisystems.com/
(project goals, etc.)
Could anyone brief me? Is there a FAQ or anything?
--
Perry E. Metzger[EMAIL PROTECTED]
--
NetBSD Development, Support & CDs. http://www.wasabisystems.com/
28 matches
Mail list logo
