Slashdot Mirror
New BSD licensed CVS replacement for OpenBSD
Jeferey Bakins writes "In an effort, by Jean-Francois Brousseau (jfb@openbsd.org), to rid the OpenBSD CVS tree of GPL'ed licensed code, OpenCVS is now officially part of the OpenBSD project.
For more details, see the OpenCVS homepage;
http://www.openbsd.org/opencvs/"
I was about to ask why they did not use Subversion, but I searched Google and found it uses software licensed under at least the LGPL (neon). Of course, they could have just edited Subversion to use another HTTP library like Curl or fetch (at least on FreeBSD). Maybe this has been in the planning stages for awhile.
Let me know when they've finished with their GCC, Gnome, and KDE replacements. I'm looking forward to trying them out in 2012.
Judging by this commment I'm guessing you haven't used any BSD variant. The idea isn't to reimplement EVERY piece of GPLed code, only the stuff in the BASE SYSTEM. It's hard for many Linux users to make that distinction, but in BSD you have the base operating system (that's more than the kernel) and the add on software.
Would you be happy using Linux if it had random things that had proprietary licences in it? Of course not. By the same token BSD is about being free via the BSD licence, it's really a snag when you have a mix of tools using BSD and GPL licences.
I don't see stuff like GCC going away, but GCC isn't neccesary for a functioning system so it can be torn out if someone doesn't need it. Most of the base system has GNU utilities in odd spots (tar was recently replaced in FreeBSD for instance). When all of this is said and done you know that the base system is BSD, and the rest of the software is whatever you stack on top of it - no confusion as to what is where.
There's a small thing holding back Net and OpenBSD (I'm an advocate of both, this isn't trolling, just an observation) which is lack of real kernel preemption in favor of clean, simple code. While you do get the most out of your cycles this way (and it shows on lower spec machines), even on higher end machines even moderate load (in my experience, any compile job, even -j1) can make the user interface very unresponsive.
My worst experience (possibly made worse by flaky hardware) of this is NetBSD 2 a couple of days ago, doing a pkg_chk -u round that made my entire day consist of 10-second lag after typing things before they appeared, and almost having to resort to elinks because Firefox couldn't do anything useful. On a DESKTOP system, traditionally an interactive system, this is a Very Bad Thing, since it reduces productivity if the system is under any other load.
The irony is that the Net/OpenBSD approach results in typically better server/overall performance, where 'responsiveness' isn't an issue, and hence they really do make great servers. The way people say "Net and OpenBSD are still for servers" has its truth, but you won't stop me using (at least) NetBSD on a desktop instead of Linux just for the peace of mind.
If there's a clean and simple way to improve responsiveness without significantly hurting performance, it should be implemented. Apparently a new thread scheduler would be enough, but even that is quite a task.
Sam ty sig.
Here's where I step in with a favorite URL - http://kerneltrap.org/node/view/4126 - wherein Linus himself points out that GCC 3.x is a generally worse C compiler, with some advantages in C++ compiling being its only real saving throws.
While I can't honestly say BSD projects haven't come under the same kind of problems (FreeBSD 5, for instance, which at least right now isn't a pretty sight), the tendancy is not to replace perfectly fine systems (like gcc 2.95's essential core, which was fast and light) with monstrosities (gcc 3.x). If something new is to be implemented, it has to be Right in design and in practice. If a BSD project wrote a compiler, it would be free, light, very UNIXy (functional, not kitschy), and few people would care because it's not GPL and anything non-GPL must be inferior, right? Some people...
Sam ty sig.