BSD devcenter at onlamp.com has an interview with Charles M. Hannum, one of the creators of the NetBSD Project and the NetBSD Foundation, about the evolution of the project, funds management, problems with licenses and hardware documentation, the link with vendors, past and current mistakes, and what we can learn from the Linux development process.
Confessions of a Recovering NetBSD Zealot
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Him to just come out and say, “Alright everyone, we’re forking, FarBSD is my new project,” or, “Okey, everyone start sending your patches to OpenBSD, so that NetBSD is entirely the puppet of Wasabi, because only they use it.”
He comes close but doesn’t say join X, or we’re forking and calling it Y. While it would be great if he’d try and get those developers not comfortable with Wasabi’s influence on the project to move elsewhere, seems he’s just venting about how he isn’t in control anymore.
i’m really interested in helping out. I know C but don’t know anything about kernels. Is there a good place I can start learning about kerenels and the various parts of them? I’ve been using netbsd for a while not daily but I manage to keep a embedded system up for when I’m bored.
I don’t have any links for kernel documentation at the moment, but why is it always assumed that working on a project envolves kernel grubbing? It is an entire OS, so maybe you could grab onto something a bit easier to start out on.
There is a nice list of project available at:
http://www.netbsd.org/contrib/projects.html
Some tasks are fairly easy, and can be a good starting point for more complex projects. For instance, some of the GNOME-related items will be easy to start with.
As a more general remark: there seems to be a lot of commotion about the NetBSD project. But remember that the stir on the mailinglist is caused by discontent of just one developer. There are over 300 developers, there would be a hell lote more of people complaining, if the project is a train wreck.
If you like NetBSD, and feel there is stagnancy, you can help out by picking one of the items from the todo list, or just test releases, send PRs, and help other people.
thanks maybe i should start on those kinds of problems. the gnome ones look easy enough.
Charles M. Hannum: Well, look at the current situation. If you look at just the major options in the Linux community, you have apt, rpm+up2date and rpm+yast. They have all converged on pretty much the same feature set, but they have different UIs, and the packages themselves are maintained by completely different communities (with their own versioning, patches, and selected options). There’s no good reason that they need to have different underlying formats (.deb versus .rpm), but they do.
He raises an interesting point about Linux package management. If .rpm and .deb really do track the same information, might it be possible to construct a package manager that could use both package repositories? I mean, not now (the Alien tool has enough problems with slightly different library versions, slightly different compile-options…) but in the future if the Linux Standard Base/Freedesktop standards take off and less distro-specific patches are needed?
http://labix.org/smart
SmartPM has nothing to do with what is being discussed. Go pimp your package management system elsewhere.
It’s about package formats, and I totally agree that there need only be one. Personally my choice happens to be the same as the LSB. Now if everyone else would stop making .deb packages everything would be perfect.
* Before you mod trolls whip out your mice and get ready to mod me to hell, please understand this post was written with so much tongue-in-cheek my mouth is a bit sore.
I did not pimp “my” package manager, I do not use it. I think that once we have easy way of dealing with both RPM and DEBs Linux community will agree on one standard as it will be easier to migrate.
Right now judging by top10 distrowatch stats deb to rpm ratio is about 6:5. LSB is just unreal since it was proposed by commercial Linux vendors who in majority produce Red Hat derivatives and inherited RPM package manager.
I’m not entirely sure what he thinks having a common format would fix. Even if everybody did migrate to one system, it’s still not going to make it any easier to use packages built for other distros. Nor should it.
It’s not the package formats but what they have inside and how they connect together.
Could they be a common base repository? I would have said yes until I saw what Novell did with Xen. The problem is that there CAN’T be a common base repository. It limits the ability for a distro to innovate. Who has say over how the repository is constructed, what goes in etc? What if RedHat introduces a package that works great for them, but breaks some feature in SLED?
deb vs rpm doesn’t really matter, it’s the repository that matters.
Gentoo’s Portage is the solution!!!!
🙂
That’s not a solution but a nightmare
mod up!!
Gentoo’s Portage is the solution!!!!
A silly comment like this, (without explanation why, just a pure zealotry), as long as about linux and its derivatives, is always modded up to the max. How come a rip-off of BSD port is the solution for BSD?
Edited 2006-09-17 10:16
I’m not a zealot; I’m using NetBSD and I’ve installed it from the scratch using pkgsrc, but simply I found Portage more intuitive for the end user.
pkgsrc, FreeBSD Ports and OpenBSD Port collection are the same woman with dresses of different colors!
Portage is largely based in the same idea but it’s more intuitive, easy to use and better documented that pkgsrc. I found doing an update easier than update a package using pkgsrc.
Portage is again the same woman, but with a nicer dress.
The smiley indicates sarcasm.
If *BSD flavours want to improve their package management (or perhaps create a new package manager that is shared between all BSDs), they should check out how Source Mage GNU/Linux and Lunar Linux do it. These source based distros have a menu driven package manager (written in bash) that you can use to install/remove/upgrade your applications and you can also configure every aspect of the package manager (optimizations etc.) from the same menu. Before installing any new packages it asks you some questions about the optional dependencies that you might want to include and it also offers you the chance to view and edit the makefile if you want to. Now, that’s what I call easy and intuitive package management — no need to read any man pages before you’re ready to go.
I’ve found Pkgsrc to be a reliable package manager but it’s not too intuitive. You need to read way too many man pages and edit too many config files before you can start to use it. You even need to list the licenses you want to accept in /etc/mk.conf. Of course, once you’ve set up Pkgsrc properly, things become easier. But I don’t understand why Pkgsrc insists on removing every package it wants to upgrade (plus their dependencies) before it starts building the new versions. With large upgrades this means that the system may become unusable for the time it takes to build the upgrades and this, IMO, is unacceptable.
Source Mage GNU/Linux and Lunar Linux do it. These source based distros have a menu driven package manager (written in bash) that you can use to install/remove/upgrade your applications and you can also configure every aspect of the package manager (optimizations etc.)
We already got DesktopBSD package manager and Kports. All functionality is here already. All distributions should use TBZ or PBI format and shut up about RPM.
IMHO
Charles M. Hannum: NetBSD today does a very poor job of setting and meeting standards. I created the mythos of NetBSD having “clean” code, and even I don’t buy it any more.
DragonFly BSD is an example of a very modern and innovating BSD: Matt Dillon forked from FreeBSD to create its own OS because the people inside FreeBSD did not want to apply his good ideas about a cleaner SMP support.
When there are a lot of problems managing a community and in this case, the software development (quality, innovation, high standards, passion, etc.) is not longer the main focus of the project, a fork should be a MUST.
DragonFly promises to be a very nice and scalable OS in a near future.
Why not following its example or joining it?
I for one would like to see a NetBSD fork. Can you imagine a BSD system that runs on just about every architecture with good driver support? That’ll be the day I switch from Linux.
I for one would like to see a NetBSD fork.
See OpenBSD.
Can you imagine a BSD system that runs on just about every architecture with good driver support?
See NetBSD and OpenBSD.
Actually, see NetBSD, OpenBSD AND FreeBSD
FreeBSD is neither a fork of NetBSD nor is it able to run on many platforms, so what have you been smoking?
“FreeBSD is neither a fork of NetBSD nor is it able to run on many platforms, so what have you been smoking?”
Sorry, I should have been more specific!
I replied specifically to the statement:
“Can you imagine a BSD system that runs on just about every architecture with good driver support?”
And the combination of NetBSD, OpenBSD and FreeBSD fill that very nicely
FreeBSD does run on several platforms:
http://www.freebsd.org/platforms/
* FreeBSD/alpha Project
* FreeBSD/amd64 Project
* FreeBSD/ARM Project
* FreeBSD/i386 Project
* FreeBSD/ia64 Project
* FreeBSD/MIPS Project
* FreeBSD/pc98 Project
* FreeBSD/ppc Project
* FreeBSD/sparc64 Project
* FreeBSD/xbox Project
BTW, I’ve been smoking BSDs since ~94
But of those, how many are worth using? They have their tier system in place for a reason – only I386, AMD64, and sparc64 are real platforms for FreeBSD, not to mention xbox being just another random i386 box.
Alpha development has completely stopped, there will be nothing in or beyond 7.0. mips, pretty much a dead platform, likely heading the same way considering FreeBSD’s reaction to Alpha’s ceasing support.
On the whole, FreeBSD supports three platforms with any real focus – I am suprised really that PC-98 is in that group considering FreeBSD’s position on outmoded platforms.
Sorry guy, but on *BSD it does hurt. It’s not like in linux, where forks usually just change packages inter integration or some options. On *BSD case, you must maintain/improve the kernel and the userland, what is a hell of work to do (there is, again usually, not a concern about that on linux).
I think we already have enough *BSD projects floating around (actually I think we should have less). Please, if you want to help, pick one you like at most.