Tales from the Gryphon/ archives/ 2004/

Tales from the Gryphon

Archives for 2004/07

Manoj's hackergotchi
Add a new post titled:
Monday 02 January
Link: Beyond crumbling consensus: communication in Debian

Posted early Monday morning, January 2nd, 2006

Beyond crumbling consensus: communication in Debian

I have talked earlier about the crumbling consensus in Debian, which was nice, but did not delve deep enough into the reasons for the crumbling tendency to try to arrive at an consensus.

I can see bunches of people jumping up and down screaming communication! communication! communication!. Yes, but; have people complaining about lack of communication ever looked for a cause why communication in the project has deteriorated (and no, frequent flame--fests do not count as communication)?

The facile explanation is that people who fail to communicate, or fail to respond, are either overly busy (which does not hold water since the people examples being flouted are actually doing visible and often extensive work), just plain lazy (again, easily refuted), impossible to communicate with (and there are equal examples of people who have no problem communicating with the same people), or just plain secretive and malicious and holding a grudge against people.

With my experience with people in the project, I find it hard to credit the theory that people are strongly for a hidden, secret big boy club in Debian. Despite recurrent and no longer funny references (always unsubstantiated) about a Debian Cabal, I have not yet found any actual instantiation of the so called super secretive cabal. I know these folks, guys, and I am not buying a super secretive cabal.

But surely there must be some fire under all this smoke, right? Yes, but not in the manner that people think, I suspect.

I think the same phenomena is at work that causes lack of consensus efforts in Debian; and the root cause is partially the growth of the project (resulting in people no longer being acquainted with the other participants), and the perception of Debian as an faceless institution, rather than a convivial set of people trying to have fun and put together a distribution focussed on excellence.

I say this, since I have seen the growing tendency to treat classes of volunteers as faceless, nameless, institutions: we talk about DAM's, ftp-masters, list-masters -- anonymous, faceless, institutions that one may then chastise with little need to cater to their feeling (since when do institutions have feelings?). This is a similar phenomena to people treating other cars far more rudely than they would if they were talking to the driver face to face. The increasing hostility, expressed as increasingly pointless flame wars, and increasingly hostile mails to the people in visible positions in Debian (often verging to obnoxiously rude demands), whittle away at the motivation of the people doing additional work in Debian beyond their packages.

Now, given that most developers do not care to do more than cater to their own packages (the DPL has said several teams, including security, are overworked, and have been asking for volunteers. Policy has been looking for new blood as well, and I have been lucky enough to find one person who actually started out by doing the scut work, rather than ask for spoon feeding and a gilt-edg4ed invitation) -- we have a few people putting in far more labour into the project, above and beyond the talk of maintaining packages. The tasks these people perform is becoming increasingly thankless, to the point a few have taken to ignoring the most unpleasant communication in the interests of sanity. Since they respond still to nicer communications, it may appear there is a cabal -- but this is basic human nature, avoiding experiences that have, in the past, proven to be unpleasant and unproductive.

So what do I propose? The same thing I proposed before: I suggest that we try not to lose sight of who we are fundamentally: we are a group of people who have found common cause to volunteer our time to make the best OS out there. Treat developers like people. I would like to think we are a bunch of folks having fun -- and working together for what is still a common goal. Look at the big picture. Don't let the end goal be lost in the petty details.


Monday 02 January
Link: Debian and tyranny of the masses

Posted early Monday morning, January 2nd, 2006

Debian and tyranny of the masses

There have been various people positing that Debian is a democracy. It's not, thank god. Yes, we do occasionally vote on issues, but that does not a democracy make.

Another theory often advanced (usually as a counter to the democracy theory) is that Debian is a meritocracy. Again, this is not true: as above, there are shades of truth (as in merit, in theory, is held in reverence in Debian).

Why is it not a democracy? Well, we do not decide on issues based on popularity (else we'd be distributing windows share-ware). We make decisions based on technical merits, and principles we have agreed on (the Social Contract, for one). A developer is the Czar for the packages maintained by him/her, for example.

Decisions, for the most part, are taken by those who do the work (in flex, and fvwm, I have made decisions that are fairly unpopular with the user base, but, in my opinion, the correct ones). A developer has control over his or her package. The NM team decides to accept (or not) applicants -- but not through GR's. The DPL decides who should get funded for debconf -- in consultation with other people, but not via a vote. In a sense, Debian is a volunteerocracy -- Those who do, rule.

Why do I say it is not a meritocracy? Well, there is no evidence that merit is a gating factor for entry into the project, or a position in Debian. Sure, a modicum of bare competence and a base demonstration of judgement is required, both for entry into the project, and for appointment to a delegate's job; but this is a minimum threshold, really. The important jobs are fulfilled by people who took it upon themselves, who went in and started working (my first real package, kernel-package, was just me getting tired of remembering all the steps needed to compile kernels, and the resulting kernel images were quietly accepted after a probation period). So, merit is not the gating factor -- demonstrating readiness to do the work trumps ability.

I am sure there are a large number of more meritorious people in the wings who never stepped up to the plate and volunteered; and they would lose out to people who stepped up and presented something. We are a volunteerocracy, not a meritocracy.

Why do I say thank god above? Do we really want Debian to be a democracy? I am not a domain expert in any but a small subset of technical topics, and I would hesitate to have my opinion overrule the domain expert's. And yet that is what going for popularity gives you. In all but a handful of topics, most of us represent mediocrity, and only the domain expert represents expertise; decisions by laymen, as opposed to the experts, lead to mediocrity.

So, do we really want democracy? Rule by the unwashed masses? Governance by the least common denominator? Taking the popular route, over determining the correct one? How can you create the best distribution ever by bending over backwards to pander to mediocrity? Would one want to select leaders based on how cute they look, or how well they kiss babies (which seems to be the basis we pick politician's by)?

Thanks for listening.


Monday 02 January
Link: User Mode Linux: not ready for prime timeU

Posted early Monday morning, January 2nd, 2006

User Mode Linux: not ready for prime timeU

I have been using uml (actually, pbuilder-uml) for a while to build my packages and ensure that the build dependencies were sane. Unfortunately, in sometime in the last month or so, something broke: now uml just hangs with the lines

Initializing stdio console driver
Netdevice 0

Since I have wanted to get back to playing with SELinux, and since Russel Coker has deprecated 2.4 based LSM patches ( kernel-patch-2.4-lsm), I decided to try to compile my own 2.6 based UML, especially since I heard tell on IRC that it was feasible to do so. Thats when the fun started.

Well, it started ok. Google quickly found the user mode linux home page, from where I down loaded the UML patches. People on IRC pointed me to updated host and skas patches for the 2.6.7 kernels. The patches applied, though with some fuzz.

There was some initial confusion (you really need to specify ARCH=um all over, even when configuring cleaning -- took me a few minutes of confusion to figure that out). Then the kernel refused to compile. I tried all kinds of different host patches, but to no avail. Finally, I had to go on #uml for help, and I was told to turn off CONFIG_HIGH_MEM. That got the kernel compiled.

But then I kept getting the hangs while trying to get an initial network connection. Turns out that I had taken the dictates of the HOWTO too literally, which tell you to take the defaults. That is fine for 2.4 uml's -- for 2.6 uml's, the defaults do not compile in anything. I compiled in all kinds of network methods.

Compile, run, and get a hang trying to get an initial console. Hmm. Go back and compile in input methods. Does not hang now -- it just warns it can't open an initial console (though it pops up xterms all over. This time it is the lack of a devfs that rootstrap needs. Compile in devfs.

And now things segfault in the UML since the libc is trying to get native posix threads library, not yet supported in UML. I tried all kinds of methods trying to set LD_ASSUME_KERNEL=2.4.17, but to no avail (Look at this thread on the uml devel list.)

I give up. Getting a 2.6.7 UML running is too hard, and I am certainly not a kernel compilation newbie. I gave a go to the 2.4.26 kernel based UML with the latest patches and all (still on a 2.6.7 host with SKAS3), and the uml does not even start. And the 2.4.26 UML would not have SELINUX in it, so my motivation is at an ebb. (or nadir, really).


Webmaster <webmaster@golden-gryphon.com>
Last commit: terribly early Sunday morning, June 8th, 2014
Last edited terribly early Sunday morning, June 8th, 2014