Re: FreeBSD's problems as seen by the BSDForen.de community

Note:  Reply-To set to chat_at_.

Timo Schoeler wrote:
 > Oliver Fromme wrote:
 > > I think the real answer is:  You cannot prevent anyone
 > > from writing a piece of software, no matter how useless
 > > or ridiculous it might be for the majority of users.
 > 
 > I don't want to do this, either. Sorry, my argumentation on this was
 > not clear enough...
 > 
 > >  If
 > > there's someone who wants to write a driver for a USB
 > > christmas tree or for a bluetooth canned laughter device
 > >  -- he will do it, and you can't keep him from doing it.
 > 
 > So above, (s)he shall be happy doing so.
 > 
 > > It will even go into the CVS tree (though probably not
 > > into GENERIC) if the source is clean, style(9)-compliant
 > > and well maintained.
 > 
 > It should do with *one* exception: Every other, more important problem
 > (e.g. getting ZFS to v9) is *solved*.

No.  You cannot force a _volunteer_ to work on anything
other than the issue he wants to work on.  That's why he
is a volunteer.  FreeBSD is mostly a project of volunteers,
only a few of the developers are paid for what they're
doing.

 > > But even if it doesn't go into the
 > > tree, that's not a big deal.  For example, for several
 > > years I maintained some patches that improved syscons
 > > (kern/15436).  They didn't go into CVS, but they worked
 > > fine for me and a few others.
 > 
 > But I bet you would be fine with it in the tree

Certainly, but as I wrote, it's not a big deal.  I have
several other patches that I maintain on my own for
various reasons.  For example I have a local patch set
that enables "-c none" in ssh, so I can scp large files
much faster between slow machines over channels that don't
need encryption, and still be able to use ssh's features.
I don't even try to submit the patch to the OpenSSH people,
because they would reject it.  I considered submitting it
as a local patch to the FreeBSD base, but I think it would
be rejected too, reason: "please submit it upstream to the
OpenSSH people".  :-)

 > If so, why didn't it get into the tree?

There are various reasons why patches don't hit the tree.
Some have already been mentioned by Peter Schuller and
others.

In the particular case that I mentioned, the maintainer
of syscons was in the process of completely restructuring
the code anyway, so any other patches had to wait.  Later
I forgot about the whole thing because I had more important
things to do.  If I insisted at that time and submitted
follow-ups to the PR with updated patches, it might really
have been comitted.

 > Maybe because some lower-priority USB christmas device
 > driver was imported instead?

Priority depends on the point of view.  Different people
have different priorities.  There are people for whom ZFS
is top priority.  Other people's top priority might be
improvements on zero-copy sockets or TCP scaling.  And
yet others might have hot-plug-PCI support on top of their
list because it's crucial for their jobs.  There might as
well be people whose top-priority is the USB xmas tree
driver.  Why not?

 > OpenBSD gets this straight very well (and no, I'm no longer a fanboy of
 > OpenBSD, if interested why, send me a PM). They put emphasis on
 > security, and they get this job done very very well.

OpenBSD doesn't force volunteers to work on things that
they don't want to work on.  It wouldn't work.

 > > You can't tell people how to waste their resources in their
 > > free time.  They waste it on whatever they want, no matter
 > > what the FreeBSD project tells them, no matter if there's
 > > a strong leader or not.
 > 
 > They can waste their own time, but they shouldn't waste others.

How is writing a USB xmas tree driver wasting others'
time?  Well, if you submit it, another developer (maybe
a comitter) will need some time to look at it, but again,
that's voluntary.  No volunteer is forced to look at it.

In fact it might _save_ others' time who would otherwise
have to start writing such a driver themselves.

 > > > The problem is, that when people start to migrate *away* from
 > > > FreeBSD (like was stated in bsdforen.de, where some guy's company
 > > > could no longer justify to recommend FreeBSD to their customers,
 > > > because they had way too many problems with it), then a chain
 > > > reaction is started.
 > > 
 > > Actually I think that bsdforen.de issue is overrated
 > > (I don't even think bsdforen.de is the largest German BSD
 > > community, but that's a different story).
 > 
 > Pride goes before a fall.

Exactly.

 > Even in case it's the second biggest forum, it shouldn't be ignored;

I agree completely, it shouldn't be ignored.  (Whether it's
the first, second or third biggest forum doesn't matter at
all; it can't be easily measured anyway.)

Basically there are two problems here, the first being sub-
optimal bug reports (e.g. missing details, problems with
communication), and the second being a lack of committer
manpower.  Some pople have suggested ways to solve or at
least alleviate the latter.

Best regards
Oliver

PS:  Reply-To set to chat_at_.

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

"If you aim the gun at your foot and pull the trigger, it's
UNIX's job to ensure reliable delivery of the bullet to
where you aimed the gun (in this case, Mr. Foot)."
        -- Terry Lambert, FreeBSD-hackers mailing list.