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

Timo Schoeler timo.schoeler at riscworks.net
Fri Jan 11 05:01:41 PST 2008


Thus Oliver Fromme <olli at lurza.secnetix.de> spake on Fri, 11 Jan 2008
11:58:10 +0100 (CET):

> Timo Schoeler wrote:
>  > [...]
> 
> While I agree with many of your points, I need to write a
> small comment on this one:
> 
>  > FreeBSD is everywhere and nowhere at the same time. As was stated
>  > in bsdforen.de, I should run ultra stable on servers, as it *used
>  > to be*. It no longer is. Instead, there are drivers written for HD
>  > Audio... Is there something I missed? Logic or Cubase already
>  > ported to FreeBSD? No?
> 
> FreeBSD supported soundcards from day one, in the good old
> days of the 8bit SoundBlaster cards.

Sure, and that is absolutely not a problem (see below).

> Today, many computers (especially laptops) come with HD
> audio hardware that works only in HD mode.  It requires
> an HD audio driver to do anything more than a square wave
> beep.  Without the HD audio driver, I wouldn't be able
> to play any sound on most of my newer computers, which
> is why I am very grateful to the people (Ariff and others)
> who worked on that driver.  I certainly would not want to
> switch to a different OS just because of sound support.

Okay, that shows me that I (and some guys on bsdforen.de, too) chose a
bad example. I thought that almost any sound device on PeeCees can be
addressed like almost every graphics board can be addressed via VESA.

As this is not the case, it's perfectly alright to write a driver for
it (what I never questioned, btw!), *and* to take it into the
repository.

>  > So why waste resources and write this driver? 'Because one can.'
> 
> 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*. If this is the case, import the
USB christmas tree device driver and introduce dev.xmastree.lamps.blink
as sysctl, absolutely no problem.

> 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 as well as some others,
if not all others? If so, why didn't it get into the tree? Maybe
because some lower-priority USB christmas device driver was imported
instead?

This is the crucial point I wanted to show: *Priorities*.

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.

> 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. Wasting
time of others (or FreeBSD developers, the core team, system
administrators that have to deal with problems that arise because of
that, users in trouble, etc) can be prevented when paying attention to
priorities defined and introduced before...

> Of course, things are a little different when certain
> pieces of software are sponsored (like the TrustedBSD
> stuff), or when they are done for other purposes than
> for pure fun, e.g. as part of a students project.
> That's how things like IPFW and DUMMYNET came to life,
> IIRC.
> 
>  > 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.

Even in case it's the second biggest forum, it shouldn't be ignored;
furthermore, some guys (if I filtered this license crap correctly) see
the points made quite similar.

> It's true that
> there are certainly problems, as the OP explained in his
> initial posting.  Those problems do exist; I've been a
> victim of one or another myself.  But I don't think that
> significant amounts of FreeBSD people are now running away
> from it.  Especially long-time FreeBSD people should know
> better than to run away.

It's the same here: I test other OSs (as well as Linux distros) on a
quite regular basis, and I'm very happy being back in BSD land. It just
works. But I want that it stays this way ;)

> Everybody who's been following
> FreeBSD seriously for a few years or more should know how
> to produce _good_ bug reports and get them to the attention
> of developers, especially when they're critical and affect
> many people.  Several of the PRs submitted by myself are
> still open and idle, but those are simply not critical
> enough to waste time hunting developers.  All of my PRs
> that I regard as critical have been taken care of.

That's cool. I hope the automated reporting that was discussed and
implemented will show further progress in getting things done better.

> Personally I've always looked in the directions of other
> OS projects (Linux, NetBSD, OpenBSD, and recently Dragon-
> Fly), and even tried them out sometimes on spare machines
> or just within qemu.  None of them convinced me enough to
> replace FreeBSD for production use, though, for various
> reasons.  In fact there were instances when certain pieces
> of hardware were reliably supported by FreeBSD, but not
> at all by Linux.  (I should tell those stories on chat at .)

That doesn't surprise me (and yes, please tell those stories, I'm
curious).

> Well, to get at least a little bit on-topic here, let me
> say that I think that -current seems to be in a very good
> state today.

Though running 7 here, I'll try it ASAP (as soon as I have today's
backup save).

> I've been mostly following the -stable
> branches on the machines I'm responsible for, but I also
> give -current a try every now and then, just to get a feel
> for what's happening at the "bleeding edge".

I've been on NetBSD-current for quite some years, and it was sometimes
quite hard when not on x86/amd64 (was on macppc).

Doesn't matter at all, however ;)

> Best regards
> Oliver
> 
> -- 
> Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing

Best regards,

Timo


More information about the freebsd-current mailing list