Search Results: "ema"

5 May 2010

Gunnar Wolf: Post-apocalyptic times

Pestilence, War, Famine, and Death, the mythological Four Horsemen of the Apocalypse. Mexico's de facto president, Felipe Calder n, once again showed his involuntary aptitude for deep political analysis: On Monday, on a State visit to Germany, he declared Mexico has faced the Five Horsemen of the Apocalypse (second source, in English). I agree: One year ago, we were facing a health emergency, the AH1N1 epidemic, hence pestilence. Since he took power in December 2006, the president's main action has been the war on drugs, hence war. The country was the worst performing Latin American country in 2009, with our economy falling 6.5%, more than any other country, and prices have been really on the rise, hence famine. Finally, death... official numbers state that there have been over 22000 deaths in the "war on drugs" And merrily he stated that only 10% of that were civilians. Whatever that meant... But... What about the fifth? Who is he? A plausible hypothesis is offered by cartoonist El Fisg n in today's cartoon in La Jornada:
We don't know how he got here, but he is the most effective one Now... However good El Fisg n's analysis might be... Lets not get distracted with silly details. Hern ndez, another of La Jornada's great cartoonists, shows the hidden meaning:
We are over the apocalypse!
Does that mean we are facing the Final Judgement? The coming of the five horsemen of apocalypse can only mean... It is time for the Final Judgement and the end of time!
AttachmentSize
hernandez_20100505.jpg16.6 KB
fisgon_20100505.jpg28.11 KB

4 May 2010

Chris Lamb: Rotating email into your inbox using imapfilter

I'm not a fan of "life hacks", but I have the adopted the following automated processing of my email inbox: if I don't want to deal with a message today, I move it to (eg.) Mail.DELAYED.4 and it will reappear in my inbox automatically in 4 days. It is inspired by the Inbox Zero, tickler files and the Debian DELAYED queue. My implementation uses imapfilter. You'll need to tweak the move_messages syntax for lenny's version; the following works fine in squeeze and sid: 
mbox = IMAP  
    server = 'mail.server.net',
    username = 'username',
    password = 'password',
    ssl = 'ssl3'
 
num = 14
dst = 'INBOX'
prefix = 'Mail.DELAYED.'
for x = num, 1, -1 do
    mbox[prefix .. x]:select_all():move_messages(
        mbox[x == 1 and dst or prefix .. (x - 1)]
    )
end
The messages are moved when I'm (hopefully) asleep: 
# m h dom mon dow command
  0 6 *   *   *   imapfilter -c /path/to/delayed.lua >/dev/null

Wouter Verhelst: On clue and opinions

How does one define one's "national identity"? One way is to look at where a person is born. By that definion, I could be called Flemish, Belgian, or European, whatever you think about it. Another way to look at it is how one feels about one's own identity. This, of course, is a much more accurate way to describe a person; and by that definition, I am either Belgian or European. I do not feel any affinity with much of the so-called "flemish" identity, nor do I wish to be associated with it any more than is strictly necessary. Obviously, some people feel different about that for themselves. This I can understand. In fact, the statement to feel more Belgian than Flemish is probably not one that is very common in this general area. I am not stupid; I know that Belgium is not a Nation (it is a state, but that is a different matter). I just do not feel a lot of warm fuzzy feelings about Flanders. Naturally, other people have other feelings about that. This, too, I can understand. The logical result of the above is that my personal opinions about the somewhat convoluted politics in this country are not shared by many; that when I state my opinion, I may expect opposition, or at the very least someone stating why they disagree with me. This, of course, I can also understand. But what I cannot understand is that every time I state my opinion, someone must come out and insult my intelligence by telling me I "do not have a clue". Please do not mistake my disagreement for misunderstanding. Martijn asks me to "check the facts". Let's do that, shall we?
  1. There's been a judgement by the constitutional court that the current situation regarding which party may run for election in the BHV region is unconstitutional.
  2. One group of politicians wishes to resolve this issue by splitting the BHV region in two. That would certainly solve the issue.
  3. Another group of politicians dislikes this solution. They may be willing to go along, but they want other concessions before they will do so. This is what I referred to when I said that there were "a huge heap of all kinds of side issues" in my previous post.
  4. The first group does not wish to make such concessions. Some of their numbers have even stated in the press that there is no need to make them, because, given the first point, there's only one solution and that is to split.
That last point is, of course, complete and utter bullshit. It would hold merit if there was only one way to solve a constitutional crisis; but by definition, there are always at least two ways: one is to change the law to comply with the constitution, the other is to change the constitution to make the law no longer be unconstitutional. So a group that feels strongly about one of these two possible solutions should be prepared to negotiate with the other group so as to hammer out an agreement that benefits both parties. In some cases, this will mean doing things that they do not completely like; but if they're not willing to do that, at all, they have no business being politicians. For the longest time during the early negotiations, however, both parties have stubbornly refused to even acknowledge the other position, let alone talk about it. Now, for clarity, I'm not advocating that the latter of the two options in that previous paragraph is what should happen. Frankly, I don't even care what happens, so long as they manage to resolve the issue at hand in some way. What I do care about, however, is that this country has been in a near-constant state of stalemate over these past few years for an issue that only matters to politicians; I don't care who or what a group of people in a (to me) obscure part of the country can vote for. This country needs a stable government which can act on things that actually matter. Like, say, the international economic crisis of the past two years; I think it matters much more whether the man in the street has a job than whether John Q. Politician will past these next elections.

3 May 2010

Matthew Garrett: PCI power management problems

I've previously written about some of the implementation details of runtime PCI power management. One of the key aspects for PCI devices is that the PME line on the device be able to generate a wakeup event. Unfortunately, it turns out that since Windows makes no use of this functionality at present, some vendors have started failing to wire this up. This is problematic because the device itself still announces PME support and will even raise a PME signal when it gets woken up - but it's pretty much screaming as hard as it can and nobody's listening because somebody's replaced the air with cheese.

Bother, etc.

The obvious question is what to do next. We could poll all the PCI devices every second or so to see if there's a PME status register that's been set. This would be reasonably cheap (we're going to wake up at least once a second on x86 anyway, so it makes no real difference to power consumption) but would introduce obvious latency in the wakeup path. This would be fine for certain types of situation (you're probably not going to be too sad if your SD reader takes a second longer to notice a card insertion) but not others (if an sdio wireless card generates a wakeup interrupt then we really ought to do something about it in a more sensible timeframe). A second is to force users to pass a boottime argument to enable this at all. That kind of sucks.

The third possibility is limited to a subset of hardware, but does allow the introduction of some kind of elegance into what would otherwise be one of those nightmarish scenarios that makes me consider taking up farming instead. If we can trigger a PME ourselves then we can test whether the line is connected. This doesn't appear to be possible on SDHCI but the spec for firewire makes it look like we can do it there - one of the interrupt sources is the port enable/disable register, and we can hit toggle that ourselves. I haven't actually tested this yet, but if it works that would let us make this determination.

It's depressing that doing anything interesting with power management is still heavily determined by what Microsoft have bothered to implement - to the extent that on some machines (hello, Thinkpads) there are no GPE methods at all for PME signals and you don't get runtime power management at all. The only thing that saves us is that (a) it's pretty hard to be able to screw up stuff that's already all glued into one chip package, so integrated stuff like USB should be fine anyway, and (b) PCIe does this as part of the normal traffic stream so there's no way to get that wrong. Unless you're still missing the GPE methods for the signals (hello, Thinkpads) in which case you get nothing unless the native PCIe signalling works. I suspect that we can always force that, so there's some hope yet.

In summary, then: dispassionate.

2 May 2010

Dominique Dumont: Improve config file upgrades Ep 01

Hello The GSoC project Krzysztof and I are working aims to facilitate configuration upgrade during package upgrades. Most of the cases, this upgrade should not require any input from the user, even if the user had previously customized his configuration file. Currently configuration upgrade may ask questions to the user which may be hard to answer for most non-technical users. For more details see PackageConfigUpgrade on Debian wiki. (If you are not familiar with upgrade issues, you might want to read this page.) At the 2 extremes of upgrade tools, we have: Each tool has its own advantages and drawbacks. On the plus side of diff3 tools : On the other hand, here are the issues with diff3 based tools: For more details on diff3 issues, see Benjamin Pierce s paper (thanks to David Lutterkort from Augeas for the info) On the other end of the spectrum, Config::Model pros are: But, Config::Model main problem is: diff3 tools is lackluster for users. While Config::Model puts too much strain on packagers because it requires configuration models where all parameters are defined and declared in the model. For fast evolving projects, this can be a huge recurrent task (been there, done that for Xorg) . (Well, this recurrent task is a problem until doc, implementation and config model can be extracted from a single meta-description But I digress, this may be a project for GSoC 2011 :-p ) So, this GSoC project (for 2010) aims to find a compromise between these 2 extreme cases. On Config::Model, I ve always had a drawer statement whenever I was asked why Config::Model does not handle unknown parameter:
a configuration file cannot be validated if an unknown parameter can t be distinguished from a user typo.
This stance is fine for casual user interaction on a stable system: an unknown parameter is most likely an error. And the user must be warned of his error as soon as possible. For a stable distro release, packagers should have the time to provide complete models, so basing upgrade on complete models should be possible (famous last words ?). On the other hand, a lot of configuration upgrades will be done on unstable systems where software evolve quite fast, where models will likely fall behind software evolutions. Another shorcoming of my drawer statement is that it assumes user interaction where erroneous input is more likely. In case of configuration upgrades, there should be no user interaction. And we can assume that the config file to be upgraded was used (and thus validated) by the old version of the software. So unknown parameters should be tolerated and managed as best as possible. Now, the big question is: how ? In all attempts I ve seen in managing upgrades that goes beyond diff3 tools, the configuration is stored as structured data. Sometimes this structure can be infered from the configuration file syntax (shell vars, INI files, YAML, XML), sometimes not (sshd config file). In the latter case, some structural knowledge must be built in the upgrade tool. Currently, Config::Model is designed to bring a complete description of the structure and semantics of a configuration file. This is perceived as bringing too much structural and semantic knowledge ( too semantic ). So the maintenance cost is perceived as too important. That may be right or wrong, but that does not matter. Perception is more important here. So, let s figure out a way to reduce the amount of work required to perform upgrades (you may want to read a little bit more on configuration model creation before going on ) One possibility would be to support configuration models that allow unknown leaves in nodes. Such a model would provide a kind of fallback leaf description. Something like: this parameter is unknown, let s assume it s a simple string value . Let s consider sshd_config example to see how such a behavior would pan out for some upgrade scenarios. sshd model is made of 2 main classes:
- Sshd
- SshdMatchElement The second one contains all parameters allowed in a Match class (in fact, Match parameter is the only one in sshd that defines a new hierarchical level. All other parameters are simple leaves). Now let s consider typical upgrade scenarios from old version (with old models) to a more modern version. Let s assume that the model is lagging behind and the model does not follow sshd evolutions. So Config::Model will face 3 upgrade cases (extracted from sshd config history):
  1. Unexpected parameter that are actually simple leaf parameters. E.g. introduction of ClientAliveInterval.
  2. Obsolete parameters that should be migrated. E.g KeepAlive is renamed into TCPKeepAlive
  3. New structural parameters (introduction of Match element)
So what would happen with a model allowing unknown parameters but lacking specific instructions for these upgrades:
  1. ClientAliveInterval value would be kept. :-)
  2. KeepAlive would be kept as is.TCPKeepAlive would also be kept. No migration is performed, but the configuration would be good. As long as sshd supports the old parameter, we re good. :-/
  3. Without knowledge of the structure brought by Match parameters, Config::Model would consider that parameter in Match block would duplicate parameters in the main block and remove the duplicate. User data may be lost. :-(
So, there s not silver bullet. Let s resume what we ve learnt: Next step is to figure out what would happen if the same strategy is applied to other types of configuration files. But that will be for another blog. All the best

Petter Reinholdtsen: Forcing new users to change their password on first login

One interesting feature in Active Directory, is the ability to create a new user with an expired password, and thus force the user to change the password on the first login attempt. I'm not quite sure how to do that with the LDAP setup in Debian Edu, but did some initial testing with a local account. The account and password aging information is available in /etc/shadow, but unfortunately, it is not possible to specify an expiration time for passwords, only a maximum age for passwords. A freshly created account (using adduser test) will have these settings in /etc/shadow: 
root@tjener:~# chage -l test
Last password change                                    : May 02, 2010
Password expires                                        : never
Password inactive                                       : never
Account expires                                         : never
Minimum number of days between password change          : 0
Maximum number of days between password change          : 99999
Number of days of warning before password expires       : 7
root@tjener:~#
The only way I could come up with to create a user with an expired account, is to change the date of the last password change to the lowest value possible (January 1th 1970), and the maximum password age to the difference in days between that date and today. To make it simple, I went for 30 years (30 * 365 = 10950) and January 2th (to avoid testing if 0 is a valid value). After using these commands to set it up, it seem to work as intended: 
root@tjener:~# chage -d 1 test; chage -M 10950 test
root@tjener:~# chage -l test
Last password change                                    : Jan 02, 1970
Password expires                                        : never
Password inactive                                       : never
Account expires                                         : never
Minimum number of days between password change          : 0
Maximum number of days between password change          : 10950
Number of days of warning before password expires       : 7
root@tjener:~#
So far I have tested this with ssh and console, and kdm (in Squeeze) login, and all ask for a new password before login in the user (with ssh, I was thrown out and had to log in again). Perhaps we should set up something similar for Debian Edu, to make sure only the user itself have the account password? If you want to comment on or help out with implementing this for Debian Edu, please contact us on debian-edu@lists.debian.org. Update 2010-05-02 17:20: Paul T tterman tells me on IRC that the shadow(8) page in Debian/testing now state that setting the date of last password change to zero (0) will force the password to be changed on the first login. This was not mentioned in the manual in Lenny, so I did not notice this in my initial testing. I have tested it on Squeeze, and 'chage -d 0 username' do work there. I have not tested it on Lenny yet. Update 2010-05-02-19:05: Jim Paris tells me via email that an equivalent command to expire a password is 'passwd -e username', which insert zero into the date of the last password change.

1 May 2010

Sean Finney: Nouveau, Gallium3D, and Compiz on Debian

update: 20100503: It's been brought to my attention that there might have been a regression in one of the libraries, mesa, maybe, so that master might not be as reliable a reference point for this guide. so, just in case, here are the commit hashes that were used from the different projects: for the non-git-savvy: git checkout -b mybranch <hash> we now return to your regular broadcasting... A week or two ago I figured it was about time that I took the plung and tried out the latest nouveau drivers from experimental on my laptop. Unfortunately, it meant bidding adieu to compiz (apart from the bling it does actually provide some pretty damned useful features). I thought I'd give it a shot at least for a while on principal, since I've always had to think of the nvidia drivers as a necessary evil, and their lack of proper xrandr support is really, really annoying. Since then I haven't noticed any problems, apart from the following message after every suspend/resume: 
[  931.213239] Uhhuh. NMI received for unknown reason 80 on CPU 0.
[  931.213240] You have some hardware problem, likely on the PCI bus.
[  931.213242] Dazed and confused, but trying to continue
No idea what's causing it, but otherwise the system is stable and functional. If anyone knows what can be done about this, I'd appreciate hearing from you. My graphics card, by the way: 
01:00.0 VGA compatible controller: nVidia Corporation G72M [Quadro NVS 110M/GeForce Go 7300] (rev a1)
In the time since then, the nouveau driver has made its way into unstable, and a lot of distros (ubuntu, fedora, ...) are even using it as the default driver. So before going any further with the 3d/compiz stuff, I highly recommend that you get the packaged version working first. This will not only make sure that the basic driver works, but it will also make recovery/rollback a lot easier. Since it's all packaged in the standard repositories, it's not much harder than installing a few packages and editing a few files... so come on give it a try :) Getting the 2d driver working in Debian sid Really, this is so easy it's hardly worth writing up, but i'm running with the -v flag this morning... Make sure you don't have any reference to nvidia in /etc/modules or other places that might cause it to be automatically loaded. Then remove the proprietary glx bindings, which would otherwise interfere with the nouveau driver. 
sudo apt-get remove nvidia-glx
Next, you'll need to install a kernel that includes updated drm support. Normally this would require a kernel >= 2.6.33.1, but the debian kernel maintainers have graciously backported this code to the 2.6.32-4 kernel package. note this isn't the default kernel version in testing/unstable at the time of writing so you have to explicitly install it along with the nouveau driver. 
sudo apt-get install linux-image-2.6.32-4-amd64 xserver-xorg-video-nouveau
If you are already running this kernel and using the proprietary nvidia drivers, via module-assistant or otherwise, you /might/ need to uninstall them first. On my system I left them installed in the old kernel version but did not install them on the new kernel version. Required xorg configuration I don't believe that nouveau is picked by default if available at the time of writing, so you have to have the following in your xorg.conf: 
sudo sh -c "cat > /etc/X11/xorg.conf" << EOF
Section "Device"
    Identifier     "nVidia Corporation G72M [Quadro NVS 110M/GeForce Go 7300]"
    Driver         "nouveau"
EndSection
EOF
This was all I needed to do, apart from rebooting into the new kernel. For those who don't want to venture outside the packaging system, this is about as far as you can go for the time being. Though really, if you're bothering to read this far along, you're probably more interested in what comes next :) Getting 3d working (without voiding your distro warranty) So I thought I'd give the 3d-accelerated gallium a go. Their wiki page certainly makes one think twice, but at this point I was seriously fiending to get my bling back (well, the compiz scale plugin, anyway) and figured it wouldn't hurt too much to try. Via google and trawling around in various forums I found a number of how-to documents for getting Gallium3d on debian/ubuntu systems, but most of them recommended doing things in a way that wasn't easily reversible and that could totally hose your system in a not-so-hypothetical worst-case scenario. It's pretty hard to roll back a make install done into /usr, for example, and subsequent package upgrades can leave your system even worse off as they will probably clobber half of what you just did, leaving the other half totally broken. And if you have a laptop which requires the gui for networking (i.e. network-manager), then fixing/rolling-back the changes is not entirely trivial, since you'd likely have to re-download the various drm/mesa/xorg packages. So enter the tried and true unix utility stow (apt-get install stow, of course). stow is a utility that lets you install software into arbitrary folders, and then manage the system-wide installation of the software via a farm of symlinks pointing at the installed location. It's probably more well known among the sysadmin crowd than the desktop user crowd, but it's incredibly useful for the task at hand as it will let us easily install multiple copies of different software in a way that's very easy to update and/or roll-back. RTFM stow(1) for more information. So, on to the juicy stuff... Install needed software, remove problematic packages, setup, etc At least on my system, I had to remove libdrm-dev to keep things from accidentally linking against it instead of the updated version that we install later on below. There's probably a way to override this with CFLAGS but I figure this is simpler. 
sudo apt-get remove libdrm-dev
sudo apt-get install stow build-essential xorg-dev git-core libtool mesa-common-dev automake autoconf 
mkdir ~/nouveau
Compile a linux-2.6.34 RC kernel 
cd ~/nouveau
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
cd linux-2.6
git remote add -f nouveau git://anongit.freedesktop.org/nouveau/linux-2.6
git checkout -b nouveau-master nouveau/master
make menuconfig
Enable device drivers -> staging drivers -> nouveau. Make any other changes you might want to make (I just took defaults for everything else). 
make deb-pkg
The linux-firmware-free debian package ships some of the same stuff from the generated linux-firmware-image package. I decided to opt for the upstream firmware, though I'm not sure that this is necessary: 
sudo apt-get remove linux-firmware-free
sudo dpkg -i ~/nouveau/linux-image*.deb ~/nouveau/linux-firmware-image*.deb
sudo update-grub
Install a copy of dri2proto 
cd ~/nouveau
git clone git://anongit.freedesktop.org/xorg/proto/dri2proto
cd dri2proto
./autogen.sh --prefix=/usr/local/stow/dri2proto-20100428
sudo mkdir -p /usr/local/stow/dri2proto-20100428
sudo make install
sudo stow -d /usr/local/stow dri2proto-20100428
Install a cutting-edge version of libdrm 
cd ~/nouveau
git clone git://anongit.freedesktop.org/git/mesa/drm/
cd drm
./autogen.sh --prefix=/usr/local/stow/drm-20100428 --disable-intel --disable-radeon --enable-nouveau-experimental-api
make
sudo mkdir -p /usr/local/stow/drm-20100428
sudo make install
sudo stow  -d /usr/local/stow  drm-20100428
Likewise for mesa 
cd ~/nouveau
git clone git://anongit.freedesktop.org/git/mesa/mesa
cd mesa
./autogen.sh --prefix=/usr/local/stow/mesa-20100428  --enable-debug --enable-glx-tls --disable-asm --with-dri-drivers= --enable-gallium-nouveau --disable-gallium-intel --disable-gallium-radeon --disable-gallium-svga --with-state-trackers=glx,dri --with-demos=xdemos,demos,trivial,tests
make
sudo mkdir -p /usr/local/stow/mesa-20100428 
sudo make install
sudo stow -d /usr/local/stow mesa-20100428
And now the xorg driver... 
cd ~/nouveau
git clone git://anongit.freedesktop.org/git/nouveau/xf86-video-nouveau/
cd xf86-video-nouveau
./autogen.sh --prefix=/usr/local/stow/xf86-video-nouveau-20100428
make
sudo mkdir -p /usr/local/stow/xf86-video-nouveau-20100428
sudo make install
sudo stow -d /usr/local/stow xf86-video-nouveau-20100428
Configuration Configure xorg to look in alternate location for xorg modules and set up DRI 
sudo sh -c "cat > /etc/X11/xorg.conf" << EOF
Section "Files"
    ModulePath "/usr/local/lib/xorg/modules,/usr/lib/xorg/modules"
EndSection
Section "ServerFlags"
    Option "GlxVisuals" "all"
Endsection
Section "Device"
    Identifier     "nVidia Corporation G72M [Quadro NVS 110M/GeForce Go 7300]"
    Driver         "nouveau"
EndSection
EOF
I've /heard/ that disabling TV out is a necessity on some cards, though I haven't seen this myself: 
sudo sh -c "cat > /etc/modprobe.d/nouveau.conf" << EOF
# not entirely sure this is necessary, but heard it helped with vsync
options nouveau tv_disable=1
EOF
Finally, the one thing that can not be done in /usr/local is making the nouveau DRI driver available. From what I could tell the path that mesa uses to find the DRI libraries is hard-coded (corrections welcome). Since you won't already have this file (otherwise, why would you be following along here?), just drop in a symlink to the file in /usr/local: 
sudo ln -s /usr/local/lib/dri/nouveau_dri.so /usr/lib/dri/
Finally, reboot, and hope for the best :) Riding the bleeding edge: how to upgrade later on Again, stow really shows its usefullness here. Using drm as an example case, upgrading an individual component would look something like: 
cd ~/nouveau/drm
git clean -dfx
git pull
today= date +%Y%m%d 
./autogen.sh --prefix=/usr/local/stow/drm-$today --disable-intel --disable-radeon --enable-nouveau-experimental-api
make
sudo mkdir -p /usr/local/stow/drm-$today
sudo make install
sudo stow -d /usr/local/stow -D drm-20100428
sudo stow -d /usr/local/stow  drm-$today
Note how the old version is still installed, so you can switch components around pretty freely. Abort! Abort!: How to roll back changes In case your system becomes totally unusable, or you've decided that you just want to go back to the safe and cozy world of what's provided by the debian packages, simply do the following: Assuming that you're using the nouveau driver from unstable, this should be all that is necessary. Conclusion Overall impression I am very, very happy with the resulting setup. I was led to believe that this whole thing was much more unstable and unusable than it actually is! While there are certainly some glitches and missing features, I feel comfortable enough using it that I don't have plans to switch back. But if I find myself in a situation where I can't use the new setup, rolling back shouldn't be a problem either. I figure I'm happy with what I have now and it will only get better. What works, at least to a "kinda works" level. What still doesn't work Further reading, references Thanks A couple shoutouts to those who helped me with this on the way: Feedback / Corrections Unforunately, I've had to disable comments for the time being due to overwhelming quantities of spam. So please drop me a line via email or on IRC (seanius on oftc/freenode).

30 April 2010

Biella Coleman: Baby Panda wants YOU to submit to DEBCONF



bad mood destroyer, originally uploaded by the biella.
People s the deadline is fast approaching. Don t worry though, the best ideas come under deadlines and your proposal need not be lengthy. So get those typing hands out and submit a proposal (a few sentences suffices) for a presentation! The annual Debian conference is being held in NYC this year. First time
setting foot in the imperial empire. Are you doing something related to
free software that might be interesting to share, show off or talk about
at Debconf? I bet you are! We are looking for art installations,
performances, movie screenings, maybe you are wanting to host a
roundtable/panel discussion, coordinate a workshop (you dont have to
know the subject deeply to do this!). I know the deadline is soon, but don t let that scare you. The
submission requirement bar is very low, and we are flexible! here is the submission information: [1] ********************* Calling all potential contributors to DebConf10! One more week until
the final submission deadline! The DebConf team is excited to announce that we are now accepting
proposals for contributions to this year s Debian conference! We
invite you to submit proposals for how you would contribute until the
deadline: soon There are many ways you can contribute, you could present a technical
paper, host a panel discussion, put on a tutorial, do a performance,
an art installation, a debate, host a meeting (BoFS, or Birds of a
Feather Session), or other possibilities that you devise. This year we
are also accepting proposals for tracks=E2=80=94a thematic grouping around a
particular subject, and people to coordinate those tracks. If you are
looking for ideas of things that you could contribute, or have ideas
for things that you would like to see happen at DebConf, have a look
at the Contribution Brainstorm[0] page. DebConf talks will be broadcast live on the Internet where possible,
unless otherwise requested. Videos of the talks will be published on
the web along with the presentation slides and papers. =3D=3D Step 1. Submit Proposal =3D=3D Proposals should provide an overview of your proposed contribution,
similar to an abstract, and be no more than 600 words. Since
contributions can cover a range of issues, please describe what your
proposal covers, be it political (Free Software, law, advocacy,
access, etc.), technical (d-i, OpenPGP, etc.), social (Debian
structures and groups). It s okay to hit all three of these. Your
proposal should also include some information on why you re qualified
to present, or coordinate this topic. For example, you can include
links to posts you have made to Debian mailing lists or other material
that indicates your qualifications. Proposals and their abstracts will
be accepted until May 1st, 2010, 23h59 UTC. To submit your proposal, go to Penta[1] and register as an
attendee. Once you are registered, there is a Submit a proposal
link. You will see your proposal on the site. You can choose between
different presentation types. If you are unsure what type you should
use, please read our glossary of definitions[2]. If it s not there for
some reason, or you have questions, please contact us immediately at
mailto:talks@debconf.org. =3D=3D Step 2. Committee Review =3D=3D The review committee for this year will make its decision by May 1st,
2010. All correspondence will be done by email. =3D=3D Step 3. Paper Submission =3D=3D Like last year, we are asking for papers to be submitted along with
the presentations. A full paper is optional, however we strongly
encourage you to submit one if possible as we intend to provide
written information along with transcripts of the sessions for later
viewing. Having written papers in advance will allow us to get
translations done to help non-native-English speakers feel more
comfortable with the topics presented. Papers are due by July 1st,
2010, and should cover the topic in reasonable depth (3 pages A4 text,
plus pictures and diagrams). We will use LaTeX to typeset the
proceedings. Please submit your paper formatted in LaTeX. Should you
be unfamiliar with LaTeX earlier submission in plain text is also
fine. =3D=3D Step 4. Live Presentation =3D=3D Longer presentations may have a break in the middle and should include
workshop items that directly involve the participants. If using slides
or any other presentation, please consider that your audience will
consist of people who use free software, and your choice of
application to prepare and display the slides should reflect this if
at all possible. =3D=3D Fine Print Publication Rights =3D=3D DebConf requires non-exclusive publication rights to papers,
presentations, and any additional handouts or audio/visual materials
used in conjunction with the presentation. The authors have the
freedom to pick a DFSG-free license for the papers themselves and
retain all copyrights. The presentations will be recorded, and may be
broadcast over the Internet. Any copies of the presentation will be
made available =3D=3D Failure to Submit =3D=3D In the event that a deadline is missed we reserve the right to revoke
any offer to present. =3D=3D About DebConf =3D=3D The annual DebConf conference is a technical and social forum for
Debian developers, sponsors, affiliates, and friends. It allows
various groups within Debian a chance to come together, network, and
share their work. Until we see you in the big city,
DebConf Talks Team [1] introduction written by Micah Anderson

Asheesh Laroia: Mailing lists can wait

Most of my email comes to me via mailing lists. When someone asks a question or starts a discussion, I used to jump at the chance to be the first to reply with an answer. I don't want to unsubscribe; often, I know something that can move the conversation forward or help someone out. But I'm trying to allocate more time for myself away from computing these days. So now I let these discussions mature a little before I see them. All mailing list messages are delivered to a folder called OneDayDelayed. Every night, my server moves those messages to my INBOX. If someone else has already contributed what I would have, perfect! If not, I still have a chance to participate. Sometimes, if I have a long backlog of email, I disable that cron job, sometimes for up to two weeks. Being able to turn the cron job on and off really helps; when I have time to deal with mailing lists, I do. Otherwise, I know the messages will be there when I do have time. Since this OneDayDelayed change, I've gained have a sense of calmness and distance from them. I like that. (Note that if you add me to the CC: line of a mailing list thread, I will see your message immediately, for better or for worse.)

Russell Coker: Link Within

Good Things about LinkWithin For the last 10 weeks I ve been using the LinkWithin.com service to show links to other blog posts at the end of each post (the links are only shown to visitors of my blog not in the RSS feed, so people who read my posts through RSS syndication will miss this). The service shows excerpts of pictures from my blog at the bottom of each post to entice readers into reading other posts. When you click on a LinkWithin icon on my blog you visit a LinkWithin page that redirects you back to my page, so people who use that show up as new visitors being referred by LinkWithin. Currently this month LinkWithin is the fourth highest referrer to my blog, below Google, Reddit, and WebWombat.com.au so it is clearly doing some good in enticing people to read other posts that they might not otherwise read! Bad Things about LinkWithin The first problem with LinkWithin is that the Wordpress plugin was written by people who don t know much about Wordpress. Unlike every other plugin I use it doesn t support configuration options for the user in the database but instead has it hard coded in the PHP code! When you download a plugin from their web site it creates a custom zip that includes the PHP code automatically generated just for you! I have some friends using the same web server as me for running blogs, and I have to tell them you can install any plugin apart from LinkWithin it works for no-one but me . The next problem is that LinkWithin advertises that it will display related posts, it seems to be doing a poor job of that on my blog although admittedly only a minority of my blog posts have pictures so this limits what it has to work with. This has however inspired me to use more pictures in my posts. Another problem is that it produces web pages that are not valid XHTML, the following patch fixes this. --- /tmp/linkwithin.php 2010-02-22 02:09:47.000000000 +0000
+++ ./wp-content/plugins/linkwithin/linkwithin.php 2010-02-22 02:17:29.000000000 +0000
@@ -15,7 +15,7 @@
global $post, $wp_query, $linkwithin_code_start, $linkwithin_code_end; $permalink = get_permalink($post->ID);
- $content .= '<div class="linkwithin_hook" id="'.$permalink.'"></div>';
+ $content .= '<div class="linkwithin_hook" id="'.str_replace('/','-',$permalink).'"></div>';
$content = linkwithin_add_code($content);

return $content;
@@ -26,13 +26,13 @@
global $post, $wp_query, $linkwithin_code_start, $linkwithin_code_end; if ($wp_query->current_post + 1 == $wp_query->post_count)
- $embed_code = '<script>
+ $embed_code = '<script type="text/javascript">
<!-- //LinkWithinCodeStart
var linkwithin_site_id = 151382;
var linkwithin_div_class = "linkwithin_hook";
//LinkWithinCodeEnd -->
</script>
-<script src="http://www.linkwithin.com/widget.js"></script>
+<script src="http://www.linkwithin.com/widget.js" type="text/javascript"></script>
<a href="http://www.linkwithin.com/"><img src="http://www.linkwithin.com/pixel.png" alt="Related Posts with Thumbnails" style="border: 0" /></a>';
$content .= $embed_code;
Finally LinkWithin shows up badly on the FireBug analysis (see my previous post about using Firebug to speed up my blog) [1] see the below picture for details. As an aside, given that Google recommend Firebug it is rather ironic that Google Adsense related URLs cover the majority of the Firebug issues that are not caused by LinkWithin. demonstration of how Linkwithin lowers my page speed What Next? I ve sent email to the LinkWithin people about all these issues other than the FireBug problem reports, given that they haven t responded to some suggestions for over 10 weeks it seems hardly worth my effort in informing them of other issues. I m thinking of trying OutBrain.com again. 18 monthe ago I tried OutBrain but never got it working due to technical issues and then forgot about it. It has some similar features and may work better at least it has tech support people who respond to queries!

29 April 2010

John Goerzen: Some More Gopher Data

Yesterday, I invited you to download a piece of Internet history. Today I have unearthed a bit more data to add to it. There is a new torrent with 1.5GB more data (3GB uncompressed). This includes the FTP site from boombox.micro.umn.edu/pub/gopher, which was a large collection of Gopher client and server software. Also included was ftp.unicom.com/pub/gn-tools, the old GN server, and wiretap.area.com. This last site was mirrorable via FTP, and included the UMN Gopherd .cap and .Links files, so it can be served up via PyGopherd. The full contents are available in my post to the Gopher mailing list. Incidentally, thank you to everyone that has helped seed, download, store, host, and otherwise preserve the 2007 archive. It is much appreciated. I have contacted several institutions recommended to me in comments or emails to try to arrange a stable long-term home for the data. Enjoy.

Sylvestre Ledru: Google Summer of code at Scilab

First, a quick news. Scilab 5.2.2 has been released a few days and he now available in the Debian archive (Debian Unstable for now).
It is mostly a performance improvements and bug fixes release. See the changelog. Second, for a second year, Scilab is part of the Google Summer of Code v2010. I am admin (and also mentor) this year again.
Google just released the list of accepted students. We have 9 students (against 7 last year). 2 are working on experimental projects, the other should have a finished result by the end of the GSoC. Extends Scilab UI Control - Han Dong
Extension of Scilab User Interface construction (uicontrol) by providing more elements (tree, image display, etc). Simulink import in Xcos - Jerzy Zagorski
Importation of most of the Simulink schemas from Xcos. Cumulative distribution function improvements - Michael Zhang
Improvement and extension of the current cumulative distribution functions (CFD) into Scilab. Metanet and Boost.graph - Bal a Rai evi
Extension of the Metanet capabilities in term of graphs by Boost.graph SOAP Client/server - Artem Glebov
Making available from Scilab both SOAP client and server capabilities as an ATOMS module. Database module + fuzzySQL - Igor Gridchyn
Allow to access to most databases systems from Scilab. Based on this work, the FuzzySQL will be introduced, a SQL extension to allow flexible conditions in queries. Python import - Baozeng Ding
Introduction of a mechanism to load and use Python code (objects in particular) from Scilab. Experimental projects:
Use Eigen into Scilab - Joseph Fahnbulleh
Base some components of the Scilab core code on the Eigen library which is a state-of-the-art C++ linear algebra library. This work will be a joint mentoring between Ga l Guennebaud from the Eigen team and Scilab R & D team. Hybrid Automata module - Ievgen Ivanov
Provide a convenient environment for direct modeling of hybrid automata in Scilab/Xcos.

27 April 2010

Matthew Garrett: Radeon reclocking

Alex released another set of Radeon power management patches over the weekend, and I've been adding my own code on top of that (Alex's patches go on top of drm-next, mine go on top of there). I've left it stress-testing for a couple of hours without it falling over, which tells me that it's stable enough that I can feel smug. This is a pleasing counterpoint to the previous experiences I've been having, which have been rife with a heady mixture of chip lockups or kernel deadlocks. It turns out that gpus are hard.

There's a few things you need to know about gpus. The first is that if they're discrete devices they typically have their own memory controller and video memory. The second is that there's an impressive number of ways that you can end up touching that memory. The third is that they tend to get upset if something tries to touch that memory and the memory controller is in the middle of reclocking at the time.

The first and most obvious use of video memory is by the gpu itself. Accelerated operations on radeon are carried out by sending a command packet to the command processor. This is achieved by sharing a ring buffer between the cpu and the gpu, with the gpu reading packets out of that ring buffer and performing the operations contained within them. Many of these operations will touch video memory (that being the nature of most things you want a gpu to do), and if that happens bad things occur. Like the card locking up and potentially taking your PCI bus with it.

So, obviously, we don't want that to happen. The first thing we do is take a mutex that blocks any further accelerated operations from being submitted by userspace. Then we wait until we get an interrupt from the gpu telling us that the display engine has gone idle. The problem here is that we don't have a terribly good idea of how many more operations there are to complete and we don't know how long each of those operations is going to take, but this is less bad than some of the alternatives[1]. Jerome Glisse has some ideas on how to improve this to require less waiting, but the effects should still be pretty much invisible to the average user.

So we've stopped the command processor touching ram. Everything's good, right?

Well, not really. The obvious problem is that users typically want to display something, so there's a separate chunk of chip that's repeatedly copying video memory over to your monitor. That's got to go too. Thankfully, there's a convenient bit in the crtc registers that lets us turn that off, but the pretty unsurprising downside is that your screen goes blank while that's happening. So we don't want to do that. Instead, we try to perform the reclock while there's nothing being displayed on the screen - that is, while we're in the screen region where a crt's electron gun would be scanning back from the bottom of the screen to the top. It turns out that rather a lot of display assumptions depend on this happening even if there's no crt, no electron gun and no thick sheet of glass with a decent approximation of vacuum behind it, so we get to do this even if we're displaying to an LVDS. And we have about 400-500 microseconds to do it - an almost generous amount of time.

So we ask the hardware to generate an interrupt when we enter vblank and then we reclock. Except the hardware has an irritating habit of lying - sometimes we get the interrupt a line or two before vblank, sometimes we get it after we've already gone out the other side. Vexing, and not entirely solved yet - so sometimes you'll still get a single blank frame during reclock. But there are plans, and they'll probably even work.

At this point the acceleration hardware isn't touching the memory and the scanout hardware isn't touching the memory. Except it still crashes under some workloads. This one took me longer to track down, but the answer turned out to be pretty straightforward. Not all operations are accelerated. When they're not accelerated they have to be done in software. That means that the CPU has to write to the video memory itself. I'm sure you can see where this is going. This was fixed without too much trouble once I'd finished picking through the driver to work out every location where objects might be mapped into the CPU's address space, at which point it's a simple matter of unmapping them and blocking the fault handler from remapping them until the reclock is finished. Linux, thankfully, has lots of synchronisation primitives. And now everything works.

Except when it doesn't. This took a final period of head scratching, followed by the discovery that ttm (the memory allocator used by radeon) has a background thread that would occasionally fire to clean up objects. And by clean up objects, I mean change their mapping - which means updating their status in the gart, which means touching video memory. So, let's block that. And that tripped me off to the fact that even if it couldn't submit new commands, the CPU could still create or destroy objects - with the same consequences.

So, once all of these are blocked, video memory is quiescent and we can do what we want. And we do, at least once I'd sorted out the bits where I was taking locks in the wrong order and deadlocking. Depending on the powerplay tables available on your card we'll chose different rates and so your power savings will vary heavily depending on the values that your vendor provided, but the card I'm testing on sees a handy 30W drop at idle. Right now we're only changing clocks and not dropping voltage so there's potentially a little more to come.

While getting this stable was pretty miserable, the documented entry points for clock changing made a lot of this easier than it would otherwise have been. It's also probably worth noting that Intel's clock configuration registers are entirely missing from any public documentation and the dirver Intel submitted to make them work in their latest chips appeared to have been deliberately obfuscated, so thanks to AMD for making all of this possible.

[1] It's possible to insert various command packets that either indicate when they've passed or stall until a register value gets updated, but these either cause awkward problems with the cp locking or mean that the gui idle functionality never goes idle, so they're not ideal either.

26 April 2010

Biella Coleman: Progress Island!

For like the millionth time, I am back in Puerto Rico, AKA Progress Island, at least according to MST 3000. My mom came down with severe pneumonia and I am waiting it out until she is more stable. Today, my friend forwarded the MST 3000 video as she suspected it would cheer me up and she was right. I have not seen anything so fine in a long time. If you know nothing of PR-America relations, it won t be (that) funny but if you do, it is sharp as a nail. Oh and the 70s music adds a real nice almost porn-like touch. Make sure to watch part two so you can sugar frost your damn corn flakes, you filfthy American pigs!

Biella Coleman: Progress Island!

For like the millionth time, I am back in Puerto Rico, AKA Progress Island, at least according to MST 3000. My mom came down with severe pneumonia and I am waiting it out until she is more stable. Today, my friend forwarded the MST 3000 video as she suspected it would cheer me up and she was right. I have not seen anything so fine in a long time. If you know nothing of PR-America relations, it won t be (that) funny but if you do, it is sharp as a nail. Oh and the 70s music adds a real nice almost porn-like touch. Make sure to watch part two so you can sugar frost your damn corn flakes, you filfthy American pigs!

Luca Falavigna: waf removal, almost done

Some months ago I wrote about my intention to drop waf from Debian. Some bugs I filed were fixed shortly after they appeared, while I managed to upload three NMUs to fix remaining bits (flowcanvas, patchage and raul), all uploaded to DELAYED/15 to give maintainer time to react. In the meantime, jack-audio-connection-kit was uploaded build-depending on waf, this brings in a little unplanned delay, but I provided a workaround to get rid of it, it just need to be improved. I want to remove waf before Squeeze is released, so please do not upload more packages build-depending on waf, this way you can help its removal. Thank you!

Obey Arthur Liu: Welcome to our 2010 Debian Google Summer of Code students!

I d like to extend a warm welcome to our selected students for the 2010 Debian Google Summer of Code! They should pop up on Debian Planet soon and you re welcome to come talk to them on #debian-soc on irc.debian.org Aptitude Qt by Piotr Galiszewski, mentored by Sune Vuorela Qt GUI for aptitude. Currently, KDE users need to use Aptitude via the console interface, or install the newly developed GTK frontend, which does not fit well into KDE desktop. Making Qt frontend to Aptitude would solve this problem and bring an advanced and fully Debian-compliant graphical package manager to KDE. Content-aware Config Files Upgrading by Krzysztof Tyszecki, mentored by Dominique Dumont When a package deliver configuration files, the problem of merging user data with new configuration instructions will arise during package upgrades on users systems. Sometimes merging can be done with 3 way merge, but this process does not insure that the resulting file is correct or even legal. This project intends to create standards, tools an heuristics to make the scary config file conflict resolution debconf prompt a thing of the past. Debbugs Bug Reporting and Manipulation API by David Wendt Jr., mentored by Bastian Venthur Currently debbugs supports a SOAP interface for querying Debian s Bug Tracking System. Unfortunately this operation is read-only. This project would create an API for debbugs which supports sending and manipulating bug reports, without having to resort to email. This project does not intend to replace email as mean to manipulate the BTS but rather to enhance the BTS to allow other means of bug creation and manipulation. Debian High Performance Computing on Clouds by Dominique Belhachemi, mentored by Steffen Moeller The project paves a way to combine the demands in high performance computing with the dynamics of compute clouds with Debian. Combining the Eucalyptus cloud computing infrastructure with the TORQUE resource manager and preparing the components for dynamically added and removed instances provides the user with a attractive high performance computing environment. Such a system allows users to share resources with large compute centers with minimal changes in their workflow and scripts. Debian-Installer on Neo FreeRunner and Handheld Devices by Thibaut Girka, mentored by Gaudenz Steinlin This project aims to improve the installation experience of Debian on handheld devices by replacing ad-hoc install scripts by a full-blown and adapted Debian-Installer. The Neo FreeRunner is used as it is the most convenient and open device from a development standpoint, but other devices will also be explored. Hurd port and de-Linux-ization of Debian-Installer by J r mie Koenig, mentored by Samuel Thibault The primary means of distributing the Hurd is through Debian GNU/Hurd. However, the installation CDs presently use an ancient, non-native installer. The goal of this project is to port the missing parts of Debian-Installer to Hurd. To achieve this, all problematic Linux-specific code in Debian-Installer will be replaced by less or non-kernel dependent code, paving the way for better support of other non-Linux ports of Debian. Multi-Arch support in APT by David Kalnischkies, mentored by Michael Vogt Hardware like 64bit processors are perfectly able to execute 32bit opcode but until now this potentiality is disregard as the infrastructure tools like dpkg and APT are not able to install and/or solve dependencies across multiple architectures. The project therefore focuses on enabling APT to work out good solutions in a MultiArch aware environments without the need of hacky and partly working biarch packages currently in use. Package Repository Analysis and Migration Automation by Ricardo O Donell, mentored by Neil Williams Emdebian uses a filter to select packages from the main Debian repositories that are considered useful to embedded devices, excluding the majority of packages. The results of processing the filter are automated but maintaining the filter list is manual. This project seeks to automate certain elements of the filtering process to cope with specific conditions. This project will also generalize to more elaborate and intelligent algorithms to improve the transitions of the main Debian archives. Smart Upload Server for FTP Master by Petr Jasek, mentored by Joerg Jaspert Making packages upload smarter, more interactive and painless for uploaders by switching from anonymous FTP and Cron jobs to a robust protocol and modern package checking and processing daemon. This daemon would test early and report early, saving developers time. More details coming soon on http://wiki.debian.org/gsoc Congratulations everyone and have a fruitful summer!

Wouter Verhelst: Yanina Wickmayer, heroine of the Belgian fed cup team

Last weekend, I went to the Grenslandhallen in Hasselt, to see Belgium compete against Estonia in a Fed Cup tie of the World Group playoffs. The winner of this tie would gain a seat in the top-tier World Group next year, which opens the possibility of winning this competition. The Belgian team was the strongest possible one, with all four best Belgian female tennis players Yanina Wickmayer, Kim Clijsters, Justine Henin, and Kirsten Flipkens. On paper, the team should not have had any problems beating the Estonian team. Unfortunately, Justine fractured her pinky finger during practice on wednesday; and while it did not make it impossible for her to play, it did reduce her fitness somewhat, which meant that on Saturday, Kim and Yanina had to defend the Belgian colors. They did and won, but then Kim injured some muscle in her foot, which made it hard for her to walk on Sunday, let alone play. With only Justine, Yanina, and Kirsten available, coach Appelmans chose to put Justine on the field. Though she made a valiant effort, she unfortunately did not manage to beat an unleashed Kaia Kanepi, who it must be said played a terrific match. As such, it fell on Yanina to bring home the tie in the fourth singles rubber against Maret Ani. Being a bit nervous in the start of the first set, she made some unnecessary errors; but after a few games, she came through and started to play much better. Unfortunately, by that time the score was already at 5-1. Yanina won her first service game of the match to bring it to 5-2, but it wasn't enough, and Ani won the first set somewhat easily. She couldn't put anything on the table against a storming Wickmayer, however, and after two more sets, the outcome of the match and, by extension, the tie was clear: a win for Belgium. I can't help but note that Wickmayer has been a great player for the Belgian fed cup team these past few years, however. Since her first Fed Cup participation in 2007, she holds what is, given her ranking at the time, a rather impressive 9-4 win-loss record in Fed Cup. If it wasn't for Wickmayer, the Belgian team would not be where it is now. It was Wickmayer who won her three matches against Canada, one as part of a doubles team, to prevent demotion from world group II to the Europe/Africa zone back in 2009, with a 3-2 score. It was Wickmayer who won the crucial third rubber against higher-ranked Radwanska in February to beat Poland, with the latter even holding the home field advantage. And it's now been Wickmayer who won two of the three rubbers against Estonia that were needed to win the tie. So Congrats, Yanina!

Christoph Egger: [Review] AI Touchbook

Having my primary working Computer, a Lenovo Thinkpad, going into repair at the end of December I finally got up to ordering on of those TouchBook ARM based netbooks I was looking at for some time. After some processing time it finally got shipped in April and arrived here last Monday, time to write up my first impressions. Some words about the Hardware. The TouchBook ships with a so called "Beagle Board" featuring a OMAP3 Processor, ARM Cortex A8 running at 600MHz, 512MiB of RAM and a 8GiB SD Card for storage. It has a 8.9" touch screen and comes with USB and Bluetooth Sticks for wireless connectivity. The Display part contains all the needed Hardware and is detachable from the bottom that is just a keyboard sitting on the secondary Battery. You can open the Top to get at 4 intern USBs (3 USB-A and one Mini-USB) where 2 of these spots are occupied already for wireless networking and Bluetooth. First experience The TouchBook comes with an US Power Adaptor only so when I got the device I was running for some tiny Adaptor to get the plug into a normal EU Power Outlet (it's incredibly hard to get one for this Direction while it's easy to get some travelling stuff to plug EU Hardware into various different Outlets!). When I finally booted it the first thing you'll notice is the touch interface for the bootloader. That's quite a difference to all-text-based old grub! The shipped SD Card offers 3 Operating Systems, one custom Linux that might well be interesting to the average User, a Ubuntu Karmic that really OK for a Debianoid Hacker- both running a XFCE Desktop - and a Android that is really slow and doesn't seem to be good at anything. Needless to say I sticked with the Ubuntu for now. What to not expect Well this is a 600MHz CPU with half a Gig of RAM running of a SD Card. So don't expect it to be good at anything that can profit from today's High-End Hardware. The good Points First of all, I have to admit that the touch screen is a neat interface, way superior to the Touchpad Area you'll normally find on a Notebook - at least if you use the stylus. It's quite different from the inside-the-keyboard trackball the thinkpads have of course. The Website claims 10h of Battery life and while I've emptied the battery much faster under certain workloads (e.g. Playing cards) it does hold that promise with emacs fired up in org-mode, IRCing on a server over SSH and the mandatory wireless working. Same for a always-on on campus day which just works. Again putting the screen on the keyboard the wrong way 'round will give you a touchscreen tablet with the keyboard out of your way, an ideal configuration for playing. And I have to admit playing games like gtkballs or aisle riot real fun. So much fun actually I'm currently thinking on whether it would be feasible to get openpandora working on it. What I'm really missing There are two Properties that are really lacking from the device which would make it (in my personal opinion at least) a whole lot better: A simple Ethernet controller I could use to go online when sitting in the server room doing some maintenance without taking my WRT with me and some slot to store the stylus when not using it where it's easy to get out (currently I'm having it in my wallet). Then there's something (maybe a Kernel Bug): The Wireless is unable to find any new Access Point after disconnecting from some and walking out of reach from that. Force-unloading the kernel module and waiting 30 minutes worked for me multiple times but that's purely inacceptable. Finally there are some minor glitches. The shiny red cover just gets dirty every time you touch the thing and the Keyboard is really small (what a surprise on a 9" device) and has some of the special Keys (like the Home key) located at unusual spots (Page-Up/Down only available through the FN modifier). Shift and End at the right side are also labeled opposite from their actual function (at least on Ubuntu). The last ugliness is the top part battery only charging when the device is running, which means you"ll have the TouchBook running all night to get the battery charged and the Battery Monitor not working at all (at least in the current version of the operating systems). Where to go now I've not yet come around to really play with the operating system (apart from installing wicd, urxvt-unicode and awesome getting the most needed of my working environment). As I'm a Debian Developer I'll definitely need a Debian running on it (although I was told it'll be slow with software compiled for armv4te) and, as it needs to be running all night anyway, I'll try out gentoo pending another SD Card for experiments. Secondly there's currently no useable conforming Common Lisp Implementation in Debian for armel as far as I can tell. As arm was already working it shouldn't be that hard, let's see if I can change that but feel free to join me! Final Notes I was thinking of some mobile-ish note-taking device and remote ssh terminal for University which the device clearly can do even for 10h away from any power plug while being some non-standard non-x86 device to toy on (It's actually my second armel next to the sheeva plug mounted on my window board. As a final Remark: This blogpost was written on the TouchBook hacking some markdown into emacs while traveling by train to Erlangen where I study on Sunday Night after having read some chapters of Cory Doctorow's Little Brother on my E-Slick E-Book reader and finished later in my Room. Maybe I'll find some time to write a review for this device as well one day!

25 April 2010

Daniel Kahn Gillmor: Talks and tracks at debconf 10

I'm helping out on the talks committee for debconf 10 this summer in NYC (so yes, i'm going to be here for it, even though i don't have that little badge thingy). This is a call for interested folks to let us know what you want to see at debconf! Talks If you haven't already, submit your proposal for a talk, performance, debate, panel, BoF session, etc! We know you've got good ideas, and the final call for contributions went out yesterday, due in less than a week. Please propose your event soon! Tracks Also, we want to introduce Tracks as a new idea for debconf this summer. A good track would thematically group a consecutive set of debconf events (talks, panels, debates, performances, etc) to encourage a better understanding of a broader theme. For this to work, we need a few good people to act as track coordinators for the areas where they are knowledgeable and engaged. A track coordinator would have a chance to set the tone and scope for their track, schedule events, assemble panels or debates, introduce speakers, and report back at the end of debconf to the larger gathering. We also hope that a coordinator could identify potential good work being done in their area, encourage people to submit relevant events for debconf, and shepherd proposals in their track through the submission process. Are you interested in coordinating a track on some topic? Or do you have a suggestion for someone else who might do a good job on a topic you want to see well-represented at debconf? You can contact the talk committee privately if you have questions at talks@debconf.org, or you can contact the whole team publicly at debconf-team@lists.debconf.org. Some ideas about possible tracks: We can't guarantee that any particular track will happen at dc10, but we can guarantee that it won't happen if no one proposes it or wrangles the relevant events together. Help us make this the best debconf ever and make sure that your own topical itch gets scratched! Tags: debconf, debconf10

Next.

Previous.