[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
re: Path to kmods
That's true but the project moves towards a 'new features, we groom 'em
and old features we drop 'em without proper discussion first' position;
exactly how? what are you talking about? SA? as much as i
argued for SA syscalls being put back, you're ignoring the work
done to make netbsd-4 binaries work on netbsd-5 systems without
these syscalls being present. oh yeah, and the syscalls are
there now, so what exactly is the problem?
I therefore can see what dM is saying, why, and I fear, too, that this
is going to happen. By the latest developments you can see that we already
stopped caring about backwards compatibility, from the programmers, the
system administrators, the packagers and the users view. So what makes you
again, what do you mean? please give real examples where these
things have happened where backwards compat was not provided
for featurse you care about _on purpose_.
think that the "hard to groom because 'nobody' uses it" features will
get fixed? Who is/was fixing the SA bugs? "It's ugly let's drop it". Who
will notice when a non modular generic is broken? "Everybody should be using
modules anyways. It's much leaner!" Who notices if XFree gets broken?
"Use X.Org". Who fixes softdeps? "It is going to be dropped and replaced
by WAPBL". Who fixes interop issues on systems that do not want IPv6 ?
"Better get to like IPv6. ENOPATCH. We don't care about IPv4 only systems".
You can just add "Who cares about static linking" to the list.
again, what are you talking about?
lets go through these one by one:
SA - it was removed for a time between releases while we
switched to a new kernel threading and it was put back
before netbsd-5 branch. and SA isn't really relevant to
this. SA was a back-end for pthreads. as long as the
pthread apps continue to work, that's what matters. this
point is even more misguided -- we (and by 'we' here, i
mean andrew doran) worked quite hard to make pthread-using
apps work on a netbsd-5 system.
"non modular" - modular code is *the same code* as the non
modular case. this is a huge step *forwards* compared to
the old lkm framework. it is now easier to obtain this
goal than before.
xfree? who cares? you want xfree to work? you go work
on updating it for netbsd. xfree86 project is not the
direction netbsd is taking for our up-stream X provider,
just like we switched from the XC tarballs to XF86 some
years ago. xorg is the new direction and we're working
*very* hard on it, and making it work with all our old
softdep? it's never been generally considered useable
by a large portion of the netbsd community, and has not
had a maintainer in netbsd for years. want to try?
please send patches.
ipv4-only systems? i build them every time i build a
non-GENERIC-style kernel. sounds like you had a bug that
only occured in this case? are you going to claim that
every bug introduced means that someone else doesn't
care about your feature?
static linking? there has never been a serious proposal
to remove this from netbsd. even the rejected proposal
from thorpej was not about removing static linking, and
was explicit about leaving that support, but about not
shipping .a libraries any more _by default_. it in no
way was going to remove any support for using or building
in other words, you, like mouse, are just spreading FUD.
please stop it.
if you want to help these features, and more, from breaking,
then you should be testing these features. claiming that we
don't care about backwards compat is ignoring the massive
amount of work that all the netbsd developers who have worked
on that have done. thanks!
Main Index |
Thread Index |