Slashdot Mirror
First NetBSD Bugathon a Success
Daniel de Kok writes "Last weekend the first NetBSD Bugathon weekend was organized by Elad Efrat to handle as many open PRs (problem reports) as possible in a weekend, checking and fixing the bugs that were reported. Although the first Bugathon was not announced widely, it was a success: about 30 developers and 20 users closed around 270 PRs, bringing the number of open PRs down from 4200 to less than 4000.
The next Bugathon will take place on 7-8 October, and NetBSD users and developers are invited to help fixing bugs and handling PRs."
Every time there's a NetBSD article on Slashdot, up pops a message about it not working on the Vax. I'm beginning to suspect it's the same individual, as the message is always worded in a very similar way - as a none too subtle attack on NetBSD's cross platform capabilities. Just for the record my Vax, SGI Indy, SparcStation 5 and Dell laptop are all running NetBSD 3.0.1, the most recent release. The Vax previously ran 2.1, 2.0, 1.6.2, and 1.5.3 without problems. Around the time of 2.0 I was actually running it on three different Vax machines (3100 m76, 3100 m80 and 4000 VLC). Never had a single problem installing from CD or running NetBSD.
Now, getting NetBSD running on the last generation of Apple's 12" Powerbook (model 6,8) is a different matter - but I've been unable to get OpenBSD or YellowDog Linux installed on it either ...
A fair number of those are bugs for other OSes, due to having pkgsrc issues included in the same bug database. pkgsrc runs on a dozen different platforms so the bug database ends up with a lot of issues not directly relevant to NetBSD. Right now, there are 1233 open bugs relating to pkgsrc, many of which are non-NetBSD issues.
As for the classification of other bugs, you can check out http://www.netbsd.org/Gnats/ for a table of how those are distributed. Quite a few are specific to just a single port.
There are two architectures which have compiler issues not present on other NetBSD platforms, vax and pc532. In both cases support is fading away in more recent gcc versions, and they continue to be built using gcc 2.9.5 rather than the gcc 4.1.2 used by the rest of the NetBSD platforms (there are a couple of platforms still finishing testing for the transition from 3.3.3 to 4.1.2).
:)
This means all constructs in MI areas of the kernel (and the entire userland) need to keep compatible with gcc 2.9.5 and cannot take full advantage of newer C syntax and features.
So those working on the vax port tend to have to spend a reasonable amount of their time just making sure everything still builds, which reduces their time available for adding features and fixing PRs.
Its unfortunate, but the alternative would be to have the vast majority of NetBSD platforms stuck on an older compiler, which would hardly be very progressive
Having said that the VAX port is run and developed actively by some people, so its most likely the install tools and some models which have issues.
So, yes, VAX (and pc532) are at a disadvantage to the other ports, but they are still far from dead, and I would suggest tuning into the next bugathon to push your pet PRs...
NetBSD's driver organization is cleaner, not the code. This allows it to be ported to other arches easier. But OpenBSD's setup is almost the same (it did come from NetBSD originally after all), and is quite easy to port to other arches too. Linux and FreeBSD both show their 386-only roots in the rather poor organization and structure of drivers and hardware layers. Which is why you tend not to be able to run alot of off the shelf PCI hardware on sparc64 or alpha with those kernels, even though you can with Net or Open. Linux even re-impliments the same stuff over and over again in different drivers, like parts of the SCSI layer or especially 802.11