Amora ( A MObile Remote Assistant ) is a client/server suite which allows you to remote control an X desktop using a bluetooth enabled mobile phone. Initially there was only a Symbian client (running e.g. on nearly all Nokia E and N series phones), but J2ME clients are under developement, too. Then there is Tablet Amora (aka Tamora), an Amora proof of concept client for the Maemo platform which runs on internet tablets like e.g. the linux based Nokia N770, N800, and N810. Since Maemo isn t that far away from what runs on the OpenMoko, getting Tamora working on the OpenMoko, too, suggested itself. Maemo seems to use the deb package format, too, just slightly extended (e.g. by package icons), so it wasn t even that hard work to adapt the existing Maemo packaging to build, install and run on Debian, too. So that s how Tamora looks on the OpenMoko: The packaging is still far away from Debian standards (throws tons of lintian warnings and the source package generation is b0rked), so yet there are no prebuilt debs available, but you can checkout amora-client from the Subversion repository and build the package from there:

 $ svn checkout http://amora.googlecode.com/svn/trunk/amora-client/maemo/ amora-client
 $ cd amora-client
 $ debuild -uc -us
 $ cd ..
 # dpkg -i amora-client_0.1-2maemo+openmoko_all.deb

For running and installing tamora you need packages from the pkg-fso APT repository on alioth. And to build it, you need the libedje-bin which is available from the pkg-fso repository for at least the armel architecture, or else from Debian experimental. You can add these repositories to your sources.list as follows:

 # PKG FSO repository
 deb     http://pkg-fso.alioth.debian.org/debian unstable main
 deb-src http://pkg-fso.alioth.debian.org/debian unstable main
 # Debian Experimental
 deb     http://ftp.ch.debian.org/debian experimental main
 deb-src http://ftp.ch.debian.org/debian experimental main

Since Tamora is yet only a proof of concept client, currently only the following remote functions are available:

• pressing arrow key right/left
• pressing F5 (fullscreen for the OpenOffice.org Presenter)

This should though at least suffice for a presentation with the OpenOffice.org Presenter. To use Tamora to remote control your Debian laptop, you need a bluetooth dongle (or builtin bluetooth support) and amora-server installed as with the Symbian S60 (3rd Edition) Amora client, too. Update, 23:51 libedje-bin seem not available in the pkg-fso repository for every architecture. You ll also find it in Debian experimental. Updated the sources.list section above appropriately. Thanks to Sebastian Montini for pointing out this problem.

Being left in the IT medieval, thanks to my lovely telco, the only way I can (very far away) simulate a broadband connection, is stipulating a flat 56k contract (don't laugh, please). The name of this "offer" is TeleconomyInternet.

Do you think that firing up gnome-ppp on a Thinkpad T30 laptop would work at the first try? Of course not... The problem seems to be in the telephone number to call, that badly interact with SmartLink 56k modem. Here's the story, in case you'll find yourself in the same situation.

The modem on the T30 is:

$ lspci   grep Modem
00:1f.6 Modem: Intel Corporation 82801CA/CAM AC'97 Modem Controller (rev 02)

that is a SmartLink modem, supported well by sl-modem-deamon package and by alsa:

$ ps -eo command   grep slm
/usr/sbin/slmodemd --alsa -c ITALY modem:1

Remember to edit /etc/default/sl-modem-daemon file and set the right country for you.

Now, I installed gnome-ppp (just to try an easy tool), that uses wvdial under the hood.

wvdial auto-detection utility works quite well, and the found Init2 string:

ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0

works well if the number to call is a local one (I tried it before, and worked). Since Teleconomy provides a state-wide number (702...) with the above string the connection will fail with a sad:

NO CARRIER
No Carrier!  Trying again.

But there is a fix: first, the Init1 should be ATX3 (but it seems to be enbedded in the one below), and the last arguments must be changed (well, I think it has something to do with line speed (MS=34 will result in a 33.6k line) or protocol, but don't care too much as long as it works) resulting in this Init2:

ATX3Q0 V1 E1 S0=0 &C1 &D2 +MS=90

And remember to select the "stupid mode" in gnome-ppp, and you'll have a nice:

--> Initializing modem.
--> Sending: ATX3
ATX3
OK
--> Sending: ATX3Q0 V1 E1 S0=0 &C1 &D2 +MS=90
ATX3Q0 V1 E1 S0=0 &C1 &D2 +MS=90
OK
Modem initialized.
Sending: ATM1L3DT7020187187
Waiting for carrier.
ATM1L3DT7020187187
CONNECT 52000
--> Carrier detected.  Starting PPP immediately.
--> Starting pppd at Fri Dec 26 19:12:23 2008
--> Pid of pppd: 4870
--> Using interface ppp0
--> local  IP address ......

I'll move to ppp soon, since gnome-ppp seems to not understand "fsck, reconnect when disconnect, dude" option.

How nice is to be in the 21st century...

The Debian Python Modules Team is discussing which DVCS to switch to from SVN. Ondrej Certik asked how to generate a list of commiters to the team s repository, so I looked at it and got this:
emilio@saturno:~/deb/python-modules$ svn log egrep "^r[0-9]+ cut -f2 -d sed s/-guest// sort uniq -c sort -n -r
865 piotr
609 morph
598 kov
532 bzed
388 pox
302 arnau
253 certik
216 shlomme
212 malex
175 hertzog
140 nslater
130 kobold
123 nijel
121 kitterma
106 bernat
99 kibi
87 varun
83 stratus
81 nobse
81 netzwurm
78 azatoth
76 mca
73 dottedmag
70 jluebbe
68 zack
68 cgalisteo
61 speijnik
61 odd_bloke
60 rganesan
55 kumanna
52 werner
50 haas
48 mejo
45 ucko
43 pabs
42 stew
42 luciano
41 mithrandi
40 wardi
36 gudjon
35 jandd
34 smcv
34 brettp
32 jenner
31 davidvilla
31 aurel32
30 rousseau
30 mtaylor
28 thomasbl
26 lool
25 gaspa
25 ffm
24 adn
22 jmalonzo
21 santiago
21 appaji
18 goedson
17 toadstool
17 sto
17 awen
16 mlizaur
16 akumar
15 nacho
14 smr
14 hanska
13 tviehmann
13 norsetto
13 mbaldessari
12 stone
12 sharky
11 rainct
11 fabrizio
10 lash
9 rodrigogc
9 pcc
9 miriam
9 madduck
9 ftlerror
8 pere
8 crschmidt
7 ncommander
7 myon
7 abuss
6 jwilk
6 bdrung
6 atehwa
5 kcoyner
5 catlee
5 andyp
4 vt
4 ross
4 osrevolution
4 lamby
4 baby
3 sez
3 joss
3 geole
2 rustybear
2 edmonds
2 astraw
2 ana
1 twerner
1 tincho
1 pochu
1 danderson
As it s likely that the Python Applications Packaging Team will switch too to the same DVCS at the same time, here are the numbers for its repo:

emilio@saturno:~/deb/python-apps$ svn log egrep "^r[0-9]+ cut -f2 -d sed s/-guest// sort uniq -c sort -n -r
401 nijel
288 piotr
235 gothicx
159 pochu
76 nslater
69 kumanna
68 rainct
66 gilir
63 certik
52 vdanjean
52 bzed
46 dottedmag
41 stani
39 varun
37 kitterma
36 morph
35 odd_bloke
29 pcc
29 gudjon
28 appaji
25 thomasbl
24 arnau
20 sc
20 andyp
18 jalet
15 gerardo
14 eike
14 ana
13 dfiloni
11 tklauser
10 ryanakca
10 nxvl
10 akumar
8 sez
8 baby
6 catlee
4 osrevolution
4 cody-somerville
2 mithrandi
2 cjsmo
1 nenolod
1 ffm
Here I m the 4th most committer And while I was on it, I thought I could do the same for the GNOME and GStreamer teams:
emilio@saturno:~/deb/pkg-gnome$ svn log egrep "^r[0-9]+ cut -f2 -d sed s/-guest// sort uniq -c sort -n -r
5357 lool
2701 joss
1633 slomo
1164 kov
825 seb128
622 jordi
621 jdassen
574 manphiz
335 sjoerd
298 mlang
296 netsnipe
291 grm
255 ross
236 ari
203 pochu
198 ondrej
190 he
180 kilian
176 alanbach
170 ftlerror
148 nobse
112 marco
87 jak
84 samm
78 rfrancoise
75 oysteigi
73 jsogo
65 svena
65 otavio
55 duck
54 jcurbo
53 zorglub
53 rtp
49 wasabi
49 giskard
42 tagoh
42 kartikm
40 gpastore
34 brad
32 robtaylor
31 xaiki
30 stratus
30 daf
26 johannes
24 sander-m
21 kk
19 bubulle
16 arnau
15 dodji
12 mbanck
11 ruoso
11 fpeters
11 dedu
11 christine
10 cpm
7 ember
7 drew
7 debotux
6 tico
6 emil
6 bradsmith
5 robster
5 carlosliu
4 rotty
4 diegoe
3 biebl
2 thibaut
2 ejad
1 naoliv
1 huats
1 gilir

emilio@saturno:~/deb/pkg-gstreamer$ svn log egrep "^r[0-9]+ cut -f2 -d sed s/-guest// sort uniq -c sort -n -r
891 lool
840 slomo
99 pnormand
69 sjoerd
27 seb128
21 manphiz
8 he
7 aquette
4 elmarco
1 fabian
Conclusions:
- Why do I have the full python-modules and pkg-gstreamer trees, if I have just one commit to DPMT, and don t even have commit access to the GStreamer team?
- If you don t want to seem like you have done less commits than you have actually done, don t change your alioth name when you become a DD (hint: pox-guest and piotr in python-modules are the same person)
- If the switch to a new VCS was based on a vote where you have one vote per commit, the top 3 commiters in pkg-gnome could win the vote if they chosed the same! For python-apps it s the 4 top commiters, and the 7 ones for python-modules. pkg-gstreamer is a bit special

This weekend I had the pleasure of visiting my friend Kike in Iru a, a city I really like but had not been able to visit in five years. I spent three days with him, after a really awful Bilman trip during Friday night. The first thing that happened on Friday morning was quite unexpected. I went out, crossed a pair of streets to get to Carlos III, and going past the corner I found myself surrounded by all kinds of policemen: red, blue, green and yellow. There were press reporters all over the place, with TV and photo cameras ready to record something big. What the hell? I looked around, and there it was: a huge blue sign read Populares de Navarra, and Mariano Rajoy was seconds away from getting out of the new PP headquarters in Nafarroa. With a few dozen policemen looking at me in suspicion, and realising my current hair dress wasn't the most appropriate for that scenario, I decided to disappear as quickly as possible. Populares aside, the weekend was really productive. I had a great time trying to find the places I visited 9 and 5 years ago. It was sad to see the fantastic Iru ako Gaztetxea turned into an iron building surrounded by old, traditional houses in the centre of the city. With Kike, I had enough time to learn more about the origins of Iru a and the three cities from which it originated, and visit the Ciudadela. On Saturday, Kike, Ana and I went to have some fun on a snowy day around Orreaga and had dinner in a small town around the area, maybe Lintzoain? I'm afraid I forgot due to the mix of basque names in my head. We had dinner in lo viejo, where I spotted a poster of Solidari@s con Itoiz for the Itoitz hustu arte campaign, a copy of which I unsuccessfully tried to get in several places in the city. On Sunday, Kike and I took a bus to Donosti, and I travelled across the most beautiful highway I've seen. But of course, that was from my perspective seated in a bus. I can imagine the Leitzaran highway project must have been greatly contested by the people of the tiny towns nearby. The spoiled valleys and views must have been really impressive in the past and seem now irreversibly ruined by a scar and holes through the mountains. This was my first visit to Donosti, which held its annual Marathon, and were lucky to meet our friend Rub n when he was around kilometre 25 of his race. He managed to finish under 2:50, which was a bit better than what he aimed for in his first Marathon. Well done! The weather was horrible, and our visit to La Concha, the old harbour and the Casco Viejo was short, we were freezing and getting our feet wet. While I visited Donosti for the first time, Mikel Laboa, one of the most respected singers in the basque culture, was ebbing away. Laboa's songs always give me goosebumps, even if I need to read a translation for the basque lyrics. Many will remember his music from Julio Medem's documentary, La pelota vasca, featuring Txoria txori, which has become a symbol of basque culture over the years. Youtube has quite a few videos, and I'd recommend watching Txoria txori, Gure bazterrak, Lili bat or Baga biga higa performed by the Orfe n Donostiarra to name a few. Mikel Laboa, goian bego.

Space and place has long been important to hackers. Whether it was/is the university lab, the workplace, the hacker con, or the particularly high-tech city, hackers congregate and meet face to face, often and everyday. One semi-new development has been the explosion and proliferation of hacker labs and spaces, such as Noisebridge located in the Mission district of San Francisco Foulab in Montreal. I recently got back from San Francisco and was able to spend a few nights at Noisebridge and was jaw droppingly impressed. The space is, well, spacious and nice (and located right by the Bart, a real +++++), but more important is that it is a thriving collective with all sorts of geeky participants and they have just souped up the space with all sorts of equipment, from the usual suspects (lots of computers) to lots of electronic gear such as oscilloscopes. What I also was impressed by was not only the blizzard of events but the open and accessible nature of the organization, which seemed to sit in some contrast to NYC’s hacker collective, NYC Resistor. Like so many organizations in this metropolis, they apparently are lacking in space to grow and the word on the streets (which I cannot confirm or deny as I have had very little contact with them but have heard this repeatedly) is that the organization has had a tough time letting in new members. Some folks are understanding of this given their space limitation, others have been less kind, and have referred to the group as a clique. There are already a few other initiatives under way to find a larger space so as to accommodate a more open, participatory atmosphere for a hacker space (sign up for the email list here but I imagine that over time the culture and developments of NYC Resistor will also change as new spaces develops and do hope that this creates the conditions for more access rather than less (and again, I know next to nothing of the situation though I suspect space plays a real limiting role as it does with nearly everything else in NYC). And thankfully Rose White, a NYC-based sociology graduate student at CUNY, is paying close attention to the rise and development of these hacker spaces. She is well underway doing her dissertation dissertation on these hack spaces and I really look forward to her work. update: The Axis of Awesome is a hacker space in L.A. and as far as I am concerned, dons the best name.

Space and place has long been important to hackers. Whether it was/is the university lab, the workplace, the hacker con, or the particularly high-tech city, hackers congregate and meet face to face, often and everyday. One semi-new development has been the explosion and proliferation of hacker labs and spaces, such as Noisebridge located in the Mission district of San Francisco Foulab in Montreal. I recently got back from San Francisco and was able to spend a few nights at Noisebridge and was jaw droppingly impressed. The space is, well, spacious and nice (and located right by the Bart, a real +++++), but more important is that it is a thriving collective with all sorts of geeky participants and they have just souped up the space with all sorts of equipment, from the usual suspects (lots of computers) to lots of electronic gear such as oscilloscopes. What I also was impressed by was not only the blizzard of events but the open and accessible nature of the organization, which seemed to sit in some contrast to NYC’s hacker collective, NYC Resistor. Like so many organizations in this metropolis, they apparently are lacking in space to grow and the word on the streets (which I cannot confirm or deny as I have had very little contact with them but have heard this repeatedly) is that the organization has had a tough time letting in new members. Some folks are understanding of this given their space limitation, others have been less kind, and have referred to the group as a clique. There are already a few other initiatives under way to find a larger space so as to accommodate a more open, participatory atmosphere for a hacker space but I imagine that over time the culture and developments of NYC Resistor will also change as new spaces develops and do hope that this creates the conditions for more access rather than less (and again, I know next to nothing of the situation though I suspect space plays a real limiting role as it does with nearly everything else in NYC). And thankfully Rose White, a NYC-based sociology graduate student at CUNY, is paying close attention to the rise and development of these hacker spaces. She is well underway doing her dissertation dissertation on these hack spaces and I really look forward to her work.

Sebastian K gler dissects my dissection, except in fact he appears to be responding to a pile of stuff I didn't write.

First of all, Matthew assumes that the setting "powersave" will actually use the powersave cpufreq governor - citation needed.

the "conservative" governor, which indeed is an "ondemand" governor, meaning it gives you the extra needed CPU power when you ask for it - more slowly than ondemand does, resulting in extra power draw. Never run conservative unless your P-state latency is so high that ondemand won't work.

Powerdevil doesn't offer such option, so Matthew will be happy about this item - I didn't say it did. However, it is a common myth that thermal management is part of the job a power management policy should play. CPU frequency changing is a mechanism that can be driven by two policies - power management and thermal management. The fact that they share a mechanism does not mean that these policies should be conflated. Really. I wasn't just talking about Powerdevil here.

"3d takes more energy than 2d" is something I didn't actually say. I brought this up because various people have advocated disabling compiz to save power and because Powerdevil appears to have a "Disable Kwin compositing" button.

Lesson learned: Don't have an immediate emotional response to perceived criticism and fail to actually read what you're responding to. I would have commented on Sebastian's entry directly, but he forbids comments, so fuck that.

As a brief introduction to this - I first read through the Android code when interviewing with Google for an opening with the Android kernel team. I didn't get the job, and while I don't think anything that follows here is as a result of residual bitterness you might want to take some of it with a pinch of salt.

Anyway. Android is a Linux kernel with a heavily customised user layer that bears little resemblance to any traditional Linux system. I write in C because using pointer arithmetic lets people know that you're virile so this Java-like thing is of little interest to me and I'm going to ignore it and just look at the kernel, because after all that's what I'm paid to be good at.

The short summary of the rest of this post is that I'm not planning on giving up my iphone yet.

The Android kernel source lives in a git tree here. It can pretty much be logically split into two parts - the port to Qualcomm's MSM7xxx series chips and the special Android customisations. A bunch of the MSM7xxx port code has been merged through the ARM tree and is now upstream, and Brian Swetland seems to have been fairly active in looking after that. Full marks to Google there. This code is handy outside the Android world and benefits anyone wanting to run Linux on similar devices.

The Android-specific code is more... interesting.

As I mentioned, the Android application layer isn't Unix in any real sense. The kernel reflects this. It ranges from pragmatic (if hacky) approaches like encoding security policy and capabilities in group IDs that are hardcoded into the kernel through to implementing an in-kernel IPC mechanism (apparently related to the OpenBinder implementation from Palm, but judging by the copyrights a complete rewrite). To an extent, I'm fine with this. Something like Binder is pretty clearly not going upstream, so the fact that it engages in bizarre design decisions like sticking chunks of its interface in /proc is pretty irrelevant. What's more interesting is the code that should be generalisable.

I work on power management, so I'm always interested in what kind of power management functionality and interfaces people want. Plumbers included a nice discussion with someone from an embedded company I can't remember, culminating in us deciding that the existing cpufreq interface did what they wanted and so no new interfaces needed to be defined. Google was going to be an interesting case of a large company hiring people both from the embedded world and also the existing Linux development community and then producing an embedded device that was intended to compete with the very best existing platforms. I had high hopes that this combination of factors would result in the Linux community as a whole having a better idea what the constraints and requirements for high-quality power management in the embedded world were, rather than us ending up with another pile of vendor code sitting on an FTP site somewhere in Taiwan that implements its power management by passing tokenised dead mice through a wormhole.

To a certain extent, my hopes were fulfilled. We got a git server in California.

Android contains something called the android_power driver (ignore the references to CSMI, which is a piece of OMAP-specific hardware for communicating with the baseband - I'm not sure what they're doing in there). As far as I can tell, this is an interface that handles the device being locked and unlocked, and associated powering down of certain bits of hardware. Except it's shit. Devices register device handlers and a level where they wish to be suspended. There's no direct concept of intra-device dependencies so you end up with stuff like:

android_early_suspend_t early_suspend;
android_early_suspend_t slightly_earlier_suspend;

to deal with the fact that the MSM framebuffer driver depends on the MDDI driver having brought the link bank up and so needs its suspend method called before the MDDI driver but its resume method to be called after, and the only way to handle that is to register two methods - the "slightly earlier" one which has a suspend method but no resume, and the "early" one which has a resume method but no suspend one.

Of course, this also means that all of your device runtime power management policy ends up in the kernel. Userspace indicates what state it wants to go to and the kernel decides what's going to get powered down. This kind of coarse grained approach means that as your hardware setup becomes more complex you hit combinatorial explosion. Expressing all the useful combinations of hardware state simply becomes impractical if all you're exposing is a single variable. What would be more useful is the ability for userland to interact with individual pieces of hardware.

The amusing thing is that in many cases Linux already has this. Take a look at the backlight and LCD class drivers, for instance. They provide a trivial mechanism for userspace to indicate its desires and then modify the device power state. It's true that there are other pieces of hardware that don't currently have interfaces to provide this kind of information. And that's where cooperation with the existing community comes in. We've already successfully fleshed out interfaces for runtime power management for several hardware classes, with the main thing blocking us being a lack of awareness of what the use cases for the remaining classes are. But linux-pm has seen nobody from the Android team, and so we end up with a lump of code solving a problem that shouldn't exist.

When Robert Love gave his presentation on Android at Lugradio Live in SF back in April, he talked about how one of the reasons that Google weren't releasing the source for their userland stack until they shipped phones was to prevent it being seen as throwing unfinished code over the wall and then ignoring the community. It's unfortunate that this is almost exactly what's happened with their kernel. Right now the fact that Android is based on Linux is doing almost nothing to benefit the larger Linux community. What could have been a valuable opportunity for us to gain understanding of an interesting problem has instead ended up as yet another embedded vendor kernel, despite all the assurances I got from various people at Google.

Disappointing.

I’ve been remiss in pointing my readers recently to Zachary Schrag’s Institutional Review Blog, which patiently documents the overreach and misapplication of federal regulations regarding the protection of human subjects to the social and behavioral sciences, including research that by federal regulation is exempt from review by IRBs. While Schrag is cautiously optimistic that the new head of the Office of Human Research Protections will be an improvement, the continued domination of the process at most levels by biomedical researchers—along with the general sense that, as Schrag notes, “researchers cannot be trusted to apply the exemptions themselves”—is still troubling to those of us who want to conduct human subjects research, particularly secondary data analysis. Technically speaking (even though I dare say most social scientists observe this requirement in the breach), even the analysis of secondary data collected by others and fully anonymized before we see it (e.g. use of data such as the General Social Survey, American National Election Studies series, the Eurobarometer series, etc.) requires IRB oversight and approval beforehand.

One of the many interesting ideas in Peter F. Hamilton’s Night’s Dawn series [1] is that of Combat Wasps. These are robots used in space combat which may be armed with some combination of projectile weapons, MASERs, thermo-nuclear and anti-matter weapons. In a lot of science fiction the space combat is limited to capital ships, a large source of this problem is technological issues such as the Star Trek process of making models of ships - it’s too expensive and time consuming to make lots of small models. Shows such as Babylon 5 [2] have fighters which make more sense. Sustaining life in space is difficult at the best of times and it seems likely for battles in space to have few if any survivors. So sending out fighters allows the capital ships to have a chance to survive. I suspect that a major motivating factor in the space battles in Babylon 5 was making it fit on a TV screen. Dramatic TV portrayal of small groups of fighters engaging in a battle is an art that has been perfected over the course of 80+ years. It’s about individuals being shown, whether it’s riders on horseback, pilots of biplanes, or space pilots, it’s much the same. But a reasonable analysis of the facts suggests that without some strange religious motive adopted by all parties in a war (as used in Dune [3]) the trend in warfare is to ever greater mechanisation. So while a medium size starship might be able to carry dozens or even hundreds of fighter craft, if using small robotic craft then thousands of fighters could be carried. So the issue is how to effectively use such robots. It seems likely that an effective strategy would involve large numbers of robots performing different tasks, some would detonate thermo-nuclear weapons to remove enemies from an area while others would prepare to advance into the breach. The result would be a battle lasting seconds that involves large numbers of robots (too many to focus on in a group) while each robot matters to little that there’s no interest in following one. Therefore it just wouldn’t work on TV and in a book it’s given a couple of sentences to describe what would have been an epic battle if humans had done anything other than press the launch buttons. One of the many things I would do if I had a lot more spare time would be to write a Combat Wasp simulator. There are already quite a number of computer games based on the idea of writing a program to control a robot and then having the robots do battle. This would be another variation on the theme but based in space. In a comment on my previous post about programming and games for children [4], Don Marti suggests that a RTS game could allow programming the units. It seems to me that the current common settings for controlling units in RTS games (attack particular enemies, attach whichever enemies get in range, patrol, move to location, retreat, and defend other units or strategic positions) are about as complex as you can get without getting to the full programming language stage. Then of course if you have any real programming language for a unit then changing it takes more time than an RTS game allows, and if the programming is good then there won’t be much for a human to do during the game anyway. So I can’t imagine much potential for anything between RTS and fully programmed games. There is some interesting research being conducted by the US military in simulating large numbers of people in combat situations. I think that the techniques in question could be more productively used in determining which of the various science fiction ideas for space combat could be most effectively implemented.

• [1] http://en.wikipedia.org/wiki/Night’s_dawn


• [2] http://en.wikipedia.org/wiki/Babylon_5


• [3] http://en.wikipedia.org/wiki/Dune_universe


• [4] http://etbe.coker.com.au/2008/10/16/programming-games-children/

Share This

One ongoing problem with TCP networking is the combination of RPC services and port based services on the same host. If you have an RPC service that uses a port less than 1024 then typically it will start at 1023 and try lower ports until it finds one that works. A problem that I have had in the past is that an RPC service used port 631 and I then couldn’t start CUPS (which uses that port). A similar problem can arise in a more insidious manner if you have strange networking devices such as a BMC [1] which uses the same IP address as the host and just snarfs connections for itself (as documented by pantz.org [2]), this means that according to the OS the port in question is not in use, but connections to that port will go to the hardware BMC and the OS won’t see them. Another solution is to give a SE Linux security context to the port which prevents the RPC service from binding to it. RPC applications seem to be happy to make as many bind attempts as necessary to get an available port (thousands of attempts if necessary) so reserving a few ports is not going to cause any problems. As far as I recall my problems with CUPS and RPC services was a motivating factor in some of my early work on writing SE Linux policy to restrict port access. Of course the best thing to do is to assign IP addresses for IPMI that are different from the OS IP addresses. This is easy to do and merely requires an extra IP address for each port. As a typical server will have two Ethernet ports on the baseboard (one for the front-end network and one for the private network) that means an extra two IP addresses (you want to use both interfaces for redundancy in case the problem which cripples a server is related to one of the Ethernet ports). But for people who don’t have spare IP addresses, SE Linux port labeling could really help.

• [1] http://en.wikipedia.org/wiki/Baseboard_management_controller


• [2] http://www.pantz.org/hardware/ipmi/ipmiconflictwithrpc.html

Share This

One thing I am known to do is complain how the public/academic discourse surrounding/around technology/computers is overwhelmingly male (Lessig, Benkler, Zittrain, Shirky and I can go on and on). But one day I realized that if I am bothered by it, I should do more than talk the (often) empty talk of complaint. So I decided to enroll in a day long training for writing OpEds, which kicks off tomorrow. I am not sure if engaging in public debate is what I want to do, mostly because of piling more work and time commitments on a very full plate but I am starting to explore what it means and what it may take to leave the Ivory Tower. Here is a little more info about the OpEd Project:

The OpEd Project - featured by The New York Times, Feministing.com and Katie Couric on CBS News - is an initiative to expand public debate, with an immediate focus on targeting and training women experts across the nation to project their voices on the op-ed pages of major newspapers, online sites and other key forums of public discourse. The lack of diversity on the op-ed pages - which are a source for all other media - deprives the public of robust, democratic debate, especially important in this space which is intended to showcase divergent opinions. It also means we are only hearing from a tiny sliver of the nation’s best thinkers. Imagine a baseball team of only pitchers - how well would it do?

Our friend Jaap is besides a mathematical researcher also an aviator. Last weekend he took Erik, Judith and me on a flight from Hoogeveen (EHHO) in Drenthe to the island of Ameland (EHAL). It's a really nice experience to plan the flight on the map, fly over land, the Waddensea and the North Sea, hear the radio communications; and the check-in was a lot more relaxed compared to EHAM (Schiphol). On the other hand the on-board catering left something to be desired.

all pictures are here

One thing I am known to do is complain how the public/academic discourse surrounding/around technology/computers is overwhelmingly male (Lessig, Benkler, Zittrain, Shirky and I can go on and on). But one day I realized that if I am bothered by it, I should do more than talk the (often) empty talk of complaint. So I decided to enroll in a day long training for writing OpEds, which kicks off tomorrow. I am not sure if engaging in public debate is what I want to do, mostly because of piling more work and time commitments on a very full plate but I am starting to explore what it means and what it may take to leave the Ivory Tower. Here is a little more info about the OpEd Project:

he OpEd Project - featured by The New York Times, Feministing.com and Katie Couric on CBS News - is an initiative to expand public debate, with an immediate focus on targeting and training women experts across the nation to project their voices on the op-ed pages of major newspapers, online sites and other key forums of public discourse. The lack of diversity on the op-ed pages - which are a source for all other media - deprives the public of robust, democratic debate, especially important in this space which is intended to showcase divergent opinions. It also means we are only hearing from a tiny sliver of the nation’s best thinkers. Imagine a baseball team of only pitchers - how well would it do?

The strongly connected set of the GPG keys graph contains a bit more than 40000 keys now (yes, that’s a lot of geeks!). I wondered what was the biggest clique (complete subgraph) in that graph, and also of course the biggest clique I was in. It’s easy to grab the whole web of trust there. Finding the maximum clique in a graph is NP-complete, but there are algorithms that work quite well for small instances (and you don’t need to consider all 40000 keys: to be in a clique of n keys, a key must have at least n-1 signatures, so it’s easy to simplify the graph — if you find a clique with 20 keys, you can remove all keys that have less than 19 signatures). My first googling result pointed to Ashay Dharwadker’s solver implementation (which also proves P=NP ;). Googling further allowed me to find the solver provided with the DIMACS benchmarks. It’s clearly not the state of the art, but it was enough in my case (allowed to find the result almost immediately). The biggest clique contains 47 keys. However, it looks like someone had fun, and injected a lot of bogus keys in the keyring. See the clique. So I ignored those keys, and re-ran the solver. And guess what’s the size of the biggest “real” clique? Yes. 42. Here are the winners:

CF3401A9 Elmar Hoffmann
AF260AB1 Florian Zumbiehl
454C864C Moritz Lapp
E6AB2957 Tilman Koschnick
A0ED982D Christian Brueffer
5A35FD42 Christoph Ulrich Scholler
514B3E7C Florian Ernst
AB0CB8C0 Frank Mohr
797EBFAB Enrico Zini
A521F8B5 Manuel Zeise
57E19B02 Thomas Glanzmann
3096372C Michael Fladerer
E63CD6D6 Daniel Hess
A244C858 Torsten Marek
82FB4EAD Timo Weing rtner
1EEF26F4 Christoph Ulrich Scholler
AAE6022E Karlheinz Geyer
EA2D2C41 Mattia Dongili
FCC5040F Stephan Beyer
6B79D401 Giunchedi Filippo
74B11360 Frank Mohr
94C09C7F Peter Palfrader
2274C4DA Andreas Priesz
3B443922 Mathias Rachor
C54BD798 Helmut Grohne
9DE1EEB1 Marc Brockschmidt
41CF0322 Christoph Reeg
218D18D7 Robert Schiele
0DCB0431 Daniel Hess
B84EF12A Mathias Rachor
FD6A8D9D Andreas Madsack
67007C30 Bernd Paysan
9978AF86 Christoph Probst
BD8B050D Roland Rosenfeld
E3DB4EA7 Christian Barth
E263FCD4 Kurt Gramlich
0E6D09CE Mathias Rachor
2A623F72 Christoph Probst
E05C21AF Sebastian Inacker
5D64F870 Martin Zobel-Helas
248AEB73 Rene Engelhard
9C67CD96 Torsten Veller

It’s likely that this happened thanks to a very successful key signing party somewhere in germany (looking at the email addresses). [Update: It was the LinuxTag 2005 KSP.] It might be a nice challenge to beat that clique during next Debconf ;) And the biggest clique I’m in contains 23 keys. Not too bad.

In an hour the online part of this combined embedded+fai meeting in Badajoz in Extremadura, Spain, will sadly be over, but the sadness will hopefully be compensated by good food (yes, the food at the last dinner was great) and more fun! To me it were three intensive days (plus some two half days of intense travelling) which were really productive. This post is a summary of what I did here, to document how useful these meetings are. I'm only one person out of 18, who did some Debian work here, much more stuff was done, most of it I probably didnt even notice, as 14 people where working on embedded stuff, which I mostly ignored... ;-) That said, I think it was still very nice to have this meeting together, a.) because I'm quite interested in embedded stuff and b.) because the embedded crowd is a fun one to hang around with!

Right now I'm quite tired so that I dont fully remember what I have done on the first day :) It included uploading the DebConf7 mpeg videos which will now be used by Miguel Gea to create DVDs from those, so that he gets familar with the toolchain, so that he then can do the DebConf8 DVDs once those videos are (fully) ready. That will still take some time though, but hopefully not too long.

Unlike DebConf8 I also brought my fancy new fonera2 with me, in the hope to give it to someone to work on emdebian support for it. This is quite a longer road, as currently uclibc is not part of Debian, but thats only one step in this puzzle. Much to my joy Per Andersson took the opportunity to play with it and now took it home with him to document how to run Debian on it. I'm looking forward to see progress on this in the future ;-) Update: uclibc support is only needed for running Debian from the 4mb flash it has. But since it also has an usbport one can attach some storage there and run a full Debian system, just like on the nslug, which also has 32mb of RAM.

Unfortunatly I basically forgot about the FSG-3 I also took with me (which was for good reasons, one the second and third day I mostly did FAI work), but then I remembered 90min before the end, which was really too late. Narf. But Riku had a short look at it and told me one thing I didn't knew before: (at least) arm(el) kernels need to have the cpu id set in the kernel and the debian kernels don't have that, as they are build for more than one cpu type, so one has to prepend an arm assembler code instruction before running the kernel... I'm curious to do this soon :-)

But I have more hardware news to tell: C sar G mez Mart n (thanks for organizing this meeting, too!!!1) gave me back my OLPC laptop which I borrowed to him quite some time ago, so he could use it for a talk he gave at a university in Extremadura, so now I finally could give Andres Salomon new debian image for the XO a try. It was really nice to finally see a nice Debian gnome desktop on the device :-)

Today the FAI group, that was Sebastian, Michael, Thomas and me, also took a break to visit the Alcazaba de Badajoz (built around 1100, so roughly 900 years ago) which is an amazing building (thats why I linked to the spanish wikipedia entry as it has nicer pictures), from where you can see most of the city. I've been to Badajoz at least three times now and I'm really glad I finally did that, it's only 5min away from the office where the meeting was held and I highly recommend it to anyone going here.

Oh, and last and definitly not least I did a lot of work on FAI too. Besides discussing stuff which will hit planet after I posted this (hah! Michael already posted it, though without proper credit, so I will do a repost) I mostly reviewed changes and patches and discussed bugs, I didn't develop many patches myself (well, except one for the changelog..) but I've read every change at least twice, once as a commit msg and once in a full review. Plus many patches I read more often... all in all I think FAI is now in an great shape for lenny (which was the only thing we worked on during the weekend, we discussed some future plans, but work was only done for lenny), except that we want to another upload (with only documentation changes) after the upcoming one (which has quite some documentation changes already, but also some RC+important and some trivial bugfixes).

As you might have guessed, I started this entry on saturday and am finishing it now. According to the topic of the #extremadura2008 channel, which we created to coordinate between the groups, we also fixed 7 RC bugs (or 8? one should really document the bug numbers and not the number of bugs..) affecting lenny and 3 more which are only relevant to sid. Which is not as many as I would have liked to be fixed, but then, it wasn't a ("traditional") bug squashing party either. Which makes me wonder, are there any planned in the coming weeks?

So all in all I think this meeting was really very productive. Plus, I also enjoyed a special half an hour of real holidays: on saturday we had to leave lunch without having a chance to have a coffee afterwards, so I stumbled into a random cafe on the way to the venue. Turned out it was a very nice one, where due to its nice interiour I managed to reflect on life, 42 and all the rest almost immediatly. A totally unexpected but needed break. I wont say more here, because the thoughts and memories are really mostly relevant for me, but I'm really happy I found that space. DebConf8 and this meeting both were really fun, but I really didnt have a minute to reflect things. 30 minutes to do that is definitly not enough, but it was a good start. Now I just need to find another opportunity to continue with it. I hope this will happen before the next Extremadura meeting ;-)

The new release 0.1.1 of r (pronounced littler) was just rolled up. The only new feature is due to a suggestion by Paul Gilbert: r now reports the value of the optional status variable when calling q() at the end of a script:

$ r -e'q(status=42)'; echo $?
42


This can be very useful to signal exit codes and branching on those in other scripts or Makefile. We also applied a patch to manual page which adds some examples there (thanks, Seb!) and made some small changes to tests and examples. As usual, our code in our svn archive, on my r page, and in the local directory here. A fresh package is in Debian's incoming queue, and Jeff's littler page at Vanderbilt should reflect the new release soon too.

It's more or less four months since I proposed to resurrect our newsletter. We already released eight issues of the Debian Project News and work for the ninth issue has already started. So I guess it's time for a small "state of the DPN" speech, but since I'm not attending DebConf, you will have to read this mail instead ;) After having a rough start (and in fact missing some self-set deadlines and completely underestimating how much work is involved in such a kind of newsletter) we finally developed a - more or less - working flow of work (Which is by the way documented here). Speaking of the current state sadly means to confess, that our hopes to draw a lot of help from the community by using a system for drafting the news with a low entry barrier were not fulfilled. We actually had a good start, with good participation, but due to (I assume) the aforementioned initial difficulties participation in the creation of the DPN dropped considerably. Currently the workload of creating our bi-weekly newsletter is shared by only two people (that being Meike Reichle and myself), which is barely enough :( While we at least get a hint from time to time, what we should mention in the next issue, it rarely happens, that someone contributes by drafting a text -- which is the real work. (At this point a BIG "Thank You" to those who did! (See list bellow.) It's much appreciated!) We suffer especially, since although we are a two people team, we have in fact no redundancy, since real live issues affecting one of us will most likely affect the other one, too. Therefore we mostly concentrated our work on creating the next issues and getting them out in time, and didn't have time to answer all mails considering suggestions for changes and improvements (yet?). We are sorry, but at least we tried to read them briefly and keep them in mind when drafting the next issue. As a result of this we re-added the list of DSAs, WNPP and new and noteworthy packages due to popular demand. There are still a lot of unanswered mails not dealing with content, but with workflow issues / proposals (including changing from wiki.debian.org to a special ikiwiki instance). We are sorry, that we couldn't yet act on them and take appropriate measures, but be assured, they are not forgotten. Other issues the DPN currently have are "unwritten guidelines" regarding editorial choices of DSAs to be published and which packages to list in the "new and noteworthy package" section. Both is more or less done by our gut feeling. Speaking of problems the DPN are facing, we also need to mention translations of the DPN. The current workflow makes it difficult for translators of the DPN, since we often fail to get the final draft of the DPN ready in time to give translators a "head start" so the translated DPNs can be released together with (or at least with a as small as possible delay to) the English DPN. So here is a big call for help! We really need your help writing the DPN. (Monitoring lists and newstickers we don't monitor ourselves would be nice, too, but only add more work to us if you only give us pointers.) We will both be very busy with our real live the upcoming month, and are not sure how much time we can dedicate to the DPN. So please help us! The current draft for the next issue of the DPN is always available here . There should already be a todo list with pointers to interesting topics, which need to be written out. Some guidelines about style and content are available here. Last but not least, we would like to thank the following people who have contributed to the DPN so far:

• Adrian von Bidder
• Ana Guerrero
• Andre Felipe Machado
• Bjoern Boschman
• Graham Cobb
• Jeff Richards
• J rg Jaspert
• Jon Evans
• Julian Andres Klode
• Justin Rye
• Luca Bruno
• Martin F. Krafft
• Paul van der Vlis
• Paul Wise
• Raphael Hertzog
• Russell Coker
• Sebastian
• Stefano Zacchiroli
• Thomas Lange
• Wouter Verhelst

(Unfortunately we can't list those people, who contributed by translating the DPN, nor do we have a complete list of the native English speakers, who helped by proofreading. But we thank them nonetheless!)

I have been asked about the current status of Lenny SE Linux on the Desktop. The first thing to consider is the combinations of policies and configurations. I will number them if only for the purpose of this post, if the numbering is considered generally helpful it could be more widely adopted to describe configurations.

1. Default configuration. This has the default policy and is configured with all users having the domain unconfined_t and daemons such as POP servers are allowed to access home directories of type unconfined_home_dir_t. This allows such daemons to attack privileged user accounts.


2. Some restricted users. This is the same as above but with some users restricted. Daemons such as POP servers are only allowed to access the home directories of restricted users. This means that if a user is to have an unconfined account and receive email they must have two Unix accounts or receive their mail under /var/spool/mail. This is one setsebool command and one (or maybe a few) “semanage login -m” commands from the default configuration.


3. All users restricted. The system administrator has the domain sysadm_t and users have domains such as user_t. This requires a few more semanage commands. It is equivalent to the old strict policy.


4. MLS. This is anything that is based around the MLS policy.

Currently I have two Desktop machines running Lenny (a test machine and my EeePC) and one server. I have only just switched my test machine to enforcing mode so have no good data on it (apart from the fact that I can boot it up and login - which is always a good start). The server is running in permissive mode because I have not yet written the policy to allow the POP server to read from unconfined_home_dir_t. I could get it working by switching from level 1 to level 2 or 3, but I want to get level 1 server policy working for the benefit of others else first. My EeePC however is fully functional, I have been doing some work on it - that mostly means running a ssh client under GNOME but that’s OK (desktop environments such as GNOME and KDE are quite complex and demanding, getting a machine to boot and run such a desktop environment tests out many parts of the system). It’s only at level 1 for the moment because I want to get level 1 working everywhere before moving to the higher levels. I want to get things ready for real users ASAP. With the way the policy is managed now it will be possible to move from level 1 to 2 or 3 without rebooting or interrupting running services. So once users have systems running well at level 1 they can easily increase the security at a later date. The problems that I have had are due to text relocations in libraries (see my previous post about execmod permission [1]). I’ve filed bug report #493678 against libtheora0 [2] in regard to this issue and included a patch from Fedora (which disables the non-relocatable assembly code in question). It seems that upstream have some new assembler code to try and fix this issue, so hopefully we’ll have something that can make it into Lenny! I’ve filed bug report #493705 against libswscale0 for the same issue [3]. I included a patch to turn off the assembler code in question but that was not well received. If anyone has some i386 assembler skill and some spare time I would appreciate it if you could try and find a way to make the code position independent while losing little or no performance. One thing to note is that I am now using an Opteron 1212 (2.0GHz dual-core) system for compiling, I run the i386 DomU with a 64bit kernel (I expect that 32bit user-space runs faster with a 64bit kernel than a 32bit kernel), and the disks are reasonably fast. Even so it takes about 15 minutes to build libswscale0 and the other packages from the same source tree. Previously I was using a 1.0GHz Pentium-3 for my Lenny i386 development until I had the libswscale0 build process go for more than 90 minutes before running out of disk space! If your build machine is old enough to only be 32bit then you should probably plan on watching a movie or going to bed while the build is in progress. I have built packages that work around the above bugs and included them in my Lenny repository [4]. If you take the packages from that repository plus the Lenny packages then you should have a functional desktop system at level 1. I would appreciate it if people would start testing that and providing feedback. One important issue is the discovery of libraries that want shared stacks, text relocations, and executable memory. The deadline for fixing them properly is even more of a problem due to the number of people who have to be involved in a solution (as compared to the policy where I can do it on my own). One finally problem is a bug in xdm which causes it to give the wrong context for login sessions due to having an old version of the SE Linux related code [5]. Due to a combination of this and some policy bugs you can not login with xdm. This is not a hugely important issue as most people will use gdm (which has the newer patch) or kdm (which has no SE Linux patch but can use pam_selinux.so). Also another option is wdm which works with pam_selinux.so. I’ve had a response to my bug report suggesting that there’s a bug in the patch (which was taken from gdm so maybe there’s a bug in gdm code too). I haven’t responded to that yet as I’ve been concentrating on the things that will make the most impact for Lenny. At this stage I’m still unsure of when the release team will cut me off and prevent further SE Linux related fixes from going in Lenny. I need at least one more update to the policy packages before Lenny is released. I could release one right now with some useful improvements over what is currently in unstable, but am waiting until I get some other things fixed. If I get everything fully working at level 1 (both client and server) before Lenny then I will provide a similar status report for users and testers of levels 2 and 3. I don’t expect that I will even get a chance to test level 4 (MLS) properly before Lenny releases.

• [1] http://etbe.coker.com.au/2007/02/10/execmod/


• [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=493678


• [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=493705


• [4] http://etbe.coker.com.au/2008/07/31/installing-se-linux-on-lenny/


• [5] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=493524

Share This