

I installed OpenBSD 4.4 on my two year old HP Pavilion dv2037 notebook right after the CD set arrived. Although I did not test the webcam (I really have no use for them), everything else worked out of the box, including the built-in Intel WiFi, which had been problematic on the OpenBSD 4.3 release just six months before.
I let it "burn-in" for a few days with the standard kernel, then switched over to the MP kernel. Everything still worked. All in all, I've been quite happy with this release of OpenBSD, and it just keeps getting better.
I'm quite surprised at how immature the system seems, judging from the interview: until now they didn't have >4GB RAM support, they were missing basic functions from the C standard library and had lots of other missing features and significant bugs.
I suppose this is because they don't have enough developers, yet they still waste time by doing things such as trying to reimplement CVS, just because they don't like the GNUGPL. Crazy, if you ask me.
I will assume that the use of the word "immature" means lacking features in your vernacular.
What you consider a waste of time is not considered a waste of time on their part. They (the core devs) are a group driven by philosophical wants. For them, the license issue is very important so that is where they spend the majority of the time.
The problem is not so much that they're rewritting CVS with a BSD license. The problem is that these days pretty much everybody is running away from CVS to distributed systems like git or mercurial.
So basically OpenBSD is wasting the few time they have into rewritting a outdated source management system.
Except they're not simply a making feature-by-feature, bug-by-bug reimplementation of CVS. They're making a better CVS that fits their needs. They're leaving out things they consider bloat in CVS and improving the stuff they don't think works as well as it should. Basically they considered the old CVS too stagnant and too bloated, so they made a better one.
To what I understand, OpenCVS is a reimplentation of CVS with better security and access control while staying compatible with the original as much as possible. At least, it's how they are advertising it. They cannot add or remove many features if they want it that way. Even if they change their minds, they are still building a new solution based on something that is obsolete.
I believe it would just be more productive to start up a new SCM.
Not always, but when I do, I take my time to investigate alternatives that might bring me more for my time and money.
It just seem pointless to me to reinvent the same old wheel, especially when there are ways to build newer and better wheels nowadays. That said, the OpenBSD team is completely free to do whatever they want: it's their project and it's not like it's gonna change my life.
They obviously disagree with you that CVS is fundamentally obsolete. Sure Linus didn't like CVS, but all that means is that Linus didn't like CVS, not that CVS is obsolete. And given that they have far more experience with large scale collaborative software development than I have, I'm certainly not going to argue with them.
Well, it's not like CVS is going to bit-rot projects that are still using it. However, many high-profile open-source projects and enterprises are moving to alternatives because they are improving the collaborative experience for their users. After using SCMs like SVN, Hg or Perforce, it's a bit hard to get back to CVS.
I just wonder why the OpenBSD folks didn't started up a brand new project instead of working around CVS.
It's not "just because they don't like the GNUGPL."
From a OpenBSD misc@ mailing list post at http://marc.info/?l=openbsd-tech&m=112589526510808&w=2 Theo responded to a post about OpenCVS as follows:
> the OpenCVS effort or not, however the off-list reaction seems to be
> that the primary interest of the OpenCVS project is in re-licensing.
That is not the primary goal at all. Some people who really have nothing to do with us, and know zero about where we are going, are saying that. And they are wrong.
> In
> this case perhaps there wont be a lot of synergy between the projects.
That said, we have no interest in furthering GPL codebases. Not just because of the licenses, but also because of the obvious bloat that always happens with these codebases designed to "work on every stupid variation of system even written in the past".
And later on in http://marc.info/?l=openbsd-tech&m=112589736230624&w=2
When it is done, OpenCVS will run fine on other systems.
Like OpenSSH.
Without the boatloats of bloat that is common in GNU-style projects.
I guess immature means different things to you and me. I consider OpenBSD extremely mature and have done for years. Their hardware support has always been more than sufficient for my needs and everything they claim to support works perfectly out of the box. The entire system has been always been rock solid. I honestly don't think I've had a crash with OpenBSD. OpenBSD has always been a breeze to manage and their firewall and filtering software really is best I've ever used.
OpenBSD takes the approach that it's better to support few things well than lots of things badly. And admittedly because of this there have been projects where I've been unable to use OpenBSD. But they're very clear about what does and doesn't work, and I've never been in a situation where something I thought would work didn't. So while I might not have as many features as, for example, Linux, the features they do have are very mature.
They're not reimplementing CVS because they don't like the GNU GPL. They're reimplementing CVS because the don't like the GNU implementation of CVS. Two entirely different things.
Question of priorities. We choose to spend time on security features like stack smash protection, heap and library location randomization and much more.
We could as well say: oh dear, other systems are just busy catching up on these security features, they are really immature.
A strong point about OpenBSD is focus. We are not trying to please everybody, since we know that will fail anyway.
is based on isochronous transfer. What is the difference with FreeBSD? They hve some iso support but it is experimental nd slowly merged in mainline kernel. Do they use the same or there is a re-implementation?
About the friend talking about immaturities. I am GPL fan and against BSD licence. I use linux. But OpenBSD is exceptional because it is a source of drivers for other BSDs. Moreover it cooperates with other BSDs and is not writing incompatible code ala MS. I wish there was projects like GNU/kFreeBSD for Net/Open/Dragonfly-BSD. I also wish MidnightBSD worked on porting GNUstep/Etoile on OpenBSD and not doing a kernel re-write. Hopefully with OpenJDK they will have better userland tools to configure their systems.
I hate BSD ideologically but these folks are doing a tremendous job. Maybe one day Haiku enters this ecosystem.
I've been using OpenBSD as a router for several years now and I use it off and on as a server. It has always been a simple, clean, and stable environment. The latest 4.4 release is no different.
<blockquote>yet they still waste time by doing things such as trying to reimplement CVS, just because they don't like the GNUGPL. Crazy, if you ask me.</blockquote>
Do you contribute source code to the OpenBSD project? Do you donate money? If not, you really have no reason to complain.
Just because one solution exists for a particular problem does not mean it is the most efficient. Open source is a free and open market. I'm glad to see competitive efforts in the field.
Well, X runs perfectly fine on KVM/QEMU I cannot understand why people enjoy that limited proprietary clone.
However, I do not use X for my OpenBSD VMs I have them to test things I wouldn't dare to do in a real machine with real data inside.
No need for X - I have the Linux host for that.
I could probably use X as it was intended and pump apps into to my box but, as I usually just use the terminal, what I do is I forward a virtual port and communicate with it via ssh with the main tty on stdout. I have two nice puffy icons in my Xubuntu desktop, one for the "daemon" and another for the ssh sessions. Seamless desktop integration, I say.
Edited 2008-11-13 12:38 UTC