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

Dominic Fandrey wrote:
Hello,

I'm writing this mail on behalf of the largest German BSD community
(http://bsdforen.de/). Some of our most respected and experienced community
members have stopped using FreeBSD entirely, especially professional users
have taken this step.

Many of us are very attached to FreeBSD and those of us who turn our backs to
the system consider this a personal loss.

This mail is the result of a forum thread that consists of more than 200 posts
(still growing) that started in October 2007
(http://www.bsdforen.de/showthread.php?t=19426). It is meant to sum up the
causes of this development, the reasons we see for this and what we think
might be promising ways to try solve these problems; at least in the areas we
were able to achieve consent.

The first problem is the unbearable performance many AMD users are suffering
for several chipset and CPU generations. Even minimal I/O load on a hard disk
suffices to lock up whole systems. Posts on the mailinglists current and
stable have often been answered with denial or have simply been ignored. Only
on very rare occasions (if at all) have these problems been taken seriously.

The second big problem is the handling of regressions. PRs remain unanswered
or the reporters are told that the regressions they report do not exist. Some
of our members have even suffered the experience that they developed a patch,
but it simply was ignored or turned down for the reason that it was a "Linux
solution". Especially frustrating for those among us who have never looked at
Linux code.

These problems seem to be exceptions, but they are very persistent exceptions.
Problems concerning code that is currently being worked on are shown much
attention, feedback and patches are happily taken and the developers supply
the problem reporter with steps to take in order to track down these problems.

The problem seems, in our opinion, to reside with unmaintained code. It seems
that nobody wants to take responsibility for code that has been untouched for
a longer period of time. This is quite understandable, considering that
developers already have projects they're working on and probably consider much
more important, but that does not make it less of a problem.

What we think might be a solution to the regression problem, would be the
establishing of a Regressions Team, similar to other teams like the Security
Team. The sole purpose of this team would be to take care of regressions that
concern unmaintained code.

To solve the performance problems it appears to us, that a guide to tracking
performance problems or a performance test suite is required. This would
hopefully allow us to write PRs and emails that would be taken more seriously.

- Dominic Fandrey on behalf of BSDForen.de community

Thanks for the feedback. It is hard to respond to the reports of poor performance or other problems without specific information though.

I know from my own experience trying to investigate some of these performance issues that come up from time to time, that it is often very hard to get submitters to report sufficient information to understand a problem, even when they are pointed at documentation explaining the required steps in detail. However, we are in the process of introducing changes to the debugging tools to make this process easier; textdumps and DDB scripting will allow the most common debugging data to be collected in a more automated manner, reducing the need for user interaction.

Another factor is that many of these issues are hardware dependent, and unless developers have access to the exact model and configuration of hardware (and/or the relevant hardware datasheets and errata) they are often impossible to replicate or understand.

That being said, I do think we could do more to identify and track regressions as they occur, so this is definitely something we should think about in more depth. More importantly, members of the community are encouraged to come forward and help out with the task of maintaining older code. As you say, this often becomes neglected simply because there are never enough developers to go around.

Best wishes,
Kris
_______________________________________________
freebsd-current@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • FreeBSDs problems as seen by the BSDForen.de community
    ... I'm writing this mail on behalf of the largest German BSD community ... The second big problem is the handling of regressions. ... developers already have projects they're working on and probably consider much ... To solve the performance problems it appears to us, ...
    (freebsd-current)
  • Re: new daylight savings time
    ... I kind of like the vibrancy of the Ubuntu community: ... Developers and testers are *part* of an eco-system which is ultimately ... What good would it do anyone to have a bug report for FC4 coming in now ... any particular distribution or version, they just keep fixing and adding ...
    (Fedora)
  • Re: What am I looking for?
    ... one access database going round. ... is that only 4 days ago I have started work on a community website ... How does Scout Management Stop us from having to re-invent the wheel? ... Community of developers and testers ...
    (uk.rec.scouting)
  • Re: What am I looking for?
    ... one access database going round. ... is that only 4 days ago I have started work on a community website ... How does Scout Management Stop us from having to re-invent the wheel? ... Community of developers and testers ...
    (uk.rec.scouting)
  • Re: FreeBSDs problems as seen by the BSDForen.de community
    ... I'm writing this mail on behalf of the largest German BSD community ... The second big problem is the handling of regressions. ... or the reporters are told that the regressions they report do not exist. ... of our members have even suffered the experience that they developed a patch, ...
    (freebsd-current)