We'll see | Matt Zimmerman

a potpourri of mirth and madness

Community inertia in Debian and Ubuntu

At Debconf 9, Steve Langasek delivered a talk on pam-auth-update, which included a tongue-in-cheek slide about how it had come to be.  He pointed out that this project had required about six years of “thinking” and two months of actual development, and that this seemed to be a pattern exhibited by a number of notable Debian projects in recent years, such as using dash as the default shell, or supporting package Recommends in APT.

This fostered a lively discussion with several members of the audience about how large changes are discussed, decided and implemented in Debian.  Often, this process involves extensive mailing list threads, bikeshedding, hemming and hawing.  Sam Hartman suggested that Debian developers could do better at facilitating consensus. Joey Hess pointed out that several of the example projects Steve mentioned were actually implemented first in Ubuntu, then brought into Debian.

This isn’t because Ubuntu was particularly innovative with regard to these projects.  Many of them had been discussed and even designed in Debian before Ubuntu even existed. However, Ubuntu was able to take those crucial first steps before Debian was.

Why was this the case?

Debian is a good example of a large open source project with well established patterns of work. Most of the work in Debian is divided up according to packages, and a designated person or team is responsible for each package. This autonomy is a part of what makes Debian development particularly rewarding, as it fosters a sense of personal ownership. This arrangement also scales well: people working within well-defined areas are less likely to step on each other’s toes, and most decisions can be made quickly by a single person or a small group. There are close to 1000 individual developers actively contributing to Debian today.

However, it doesn’t work so well for projects and decisions which span these boundaries. The most problematic projects require buy-in from many individual developers to pursue a common course of action. This clashes with the autonomy which works so well for smaller scale projects.

So, why are things different in Ubuntu?

First, Ubuntu is smaller than Debian, in terms of the developer community. The development team is still small enough (less than 150 people) that consensus is more easily achieved.

Second, Ubuntu developers are loosely organized into teams around common interests, rather than by package. They don’t think of packages as “belonging” to a particular developer, and multiple developers routinely work on the same packages. Even where, in practice, only one person ever touches a particular package, that is seen as largely incidental: that person is simply doing more work on that bit of code than anyone else. It’s more similar to how things work in a shared source tree, where some developers know some parts of the code better than others, but they are fundamentally working together on the whole tree.

Areas of responsibility in Ubuntu tend to be more emergent (“it’s my responsibility because I’m involved”) than prescribed (“it’s my responsibility because I am the designated maintainer”). While there is much more team structure in Debian than there once was, the most important organizational structure in Debian is still the Maintainer field. If something is not clearly the responsibility of a particular maintainer, it can be unclear where to start, or who (if anyone) has the autonomy to decide how to proceed.

Finally, Ubuntu is a branch of Debian. Once a project grows beyond a certain point, it becomes difficult to make major changes on the spot. Major changes rarely come out perfect the first time, so they may need intensive regression testing before they can be considered stable enough even for development purposes. The changes also need to be coordinated with other developers, because they may interfere with their work.

Revision control offers a solution to this problem in the form of branches. Developers can make sweeping changes freely in a branch, work out the worst of the problems there, and then merge their branch into mainline. Rather than first persuading other developers to buy into an idea, someone can go off and implement a prototype, prove that it works, and then persuade others to adopt the working code (which is often much more compelling than an idea or even a design).

This is exactly what has happened with several major features which were developed in Ubuntu first.

It turns out that branching an entire distribution is much more complex than a single source tree (just ask the Launchpad team). Branching Debian is very heavyweight, and merging the changes back is a lot of work as well, as most of the work still must be done at a package level. Without branches, though, it is very difficult to implement large scale changes without hindering the progress of other developers.

So, what can we learn from all of this? I drew the following conclusions:

  • Branches help alleviate blockage when implementing major changes
  • Debian may benefit from more use of branches for major changes
  • Ubuntu may be an appropriate branch for some types of changes
  • Ubuntu is surely not sufficient, though, and Debian probably needs a more flexible way of branching the distribution

Written by Matt Zimmerman

July 27, 2009 at 07:18

Posted in Uncategorized

Tagged with , ,

36 Responses

Subscribe to comments with RSS.

  1. Debian is doing very, very well. There is no other distro that attracts as much developer talent, and Debian contributes much, much more to the Linux codebase than Canonical. There is no “blockage”, nor problem “implementing major changes”, with Debian. If you knew anything about Debian, you’d know that it already _has_ its own system of branches, called “Stable”, “Testing”, and “Unstable”.

    Debian devs surely don’t need “advice” from Canonical devs. Debian has a rock-solid reputation for being both stable, as well as quite customizable. Ubuntu has a reputation for being unstable, and bloated beyond any hope of customizing it for anything other than a slow desktop system for hosting closed binary blobs.

    I’m getting tired of reading your periodic attempts to suggest that Ubuntu is “better” at doing something you mistakenly assume Debian doesn’t already do better than Ubuntu ever will. You should just stick to the Canonical goal of packaging yet more bloat into a Linux distro. Shouldn’t you be busy inflicting Mono upon your unsuspecting userbase? Please stop writing about Debian. You don’t know Debian.


    July 27, 2009 at 08:42

    • Wow, what an unexpected and uninformed response.

      I based what I wrote on nearly 10 years as a Debian developer, as well as my experience in Ubuntu. I discussed these ideas with other Debian developers in person at DebConf, and they were receptive and supportive. On what are you basing your comments?

      In practice, there is a great deal of productive cooperation between Debian developers and Ubuntu developers, and both distributions serve their users well. It is most often those on the sidelines who seem to want to paint the two projects as adversaries.

      This sort of attitude does nothing but harm to either project, and to the free software community in general.


      July 27, 2009 at 09:16

      • I wonder if jg knows that Mono was in Debian for 2 years before Ubuntu even existed…

        Jo Shields

        July 27, 2009 at 11:37

        • Correction: Mono is in Debian’s repositories. There’s a difference. Debian isn’t Ubuntu. The Debian devs don’t always add bloat to the system just because it’s possible.


          July 27, 2009 at 17:46

          • And Debian doesn’t release 20-odd CDs containing the entirety of the repos? Debian’s repos are still Debian, just as Universe is no less a part of Ubuntu than Main is.


            July 27, 2009 at 19:28

      • I repeat: Debian already has an organized system of branches. It doesn’t need Ubuntu as another supposed “branch”.

        Debian has done extremely well with their current approach, and gained a reputation for stability and customization that Ubuntu can only dream of. Why don’t you fix your own distro instead of proposing unneeded, unnecessary changes to Debian?

        It’s not about being adversarial. It’s about being pointless and clueless, which your proposal about creating additional branches of Debian is. (And note that there are _plenty_ of Debian based “branches” already. It’s typical Canonical mindset to ignore all the work the rest of the Linux community does, and pretend that Ubuntu is the only Debian “branch”). You always trot out that “you’re being an adversary to harm the free software community” strawman argument whenever someone criticizes some bad idea you come up with. Nobody is buying that nonsense. You forked Debian. Fine. Now you’ve got to deal with all this entails. It’s not Debian’s fault that Canonical has discovered this is hard work, and consequently Ubuntu is an unstable, bloated fork due to not having those Debian devs maintaining your fork. They’ve got their own work to do. Sure, I imagine that every person who has forked Debian would love to change Debian’s infrastructure somehow so that it benefits his own pet project/fork, but that would literally destroy Debian. It’s not Debian’s fault that Canonical is having trouble keeping up because it decided to fork Debian instead of actually work on Debian itself. Forks require lots and lots of work. And maintaining a fork gets _harder_ as time (and inevitable changes) happen. Welcome to reality, Matt. I’ve forked projects before and I know that you _must_ realize that eventually you’re going to get irreparably “separated” from the original project. It _always_ happens and there’s no way to stop that, short of terminating the original project and switching everyone to the fork (which is what your type of “suggestions” about Debian would ultimately do. We _need_ Debian. We don’t need any particular fork of it).

        Debian doesn’t need to change just to benefit your efforts to fork Debian so that you could base your commercial interests around it. In conclusion, Debian doesn’t need more forks, it’s doing splendidly as is, and your suggestion otherwise is bad, bad, bad (for Debian). Go maintain your fork and stop trying to ruin Debian with bad ideas.


        July 27, 2009 at 17:35

        • I don’t believe Matt’s talking about “how Debian should change to benefit Ubuntu” but rather “lessons learned in Ubuntu that Debian might find handy.” Ubuntu has been doing this short-release-cycle thing for 5 years now. If anyone in Debian wants to know how to rapidly get new features in…well, Ubuntu’s doing it.

          Really, you could just say “agile” and be done with it, since it seems the way things work in Ubuntu is similar to agile development (or “iterative development” if you prefer).


          July 27, 2009 at 19:37

          • Here are his “conclusions” and why they’re misguided:

            “Branches help alleviate blockage when implementing major changes”

            Debian already has 3 official branches, and they serve their purpose of making Debian renowned for its stability and ease of customization (not to mention the myriad of platforms supported — something that Ubuntu utterly fails to do). Debian does not need any more branches, and it’s misguided to suggest otherwise.

            “Debian may benefit from more use of branches for major changes”

            Wrong. Debian doesn’t need more insufficiently-prepared people taking its codebase, and going off on a tangent, like Canonical did (and now finds itself in trouble because Canonical obviously didn’t realize the inherent ramifications of a fork. Over time, a fork _always deviates more and more_ from its original codebase, and at some point it becomes counterproductive to try to sync the increasingly incompatible code bases. The fact that Canonical’s CTO doesn’t realize that, at some point, it’s imperative for a fork become self-sufficient or it dies, underscores how green he is at dealing with the ramifications of a folk. Look, if this was Mandriva’s CTO talking about how Mandriva needs to become some sort of “Fedora branch” that the Fedora devs expend time and effort accomodating, I’d be telling that CTO the same thing).

            “Ubuntu may be an appropriate branch for some types of changes”

            It has been several years since Canonical forked Debian. Ubuntu should _already_ be a self-sufficient distro, just like Mandriva no longer grabs the latest alpha version of Fedora to base _each and every_ new Mandriva release upon that. The fact that Canonical’s CTO is _still_ talking about how an increasingly incompatible Debian fork should become a “branch” merged into Debian, rather than talking about how Canonical plans to make Ubuntu a self-sufficient distro, should be extremely worrisome to Ubuntu endusers. It doesn’t sound like Canonical has a working long-range plan for developing a distro. It sounds like Canonical just wants to continue making its own version of Sidux, with the resulting, increasing regressions and instability that goes with it. At least the sidux devs realize the ramifications, and so _all_ their effort goes towards mitigating the incompatibilities with custom package management scripts and such. They aren’t trying to fork Debian for the purpose of dolling it up with extra GUI features and Mono apps, then fingering Debian’s infrastructure for the fact that Ubuntu’s increasingly divergent fork is showing more and more regressions and instability. Canonical needs to make its codebase self-reliant so that it can actually fix the regressions and instability, and stop pointing fingers at others (who aren’t responsible for Canonical’s predicament).

            “Ubuntu is surely not sufficient, though, and Debian probably needs a more flexible way of branching the distribution”

            Debian is doing fine with its current infrastructure of branches. The problems with Ubuntu’s lack of “sufficiency” is entirely the cause of Canonical’s failure to create a self-sufficient distro. That has nothing whatsoever to do with Debian. If Canonical’s CTO doesn’t _already_ have concrete plans on how to make Ubuntu a self-sufficient distro, then Ubuntu is _already_ on the path to extinction. It’s only a matter of time. A fork can rely on its original codebase only so long before it becomes an unworkable nightmare with nowhere to go but the trashbin. I know because I’ve been there.


            July 27, 2009 at 22:54

            • Ubuntu has never been intended to be a “self-sufficient” distribution. If it had been, we wouldn’t be merging the latest from Debian every six months. We intend to continue working together with Debian, to our mutual benefit, indefinitely.

              You are coming off as extremely toxic, and I’m not sure who you think you’re representing in this discussion. It certainly isn’t Debian or Ubuntu developers.


              July 28, 2009 at 00:11

              • Oh, I do hope you have plans just in case.


                July 28, 2009 at 08:27

            • I’m still confused regarding why you think he’s suggesting these things for Ubuntu’s benefit. He’s not talking about adding to stable, testing, unstable, and…well, you forgot about experimental. I think he’s talking about a version-control definition of “branch”…you know, having a team go off on a tangent and develop something to be merged later.


              July 28, 2009 at 07:59

        • If you had any first-hand understanding of either Debian or Ubuntu development, I don’t think you would make these comments. There honestly isn’t much here that warrants a response.

          unstable, testing and stable aren’t branches in any full sense. Packages move monotonically from stable to testing to unstable. Development doesn’t continue on testing while major changes are undertaken in unstable: testing waits for unstable to stabilize.

          As for Ubuntu keeping up with Debian, we’re doing that just fine, thank you very much. Debian and Ubuntu developers are working together more, and more effectively, than ever. If you prefer Debian to Ubuntu, by all means, use it, but don’t waste your time trying to promote dissonance where collaboration is working.

          If you had read the original post, you’d see that I didn’t suggest any change on Debian’s part. Having contributed to Debian for many years, I have the highest respect for what Debian is, and want it to continue to flourish indefinitely. The work that we do in Ubuntu is additive to Debian, and both projects benefit.


          July 28, 2009 at 00:09

          • “unstable, testing and stable aren’t branches in any full sense.”

            Baloney. They comprise all the “branches” that Debian needs, and anything more would simply present more problems for Debian’s limited resources than it would ever solve. Debian’s way of having its “branches” simply be the last _fully tested_ version of the codebase (something Ubuntu _never_ achieves with its “release the next version in 6 months no matter how bad it is” approach), the last somewhat tested version of the codebase, and a snapshot of the latest changes, avoids silly stuff like time-wasting “merging” of unnecessarily forked code.

            “Packages move monotonically from stable to testing to unstable. Development doesn’t continue on testing while major changes are undertaken in unstable: testing waits for unstable to stabilize”

            And that’s how it _should_ work. How an alleged “branch” _shouldn’t_ work is for someone to fork the codebase, make “major changes” to it, and then attempt to remerge all those changes back. The fact that Canonical does this underscores why Ubuntu has neither the stability, platform support, nor customization of Debian. You’re wasting too much time hacking/testing “merges” of code that you’ve already, and unnecessarily, hacked/forked. Obviously, that means you’ve got less time to fix regressions, create a distro that offers the ease of customization that Debian does, increase platform support to Debian’s extent, and solve Ubuntu’s frighteningly increasing bloat.

            “I didn’t suggest any change on Debian’s part.”

            Who are you kidding? It’s in black and white above. 2 of your 5 “conclusions” specifically suggest changes in Debian:

            “Debian may benefit from more use of branches for major changes”

            “Debian probably needs a more flexible way of branching the distribution”

            Do try to remember what you’ve written.

            I couldn’t possibly disagree more, and I think your suggestions would only serve to make Debian worse. Debian should stay their successful, proven course, and resist having its resources diverted toward the needs of extraneous forks of its codebase. That will only increase regressions, bugs, instability, and divert resources from other, more important things than futilely trying to maintain indefinite “synchronicity” with a fork (which is an ever-increasingly-elusive goal. It’s like chasing a rainbow to find the pot of gold at the end).

            “Ubuntu has never been intended to be a self-sufficient distribution”

            I certainly hope that isn’t your “selling point” to a corporation that is also evaluating Redhat and Suse, neither of which rely upon another, noncommercial distro’s efforts, nor waste their time attempting to synchronize their codebase with some fork of theirs.


            July 28, 2009 at 07:44

            • I don’t think you’ve understood my post very well, and I’m disappointed at the negativity you’re venting here.

              I’ve described a troublesome pattern which was pointed out by Debian developers at DebConf, and you’ve said that it doesn’t exist. I’ve described how the problem was avoided in some cases where things worked better (as acknowledged by the developers involved), and you insist that these approaches are somehow wrong despite their successes.

              No free software project is “self-sufficient”. Indeed, it’s the interdependence between projects which makes the community strong. Red Hat and SuSE are just as dependent on the community as Ubuntu is, and that’s a good thing. In this view, it is blindingly obvious that I (and the rest of the Ubuntu community) have the greatest respect for Debian and want it to continue to thrive.

              Branches (the kind where active, destabilizing development happens) have been instrumental in moving many free software projects forward. This idea is neither new, nor untested, nor even mine. It is a straightforward application of version control concepts on a larger scale.

              P.S. if you would like to continue this dialog, please attribute your comments to some meaningful identity, such as your real name or an entity you represent. You have me at a disadvantage here.


              July 28, 2009 at 10:29

              • “a troublesome pattern which was pointed out by Debian developers at DebConf”

                I don’t know who these supposed Debian devs are (ie, whether they’re really Ubuntu devs who consider themselves also debian devs simply because they’re at DebConf, or whether they’re officially maintaining any debian packages), nor what percentage of the debian dev community they comprise. Yes, I do know that there are a number of debian devs who would like to see some things change/improve in debian’s infrastructure (but mostly in regards to faster approval for new dev assignments, less personal flame wars on the mailing list, or other such “social” things. I haven’t heard many clamoring for adding additional “branches” to debian’s existing 3 official branches. I’m sure there are some folks doing that, but not enough to warrant consideration of the dangerously counterproductive suggestions you’ve made).

                But here’s the bottom line: Debian’s infrastructure is _already much better_ than Ubuntu’s. The former produces more software, more upstream support, more kernel contributions, a distro with much wider platform support, a more stable, faster performing distro, a more customizable distro, a distro that is more trusted and utilized in businesses, etc. It’s also a community that is much more transparent (to the point that it can’t stifle dissenting viewpoints even if the “big cheese” wanted to). Contrast that with, as just one example, Ubuntu devs censorship of objections to Canonical’s self-serving, hypocritical commercial use of the Ubuntu name in its commercial Ubuntu One service. There is no accountability nor transparency in the Ubuntu community. There are only people who have the power to stifle opposing viewpoints, and do so.

                You need to stop talking about what Debian’s community and infrastructure should be doing, because it’s _already_ way better than Ubuntu’s alternative, and instead spend your time fixing all of the much-worse-problems with Ubuntu’s development and community.

                And that’s the bottom line.

                “attribute your comments to some meaningful identity, such as your real name”

                Why, so you can change the subject to talking about me instead of the merits (or rather, lack of merits) of what you say about Debian in your blogs?

                That’s the sort of stuff I’ve come to expect from the Ubuntu community. Typical.

                If you’re “at a disadvantage”, why don’t you just employ the usual Ubuntu way of handling that — just censor my reply, pretend that the Ubuntu way is still the best, and continue to dole out “helpful” advice about how the other distro communities can learn something from Ubuntu (as if they should be using it as something other than an example of how _not_ to be as useful a distro to the Linux community as Debian is).


                July 28, 2009 at 20:21

  2. Debian is a excellent distro.

    When it will release XX feature … ?

    When it is ready !!! (NOT Before that, like somethings in Ubuntu [1]).

    Many tasks needs more people working in, of course (debian lacks in man power in some (many?) areas).


    [1] We are suffering intel graphics hell in jaunty!


    July 27, 2009 at 10:38

    • Through that pain we as a userbase have contributed enormous testing back to Intel and as a result the Intel driver is vastly improved in mainline and will be so improved in Karmic.


      July 27, 2009 at 11:26

    • the intel graphics is a regresion bug, not a feature. I suffer from it as well and it is just one of the things that just happens.


      July 27, 2009 at 13:15

    • Some of the things ubuntu delivers to millions is definitely something debian should keep an eye out for.

      Ubuntu switched from python 2.4 to 2.5 and then 2.6, the positive effects and the negative effects could be seen by the debian community and from there take the necessary steps to implement in debian. This tends to happen with gcc as well.

      This sort of cases tend to lower the presure of making big changes. it will be interesting to see the python 3.0 migration past python 2.7.


      July 27, 2009 at 13:31

  3. […] Community inertia in Debian and Ubuntu Finally, Ubuntu is a branch of Debian. Once a project grows beyond a certain point, it becomes difficult to make major changes on the spot. Major changes rarely come out perfect the first time, so they may need intensive regression testing before they can be considered stable enough even for development purposes. The changes also need to be coordinated with other developers, because they may interfere with their work. […]

  4. @mdz, firstly, nice blog entry.

    Secondly, http://www.penny-arcade.com/comic/2004/03/19/
    (that’s what the Internet sometimes does to people)

    Jonathan Carter

    July 27, 2009 at 20:04

  5. My impression is that most people in Debian do not have any sense of obligation towards the project. While it is good that they have volunteered for something, it seems that most developer’s in Debian are all about how great they are and how everyone has to respect their rights, when Debian really needs some sustained commitment to do the actual work.
    That is something that seems to be vastly better in Ubuntu, if only because you have quite a few full-time dev’s (OOC, how many of the 150 are employees?).
    And then Debian is so entrenched in its bad habits that it mostly attracts people to match.


    July 28, 2009 at 08:51

    • I have a different impression of Debian. In my experience, Debian developers vary a great deal in terms of their behavior, motivation and views toward the project. However, of the many Debian developers whom I know personally, they are as a rule highly dedicated to the project, and have made sustained and valuable contributions over a long period of time.

      Ubuntu has several times more volunteer developers than Canonical developers, and the fact that we have both is a great strength, though it is occasionally difficult to keep these subcultures in sync with each other.


      July 28, 2009 at 10:35

      • I think the only time I could tell who was Canoni-folk and who wasn’t was when Alberto brought up that patch to add a GUI way to enable zapping in GNOME like there is in KDE (incidentally, the reason I tried, and switched to, KDE). Everyone that said “no” worked for Canonical. Everyone arguing for it, did not.


        July 28, 2009 at 11:22

      • Oh, there are dozens of brilliant and highly commmited people in Debian, I just have the feeling they do not dominate the Debian culture as much as they should. For example the lenny release seemed like a project of significantly less than one hundred people when it should have been a Debian-wide effort.


        July 28, 2009 at 11:37

  6. Ubuntu is more of a fork than a branch. I don’t see a plan for merging Ubuntu into Debian and then closing up shop.


    July 28, 2009 at 14:54

    • How is it possibly more of a fork than a branch? I can’t think of any other Debian derivative that works as much as a branch than Ubuntu does. The Ubuntu team has worked hard from early days to try to make sure that it doesn’t become a fork and that it plays well within the Debian eco-system.

      Jonathan Carter

      July 28, 2009 at 15:20

  7. I tend to agree with Matt the people on the sidelines are the ones making all the fuzz.

    day to day we see colaboration happen and that’s the ways it should be. we need more of that perhaps but let us keep on working on behalf of what these project stand for.

    There will always be naysayers and what not but it is up to us to keep the work going regardless of all the adversities.


    July 28, 2009 at 16:28

  8. […] had required about six years of “thinking” and two months of actual development… More here Debian is a good example of a large open source project with well established patterns of work. […]

  9. […] had required about six years of “thinking” and two months of actual development… More here Debian is a good example of a large open source project with well established patterns of work. […]

  10. Matt, there’s one point you missed, or at least it’s not explicit enough.

    One big strength of Debian, IMHO, is the rolling release aspect of Sid. I’ve been using Sid for nearly ten year with only one major glitch (as far as I can remember).

    The “resistance to change” you describe and the careful, painful (for DD) and long transitions are what make Unstable so… stable.

    At the opposite, development version of Ubuntu (that I test regularly) is often broken. It’s not a critic per se, it’s what permits big changes.

    The idea of distribution branches (no ig, Unstable, Testing and Stable are not branches in the sense of source branches) is very interesting.

    It would be cool if developers could make a branch of Unstable to test new features. A bit like Ubuntu’s PPA but at the distribution level. This would lead to a “broken branch” were fix could be done before new feature would merge back to unstable.

    The problem is that it would ask time and effort from developers and, more important I think, infrastructure for the Debian project.



    July 30, 2009 at 13:12

    • You make a very good point. Most Debian developers use sid/unstable as their daily working environment, and this means that they value its stability very highly. This contributes to the inertia which needs to be overcome in order to make a major change.

      If a Debian developer breaks something in unstable, this can make their fellow developers unproductive and slow down the whole project.

      Debian has an “experimental” repository which is similar to what you describe, but it is rarely utilized, often misunderstood and has some technical shortcomings.


      July 30, 2009 at 14:32

      • You can’t say that experimental is rarely used.

        $ apt-show-versions | grep experimental | wc -l

        It’s the KDE 4.3RC effect. ;-)

        Furthermore, experimental is not a distribution, it’s only an additional repository. What I meant was more (in the Ubuntu style):

        Alice and her friends want to work on multiarch. They create an unstable-multiarch branch were they implement it and can see what it breaks in the distribution.

        Frank and his friends want to work on KMS and create and unstable-kms branch.

        Frank’s branch and Alice’s one are distinct so the work of each team does not bother the other (and users can participate using the branched distributions).


        July 30, 2009 at 23:32

  11. While I love Debian and apt/dpkg, it would be nice if apt/dpkg was turned into something of a git/conary/zeroinstall-like thing (for source and binaries), so that (temporarily) forking, merging and maintaining “partially overlapping” distros would be easier. I suspect it would allow for a lot more experimentation and faster integration.

    I’ve been quite happy with my Debian setups, but I’ve found myself lusting after some of the concepts in Foresight (Conary), NixOS, ZeroInstall etc.


    July 31, 2009 at 04:56

Comments are closed.

%d bloggers like this: