Re: The future of NetBSD

2006-09-05 Thread Andreas Klemm
On Fri, Sep 01, 2006 at 11:59:57AM +0200, Gilbert Fernandes wrote:
 I have a dream.
 
 A dream of unification.
 
 Having one BSD. Merging the three projects and, why not, keeping
 incompatible stuff as options that would be either one or another.
 
 But when you tell yourself that it cannot be done, you don't even
 try it.
 
 It would require people to not only do it for the sake of their projects,
 but for the whole BSD people. Even those who really piss you off in
 other projects.
 
 Because someday, those projects will live on without us. We'll pass on
 like everyone.
 
 Am I alone thinking this ?

Sure would be kind of nice, but in practice its nearly like saying,
I want that the world gets one car. Please unify Mercedes, BMW,
Ferrari, VW and all of their models ;-)
With design goal: Modularize car in a way, that the different
customer demands can be achieved as options.

You'll get problems in many ways ...
- too many different - partly contradictory - design goals.
  One car is more a racing car, the other tries to be kind to
  mother nature
- too different customers demands
- different company cultures ...
- many leaders that have to give up their own goals and synchronize
  with each other
- say good-bye to own companies history and habits and be open
  to be only part of a new team

For a volunteer project it sounds nearly impossible to synchronize
all the different people with different goals and culture to the
project targets _and_ be productive and write good code !

If the situation of NetBSD is the way like Charles Hannum describes
- I'm no insider therefore I formulate it carefully this way -
then a possible way could be a fork of NetBSD.

But does the world really needs one more BSD ?
Maybe the discussion itself is useful for making a cut and
trying to reorganize the team by avoiding all that turns out
to be a misconception.

If this is not possible and people are convinced a fork
with a strong leader would bring more merits and productivity,
then a fork still could be done later.

A fork off alone from NetBSD by keeping all the CPU and architecture
support might be very tricky and difficult.

Its questionable if one person is able to draw good design
decisions that are well for all different NetBSD ports (here
I mean the different architectures).

Maybe a fork would need to specialize on one or some CPU types
that a small team is able to handle.

Andreas ///

-- 
Andreas Klemm - Powered by FreeBSD 6
Need a magic printfilter today ? - http://www.apsfilter.org/



Re: The future of NetBSD

2006-09-05 Thread Andreas Klemm
On Thu, Aug 31, 2006 at 06:50:00PM -0300, Marc G. Fournier wrote:
 On Thu, 31 Aug 2006, Constantine A. Murenin wrote:
 
 On 31/08/06, Marc G. Fournier [EMAIL PROTECTED] wrote:
 
 Just a stupid comment, but ... Linux is one kernel, multiple distributions
 ... BSD is, what, 4 kernels now?  If we worked more together instead of as
 seperate camps, it might make things a bit easier, no?
 
 Isn't there still fewer differences between *BSD operating systems
 than between different GNU/Linux distributions and kernel releases? :)
 
 Put together a *BSD core ... representative from each camp and try and
 steer the *kernel* itself towards a more common BSD ...
 
 I doubt that'll be productive -- NetBSD, FreeBSD and OpenBSD have all
 different goals...
 
 Even at the kernel level?  Look at device drivers and vendors as one 
 example ... companies like adaptec have to write *one* device driver, for, 
 what, 50+ distributions of linux ... for us, they need to write one for 
 FreeBSD, one for NetBSD, one for OpenBSD, and *now* one for DragonflyBSD 
 ... if we had *at least* a common API for that sort of stuff, it might be 
 asier to get support at the vendor level, no?

Are you really sure ? I see it more this way: For Linux on kernel
(or device driver) level they only have to support 2 main trains:
2.4.x and 2.6.x.

The 50 distributions are only a burden if it comes to the point
what different shared library / Java / TCL / etc ... versions
are packaged with the OS.

A friend of mine doing Java development had severe issues with
all that different Linux versions.

But a simple kernel driver only has to honour different CPU types
and the 2.4 and 2.6 tree and maybe now a development tree but
am not sure on the latter ...

Andreas ///

-- 
Andreas Klemm - Powered by FreeBSD 6
Need a magic printfilter today ? - http://www.apsfilter.org/



Re: The future of NetBSD

2006-09-05 Thread Andreas Klemm
On Thu, Aug 31, 2006 at 08:14:31PM -0300, Marc G. Fournier wrote:
 On Thu, 31 Aug 2006, Miod Vallat wrote:
 
 If the vendor is supporting the driver, and working with the community,
 then one would hope that they would also fix the driver as bug reports
 come in about it ...
 
 That's too many ifs to be realworld-compatible.
 
 And actually the only vendors I can think of which are working with the
 community actually provide documentation, if only because it is simpler
 for them to spend time on documentation than on code for N different
 systems.
 
 ICP Vortex (aka Adaptec) were providing drivers on their web site for 
 FreeBSD 4.x and 5.x that are included in both source trees ... it was a 
 binary driver, as far as I'm aware, but source code ... and Adaptec 
 doesn't provide documentation ...

I don't think that binary only drivers are well enough.
Surely better than nothing but ...

Don't forget that an open source team sometimes makes api changes
that might break a binary only driver. And companies sometimes
are slow in fixing.

Or the vendor did some mistakes in his own driver.
First the paying customers are served. All the other folks
(open source ..) surely will come last.

For some smaller corps supporting open source developers is
simply a burden that costs time and so money.

I know this from a medium sized german company producing nice
audio recording cards.

It was impossible to get a card and documentation from them for
a FreeBSD developers. And after weeks and months of asking via
e-mail they decided finally to tell the truth that they don't
want to support open source developers anymore, it makes too much
work. They are unable to spend so much time answering open source
developers questions although they got documentation. This experience
they made with Linux developers.

Andreas ///

-- 
Andreas Klemm - Powered by FreeBSD 6
Need a magic printfilter today ? - http://www.apsfilter.org/