The NetBSD Foundation published its second quarterly status report in 2005, covering the months April through June of 2005. Among many other things, this status report covers NetBSD’s participation in Google’s “Summer of Code”, the new stable pkgsrc branch and various port-specific items.
NetBSD Quarterly Status Report Published
About The Author
Adam Scheinberg
Technology Executive • Web Developer • Father • Foodie • Music Snob • OS enthusiast
Follow me on Mastodon @[email protected]
i can’t believe how quickly the BSD’s are changing their releases nowadays. Is their some surge in new features that is forcing them to branch new x.0’s so often?
NetBSD and FreeBSD use a versioning scheme where the major number shifts every time binary compatibility (ABI) is changed. OpenBSD just uses a twice-annual release scheme where the minor number is updated every time and hitting “10” causes a rollover — 2.8->2.9->3.0->3.1, etc.
In any case, it’s not a feature-centric numbering scheme (although NetBSD and FreeBSD tend not to break the ABI without good reason).
very impressed with netbsd – i would use it as a research base for new ideas. one idea that would be good is a mechanism to regsitering and obtaining kernel events for security audits and policy enforcement.
I think this fast jump comes as a side effect of the production model common across the BSDs. As soon as a new version is released as in, 2-release/2-stable, the most active development switches to the version bumped -current branch. In this case 3.0-current. That is what’s happening with Freebsd right now, 5.x introduced a lot of ground work which 6.0-current has taken to the next step.
I am not entirely familiar with netbsd’s development model, but at least on the surface it looks very familiar.
To me, NetBSD’s versioning system seems very clean and sane:
3.0 — Major new release. Big changes, updates, all over the map
2.1 — No drastic changes from 2.0 that alter the whole system; just new drivers and smaller features
2.0.2 — Purely bugfixes and security patches that don’t change the way the system behaves
This seems ideal. You can stick with 2.0 if you want absolute stability and just get bugs/holes sorted out. You can go to 2.1 if you want some new features and don’t mind tweaking a few things. And you can make the leap to 3.0 if you’re willing to work with many big changes to the whole system.
Certainly beats the nonsensical Linux distro versioning schemes, and redundant kernel numbers (how many sweeping changes in 2.6? Will it ever be TRULY stable?)
This may cause a shock:
karsten@uberhost:~> uname -a
NetBSD uberhost.newbie-net.de 3.0_BETA NetBSD 3.0_BETA (UBERHOST) #0: Sat Apr 30 03:22:44 CEST 2005 [email protected]:/mnt/data3/systems/netbsd/builds/NetBSD -3.0_BETA-x86-obj/sys/arch/i386/compile/UBERHOST i386
karsten@uberhost:~> uptime
8:15AM up 71 days, 11:50, 1 user, load averages: 0.08, 0.10, 0.08
karsten@uberhost:~>