|Milscvaer||Aug 12, 2005 3:16 pm|
|Greg Barniskis||Aug 12, 2005 4:04 pm|
|dpk||Aug 12, 2005 5:07 pm|
|Milscvaer||Aug 12, 2005 8:22 pm|
|al...@scii.nl||Aug 12, 2005 8:35 pm|
|Milscvaer||Aug 12, 2005 8:55 pm|
|Milscvaer||Aug 12, 2005 10:13 pm|
|Milscvaer||Aug 14, 2005 2:37 pm|
|Gary W. Swearingen||Aug 14, 2005 3:50 pm|
|Milscvaer||Aug 14, 2005 6:19 pm|
|Milscvaer||Aug 14, 2005 6:21 pm|
|Milscvaer||Aug 15, 2005 2:22 am|
|Milscvaer||Aug 15, 2005 3:30 am|
|Gary W. Swearingen||Aug 15, 2005 3:34 pm|
|Subject:||Failed installation of FreeBSD 5.4|
|Date:||Aug 12, 2005 5:07:37 pm|
On Fri, 12 Aug 2005, Greg Barniskis wrote:
It can be argued (and has been, a lot) whether the hardware problems that some folks clearly do have are the fault of the hardware or of the new FreeBSD architecture. Myself, I think it's probably a little of each. Even though the hardware in question often "works fine" with other operating systems, that's not in my view conclusive evidence that the new FreeBSD code is bad. Make up your own mind, by all means, but jumping to conclusions is rarely going to help you actually resolve a problem.
I believe it's a little bit of each as well -- however, there have always been hardware problems, and sometimes they just need to be hammered at with software until they work.
There are some issues with modern hardware that some (including myself) should have come up during testing (crashes w/ PAE, kernel dumps don't,
2GB filesystem/drive problems, sysinstall bugs). I suspect that
part of the problem is that this hardware may not be immediately available to the FreeBSD developers, so they might be "flying blind". I've been trying to collect information as I see the issues, and opening PRs, but if you go over the PR list you'll see some open issues for years. I'm not sure if the issues will be handled, or if they have been and the tickets just haven't been closed.
Unfortunately I'm not currently in a position to offer hardware loans to developers so they can work out the kinks. I'm hoping that will change (especially for large RAID support) but it's not directly in my hands.
With the solid FreeBSD 4.x relegated to "legacy" status, we've been forced to use FreeBSD 5.x on some servers at customers requests, with very mixed success. 5.4 seems relatively OK, so far, but earlier releases have some "random crash" issues on hardware that has appeared stable in the past.
When the latest "legacy" 4.x release version has a EOL that is further off than the latest "best" 5.x release, and with developers moving on to 6.0 and 7.0, it's hard to stay motivated, as a user, to continue to submit bugs for "older" releases (older as in not even a year old). I can and will continue to submit bugs as I see them, but as I'm working with production systems, I can't just "upgrade the entire OS to the latest version", if that's the answer, which it often is.
This may sound bitchy, but at the time of this email there are 4920 non-closed PRs for FreeBSD. It'd be great if these could be handled before or at the same time as developers move on to the "bigger, better" code. I know the answer here is that it's an open system, and if I think it should be done, I should do it -- unfortunately I do not have the skill set necessary to fix these bugs.
If there is a way I could help out, I would. The FreeBSD Foundation activity list doesn't include fixing old bugs -- http://www.freebsdfoundation.org/activities.shtml . Their goal appears to be adding features, which is understandable; it's way sexier than bug fixing, in any case. Is there another organization I could donate money to (and perhaps even time, if possible), that would be working towards making FreeBSD a stable platform on modern hardware?
I realize this email may turn people against me and my bug reports (if I'm even important enough to remember, heh!) for being so bitchy. It's been on my mind for a while, mainly because I still feel FreeBSD provides the best platform for web services (at least the type I work with). I'd just prefer that open PRs take priority over new features.