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
What is the actual difference between "Debian Common Core" and "Debian" (since Dv3.1)? Is DCC just an organization that certifies that (its own) Debian-based distros are actually both Debian-based, and comply with "Linux Standards Base" specs? Does Debian v3.1 itself not pass that test?
--
make install -not war
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.
"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!"
(slightly edited)
o uille.htm
http://www.splorp.com/critique/
Spirals all come from Ubu Roi's dread Gidouille :
http://expositions.bnf.fr/utopie/pistes/grand/gid
aurelien
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?
I think that's a very superficial reason.
Nobody's versions match those of DCC (even Debian itself) - if all members felt that way, there would be no DCC.
DCC is a good idea, and so was United Linux, which got screwed up by a member. DCC is not facing such risks, so I think it will prosper.
In any case, DCC is targeted at people and companies sick of dicking around with distro incompatibilities and frequent version updates - a bit different from Ubuntu and Fedora.
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 spoof site at http://www.dccalliance.biz.nyud.net:8090/faq.html is pretty slow too, here is my analysis (and a copy of their 'faq':
So somebody is upset about basing the name of a separate organisation on 'Debian' and abbreviate that to a 'D'. Well wanker, I tell you something: you cannot trademark a single letter, or we'd only have about 36 possible companies.
(this seems a rip-off from the 'real' DCC faq entry. see above, no trademarks on single letters.
Aha, a somewhat real-ish bone to pick. Except that creating a patched kernel is not such a big deal. You can find several in testing, does that mean that testing has been forked with every new kernel release? As long as the new kernel is interoperable with the one it replaces you can hardly call that forking.
is DCC necesary?
Debian has grown into a big organisation, and thus also has it's share of people with 'uncommon personalities'. It is all a volunteer effort (and thus?) some people in debian react a little allergic to commerce baseed on Debian, even though the licence allows it. Commercial Debian-based distro's have a vested interest in Debian, so they seek some influence. It can be vey hard to have to argue with every maintainer whose package they have altered to get him to accept the changes(There are 1000's of developers and and at least ten times more packages in Debian). Even with proper conflict resolution it quickly becomes a nightmare, so a lot of distro makers don't feed their changes upstream/to Debian at all.
That is a problem and something that a separate repository can solve. Yes that is in effect a fork, in the same sense that Ubuntu or Knoppix is a fork (not for the silly reason above). If the Debian derived distromakers have their own repository where they can work together changing Debian to their common goals without getting bogged down in Debian rules/games, then that is just great, IMHO.
It is great for the Debian-derived-distro-makers(DDDM?), as it allows them to cooperate and improve Debian while they are at it. It is great because it avoids conflict and bottlenecks. Commercials distro's (can) have a different interest than induvidual Debain developers. With this construction no single Debain developer can obstruct a DDDM. It is great because It will concentrate all enhancements made by DDDM's into one place, so the Debian developers don't need to track all different DDDMs for changes to their packages. And most of all, it will concentrate efforts into coding and cooperating, and that is good for all.
This space is intentionally staring blankly at you
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.
There are two reasons why Ubuntu is unlikely to join:
* Debian isn't even part of the DCC *commercial Debian* Alliance. Debian like Ubuntu aren't commercial distributions, so the DCCA isn't for them. If Debian were to join (or more likely, the DCCA join Debian), this barrier would disappear since Ubuntu tries to stay close to Debian SID as is stable.
* Ubuntu is based off of SID. DCC Alliance code is based off Sarge plus some selected backports. The only way Ubuntu could be based off of DCC Alliance code is if SID were backported to Sarge -- that sort of defeats the purpose of SID/Testing and seriously short-circuit the Debian process.