Slashdot Mirror
Debian Core Consortium Releases First Code
daria42 writes "It looks like the Debian Common Core Alliance announced a while ago is going to make good on its promises: the project has released its first code this week. The release consists of a base installation of Debian 3.1 with the Linux Standard Base and security updates attached. But the project also looks like it has attracted some criticism from within the Debian developer community - with a spoof Web site having already been set up to poke fun at the Alliance."
Screw the real site, the spoof is what's important: http://www.dccalliance.biz.nyud.net:8090/
The story includes a link to the spoof website but not to the actual one. Great reporting.
The address is http://www.dccalliance.org/ btw.
There should be no problem with this as long as they're following the proper licensing for all the code they distribute.
It won't matter anyway to the Debian groups.
Everyone wants a Tux in their life.
Just what we need: some more kids (or grown-ups acting like kids) fighting among themselves. This is all we need to project that trustworthy Linux and open-source image.
let's face it if more Linux Distros worked the same way and had the same layout, plus if all lib,Sources were the same that would help out a lot.
CH
Somewhat on topic is the issue of fragmenting. For a while, if an application or OS didn't do something you like, the common response was:
- Dont like it? Fork it! - Dont like it? Roll your own!
Problem is that it leads to a lot of confusion and fragmentation within the community that confuses the hell out of outsiders.
I think consolidation is a good thing and folks should work together more often rather then just splintering a code base.
(Note, fragmentation CAN be a good thing in the cases like Security Knoppix or RTLinux)
DCC is based on older versions of most packages than those in Ubuntu. Ubuntu can't really be part of DCC.
I believe the full Debian distribution and the DCC are 2 complimentary items.
From the DCC website:
What is the "DCC" of the DCC Alliance?
The DCC is not a Linux distribution; it is a "base" Debian system composed of essential programs or "packages" from Debian GNU/Linux, combined with member additions to attain LSB certification and achieve broad commercial acceptance and support.
It appears as thought this is the low level never changing set (just up from the kernel), and is similar to a bare Windows release, ie you have to add your own applications.
liqbase
"Hello world, we released an open source operating system so that all may benefit from our efforts and... Oh noes! People are modifying it to suit their needs! Evil! Strike them down!"
This seems very reasonable to me. There's something I'm missing -- Why the resistance and the spoof site?
Conflict often brings about the biggest changes, and conflict between OS developers is nothing new.
Take OpenBSD. Had it not been for Theo quarreling with the NetBSD elite, then we would not have the ultrasecure system that we have today.
And of course there's the revolutionary DragonflyBSD. If Matt had not been ostracized by the FreeBSD team, then we wouldn't have what will most likely become the premiere workstation BSD in the near future.
Then there's the whole CTSS/ITS/Multics debacle of yesteryear.
While not an operating system in itself, the whole XFree86/Xorg licensing incident has proved to be one of the greatest influences on UNIX GUI development in the past 20 years.
I believe that conflict is essential for open source projects. For if it were not for conflict, we would not have such great products as OpenBSD, DragonflyBSD, and Xorg. I, for one, support this sort of conflict. It often leads to increased productivity in the long run.
Cyric Zndovzny at your service.
I was expecting a "spoof site poking fun" to be, you know, funny.
Sorry to be harsh, but when I started using Debian 3 years back, I wasn't treated well as a 'n00b' even though I had 2 yrs prior Slackware experience, and just felt like the entire project was too splintered. I mean, running on multiple archs is cool and all, but if it pulls down the medium range then what's been gained? The plus of this approach is it was ripe for someone to come along, take what's good (APT-GET!) and create something specialized, which is now Ubuntu Linux. Building on the Debian base was just their beginnning, but it was an ace move.
bad_outlook
--
Is this vague enough for you?
Always poking fun at the Alliance. Why is it that I always find myself drinking in an alliance friendly bar on Unification Day?
You like your new Mac more than you like me, don't you, Dave? Dave? I asked...She said Yes.
The Debian release cycle has left many people unsatisfied. Some are working within the Debian Project to improve the release process. Some, such as Ubuntu, have elected to step outside of Debian to do short-term forks, while feeding changes back into Debian.
"Release early, release often" is a good approach for software development. Large numbers of small, frequent changes can produce rapid improvement. Debian Experimental and Unstable show how well that approach can work.
But what's good for developers is horrible for users. Production systems need changes collected into larger, less frequent releases. That's what Debian Stable does. But it is very easy to get stuck in the 'collect' phase, and fail to make it to the 'release' part.
One solution to that problem is to schedule releases by date rather than feature set. The traditional, and Debian Stable, approach is to define what features will be in the next release, and release when the work is done. The result is that releases get pushed out by the slowest feature, and there is constant pressure to revise finished features, since they're waiting on the other guys anyway.
Schedule-based releases set release date targets, and work backwards from those. Features are prioritized, and only those features that can be incorporated by the release date are included. Features that fall below the cutoff can go into the following release.
I've seen two things happen with the time-based approach. One is that lower priority changes that didn't make the first release make it into the second release, and still beat the traditional model's first release date. The other is that feedback from the first release will show that some of the lower priority items slated for the second release need to be revised: some changed, some completely dropped.
Ubuntu is using the calendar-based release method for production releases, using Debian Unstable as their base. DCC is using Debian Stable as their base, and hoping to improve the Debian Stable release process. Different bases, different release strategies.
I'm sure that the current Debian Stable release process will improve. But I'm also sure that a much greater improvement will come with a switch to a calendar based approach. That won't happen without a working example to point to, such as Ubuntu. Debian is run by developers, and developers understand how to manage development releases, such as Unstable. But fewer developers understand how to manage production releases, and it shows. Debian needs to make a fundamental shift in how Stable releases happen. That shift will not happen without a working example of a better way. Such a shift happened with GCC, but only after a fork showed the way.