Tales from the Gryphon/ archives/

Tales from the Gryphon

Archives for 2004

Manoj's hackergotchi
Add a new post titled:
Wednesday 22 November
Link: Dumbing down the UI: tools vs appliances

Posted at midnight, November 22nd, 2006

Dumbing down the UI: tools vs appliances

What is an appliance? A refrigerator is a prime example: I can walk to a refrigerator in Hong Kong, and know how to use it: I open the door, put in my beer, and after passage of time, it becomes cold. Open door, take out now cold beverage. Done.

A simple Axe, on the other hand, is a tool. One needs to learn how to use it -- in experienced hands, an axe can splinter a match stick. In inexperienced hands, on the other hand, an axe hitting at the wrong angle can bounce off the wood you are chopping and take off your foot. Please note that there is nothing complicated about an axe -- so mere complexity is not what distinguishes a tool from an appliance.

An axe is a versatile tool, though. It can be used to fell trees. Firefighters use it to rescue people by going through doors. Dwarwen warriors use it as a weapon of war. It come in versions that can be lightly thrown, or wielded two handed for telling effect. And remember, the term hacker comes from those who created furniture using axes.

Tools need to be learned. However, mastery of a tool can lead to wondrous creations -- think furniture (I have never heard of any significant refrigerator-fu, I fear).

This brings us to interface design. I use my computer as a tool of my trade. It is what I do, and I have invested effort in leaning how to use it effectively. I understand there are people who want to use computers as a typewriter appliance; and proclaim they have no desire to invest time required to master computers as a tool. Please understand that this has nothing to do with novices; a apprentice may well be uninitiated in the intricacies of a tool at the inception of his career, but can still be committed to mastering it.

For the most part I can accept the view point of the people who want to use computers as appliances -- though I personally feel that is a waste of a general purpose computer. I have no interest in catering to that viewpoint. Unfortunately, there is a vast difference between user interfaces for people who want appliances, and those who want a versatile tool -- and I fear the user interfaces are being hijacked by people belonging to the former set. (Anecdote: I used to go to a travel agent, using Sabre software -- each keystroke was bound to some kind of macro,and she could scan through several alternatives through multiple airlines faster than orbitz can. Using a menu driven UI wold take me half an hour to do what she did in seconds). I see applications getting bloated with user interfaces designed for the infrequent user, with little care being given to the needs of the people who are intent on speed and ease of operation, not on flattening the learning curve down to nothing.

Update: As Tollef Fog Heen points out, the critical distinction is frequency of use: for items one uses frequently it is worth paying the cost of climbing the learning curve, and flexibility and ease of operation count for far more than the cost of learning to use the tool. For items used but infrquently, one has pay the cost of the learning curve many times over; and thus it would make sense to minimize the curve. Not all interface design ought to cater to the sentiment that these programs are used but infrequently. And, in the old days, I could learn the use of a program that best suited my needs, figure out common command switches, and script them, and never really have to re-climb the curve.

Thanks for listening.


Monday 02 January
Link: A test suite for Devotee

Posted early Monday morning, January 2nd, 2006

A test suite for Devotee

I have been thinking about informally going through NM (perhaps with an AM who wants some practice) for a while now (and have been procrastinating about it like many real-life DD candidates :-). I have planned on using Devotee (DEbian VOTe EnginE) as the package I use to get through NM. So, pursuant to packaging Devotee, I am trying to add a test suite to the package. In order to run a decent test, I need a set of ballots -- signed ballots -- at least some of which are signed by keys in the Debian key-ring. I have put together a dummy vote on my own box, with the topic being voted upon being What is your favorite color of the rainbow?. Here is the ballot. Please note that any emailed ballot is likely to end up in a GPL'd package, open for all the world to see, so please consider that before voting. Oh, and the interesting stats are here.

So, why am I embarking on this strange course of going through NM even though I am already a Debian developer? Well, I've been in the project since well before there was a new maintainer process. I just felt like contributing, and, one day, just emailed the devel list, and I was in. No checks, no key signatures required (not even a key was needed, unless my memory is failing me). I have a theoretical knowledge of what NM entails, but no real gut feeling for what the various stages feel like, nor how hard they are to get through.

I have always wanted to contribute to the NM effort, but I have never felt comfortable with trying to change -- or even participate as an account manager -- with so little understanding of what an applicant is going through.

One of the concerns with me trying to go through NM is that I would be taking valuable resources away from the list of real candidates who are stuck in the queue, and mostly for my own selfish reasons. However, I have been assured by current AM's that adding another candidate to their list would not significantly alter their workload, so I have decided to proceed.

So please, do help develop a test suite for Devotee by voting for your favorite color. Pretty soon I shall be looking for a sponsor for Devotee, and an advocate.


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: Crumbling of Rough consensus in Debian

Posted early Monday morning, January 2nd, 2006

Crumbling of Rough consensus in Debian

I am not the only one to be struck with the realization that there is very little effort at building consensus going on in Debian of late. Positions are presented, the active participants rapidly become polarized, and things rapidly head to counting hands; the largest of the polarized camps then carries the day. This certainly is not how things used to be.

And it is not as if the absence of an effort to come to a rough consensus has made the lists any less acrimonious; so this reduced tendency to enter into a dialogue with people that disagree with one has not made the lists any friendlier.

I think a couple of otherwise useful institutions have contributed to this malaise; the first is the constitution. Though accepted with relief and absolute unanimity (this is the only unanimous vote we have ever had), it has its flaws: it is written in pseudo-legalese, which practically invites picayune nitpicking and contentious debate over minor points of order. We spend far more time debating over the form of the trees, and miss the forest. At the time the constitution was being crafted, we were reeling from absolutely any rules governing conduct and any delineation of powers of people in the project, we had an informally defined Project leader, and we probably did not submit the constitution to the review it required, so starved were we for any semblance of order.

The second is stems from an constitutionally defined process, the general resolution: though something like a GR mechanism is a must for a project the size of Debian, the facility with which one can vote on multiple options simultaneously has lead to people just throwing up amendments that they like, and brute forcing the most popular amendment through a vote. There is no effort to compromise, and no effort to ameliorate the tyranny of the majority. There is no effort to even begin to find a common solution, instead people seem to be offended if an option exactly matching their sentiments is not on the ballot.

Added to the growing unease about the lack of communication or openness in the organization (with the vague muttering about the cabal in Debian), this lack of communication (which is what this tendency not to convince the rest of the project of the merits of one's ideas is, really) leads to us making flawed decisions -- and then scrambling to put Humpty Dumpty together again.

So what is to be done? 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. 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: First call for votes for the Sarge GR

Posted early Monday morning, January 2nd, 2006

First call for votes for the Sarge GR

I finally got time from my day job to set up the infrastructure for a vote. This entailed setting up a temporary vote key (the key I had set up earlier for the draft ballot had expired), adding the latest proposal (F). And set up the cron jobs, and so on.

Any way, head out over to the vote page for the juicy details. Take care in reading over the details, for this is not just a GR, it is a GR that changes foundation documents, and as the last vote has shown, any foundation doc change merits a modicum of diligence.


Monday 02 January
Link: Kernelsk modulesk and security

Posted early Monday morning, January 2nd, 2006

Kernelsk modulesk and security

Now that the tmpfs patch has come out in an official 2.6.9-selinux1.patch.gz, and blaisorblade issued a new SKAS patch, I decided to recompile kernels for my active everyday non server machines, and also update my SELINUX UML page. Of course, not everything goes off without a hitch, and this time it was the fact that I use proprietary binary only drivers (boo! hiss!) that brought me down. Of course, the newer version of the drivers is the one supposed to work with software suspend. I really need to re-examine whether running glxgears really fast at LUGs is worth this aggravation -- and the further tainting of my almost-vrms-clean box.

Oh, and at this point, I don't see any reason not to have SELinux compiled in for all my kernels -- while there is a performance hit and a scalability hit when SELInux is enabled, as far as compile-time enabling of SELinux is concerned is what performance hit is imposed by LSM itself. Setting the defaults for the boot-time parameter to 0 allows one to enable SELinux without rebuilding the kernel, while only imposing the overhead of LSM itself otherwise..

(The baseline performance hit seems to be around 7% (although it needs to be evaluated again after the code is tuned), although on some networking benchmarks it is as high as 20% for gigabit networking (no significant performance hit is seen at 100Mbps). Work is being done on both the baseline and networking performance for intensive workloads)

Oh, and what was the problem with the nvidia drivers? Well, I had everything working fine under 1.0.6111 (nvidia-glx and nvidia-kernel-source), but then 1.0.6629 came out, so I tried that. The new nvidia driver now pays a lot of attention to EDID values it now reads, and it turns out my laptop gave out hsync and vsync frequencies far lower than what I was using -- and nvidia decided to use the intersection of the ranges; thus deciding the best my laptop's display could take was 1280x1024. Of course, the native resolution is 1600x1200 (which is what I had been using), so now it tiled a 1280x1024 display across the physical 1600x1200 LCD.

Telling the nvidia driver to ignore EDID in XF86Config-4 did not help, as the driver proceeded to tile the display twice vertically (1600x600 times 2).

In the end, I had to downgrade back to the 1.0.6111 versions (have to downgrade both the kernel module and glx package, since mismatched versions just failed to load the nvidia.ko). I guess no software suspend for the laptop, unless I drop down to the console, and kill xdm. Kinda defeats the purpose, though.


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).


Monday 02 January
Link: Using SELinux UMLs: A recipe

Posted early Monday morning, January 2nd, 2006

Using SELinux UMLs: A recipe

I have blogged before about the trials and travails of trying to set up user-mode-linux, but the power of perseverance has changed things a bit. What has also helped is that both
SELinux and UML are getting incorporated in the mainline kernel, and I managed to research a load of places to look for more recent patches and fixes. To cut a long story short, I have created a recipe (see here for an older version) to create your very own UML + SELinux setup, complete with a root_fs. This is a recipe, rather than a HOWTO, since it provides a step by step recipe that should work, and does not pretend to be an answer in the general case -- though I hope it would still be a guide.

The reasons I embarked on this were manifold: firstly, I have given up on strict policy for my laptop for the time being, too many things have not yet been tuned for desktop machines. Maybe the targeted policy would work out better, but that has yet to be packaged (more on that later). Next, the packaged user-mode-linux died on me, and refused to work on 2.6.x hosts. Furthermore, I could no longer even build root file systems on my 2.6.x boxes -- so I decided to root around in mailing lists, find out the patches floating around to make the whole shebang work, and to provide the glue between the uml crowd and the SELinux crowd. This way, I can continue my SELinux experiments in sane, controlled, UML environments, play with policies and networks, all without compromising my real machine.

One can set up a whole network of UML machines on a single host, allowing for more complex attack vectors to be studied, as well as prototyping MAC policies to defend against the simulated attacks. The kernel can be debugged like any other process, profiled, run under gdb; one may set up break points in system calls and do analysis of kernel and security subsystems that would be impossible on a real hosted system.

I am also thinking of running services (like bind, postfix, sendmail) in a secure UML as opposed to semi-secure chroot jails (which do not come close to the isolation provided by a virtual machine running SELinux). Since the user-mode kernel is not running directly on the hardware, it has no access to it unless you provide it. This is important, since while mandatory access control prevents a large number of exploits, it can't protect against kernel exploits (buffer overruns, etc).

One can run the uml with the original root file system read-only, and an additional (initially empty) file that that gets populated when things are written to disk (Copy-on-write ). This OW file can be discarded, or merged with a copy of the original root file system, as desired. So it is very easy to see any changes that are taking place on the file system of the uml.

Using SKAS has several advantages: The UML kernel runs in an entirely different host address space from its processes. This solves the security and honeypot fingerprinting problems by making the UML kernel totally inaccessible to UML processes. Their address spaces are identical to what they would be on the host. This also provides a noticable speedup by eliminating the signal delivery that used to happen for every UML system call.

Once I had UML more or less working, along with a SELinux enabled root_fs, I decided to more or less automate the process, and document it, hence the web page you see above. At some point I shall enhance it to provide an out of the box honeypot variant -- complete with tty logging (well, once that is supported again by UML).

Since the logging is performed on the host system, the logging would be invisible to any attacker. Just sniffing the network doesn't help since that traffic is encrypted. So, you need to capture keystrokes by running something on the honeypot. This is problematic since you have to assume that it has been thoroughly compromised, so the logging mechanism may also have been compromised.

UML solves this problem with a patch to the tty driver which logs all traffic through tty devices out to the host. In contrast to the physical honeypot logging mechanisms, this is undetectable and unsubvertable. It causes no network traffic or anything else which can be detected from within the honeypot. It's also in the UML kernel, which means it can't be defeated by anything the intruder might do.

That was also the impetus I needed to incorporate patches that people had worked on to enable kernel-package uml and xen images (incidentally, I need feedback about this new functionality from xen and uml users).


Monday 02 January
Link: Welcome to Manoj's blog

Posted early Monday morning, January 2nd, 2006

Welcome to Manoj's blog

This has been a long time coming; I've wanted to set up something like this ever since I saw Alan Cox's diary. Now that Judy has expressed an interest in keeping a family blog, there was no excuse for further procrastination (not that that often stops one). Of course, exactly because there was no excuse for procrastination, I proceeded to procrastinate; I had to find a mechanism of determining pleasing color schemes which was better than trial and a lot of errors.


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