Search Results: "beh"

24 June 2010

Joachim Breitner: nagstmon forklet necessary

A while ago, I discovered nagstamon, a very useful piece of software by Henri Wahl. This program sits in the notification area of your desktop and alerts you when your nagios-monitored services have problems. Using nagstamon allows me to keep my servers under close surveillance, and it also adds another channel besides e-mail alerts, which will be helpful in case my mail server has problems. The wish I am not a full time sysadmin, I only monitor very few hosts and the services rarely have problems. Therefore, I do not want nagstamon to constantly sit in the notification area but only use it when there is something, well, to notify me about. It turned out that nagstamon did not support this mode of operation, so I created a ticket and asked whether this feature could be added. The author raised two points, one being that then the user would not know when nagios crashed and the other being that you would not be able to configure nagstamon because you do not see it. He also indicated that he does not have the resources to work on it and asked if I could find the time. The patch Since I really liked nagstamon, but really want to keep my panel uncluttered, I found the time: I created a series of self-containing patches, adding an option for the feature, adding code to prevent more than one instance of nagstamon running in parallel and adding a "nagstamon --settings" flag that would signal the running instance to show the settings similar to how mail-notification is been behaving. The author then raised the valid point that some people run more than one instances in parallel, with different configuration options. I then extended the patch to cater for that. The rebuff The author remained reserved, did not answer my last commend on the ticket and then, six weeks later, closed the bug without explanation and turned off the possibility to add comments. I can understand when people are reluctant to add contributed features to their code, I often feel the same way. But completely blocking more comments is not a nice way of communicating with possible contributors. The fork(let) So I m left with no option but patching each released version with my changes and building my own package. As I have to do this work anyways, I d like to share it. You can find my branch in my git repository. If you happen to want this feature as well and are using a Debian-based distribution, please let me know: I am building modified Debian packages anyways and can publish them as well. As I don t want to maintain this fork of nagstamon I don t plan to diverge any more from Henri s code, so if you have other feature requests, please talk to him first.

Joachim Breitner: nagstamon forklet necessary

Matthew Garrett: Joojoo

I've had the opportunity to look into the Joojoo tablet recently. It's an interesting device in various ways, ranging from the screen being connected upside down and everything having to be rotated before display, to the ACPI implementation that's so generic it has no support for actually attaching most embedded controller interrupts to ACPI devices and so relies on a hacked kernel that exposes individual interrupts as ACPI events that are parsed in userspace, to the ChangeOrientation binary that's responsible for switching between landscape and portrait modes containing gems like ps aux grep fgplayer grep -v grep and containing references to org.freedesktop.PandaSystem, a somewhat gratuitous namespace grab. Hardware-wise it seems to be little more than battery, generic nvidia reference design board and touchscreen with an accelerometer and LED glued to the chipset's GPIO lines. The entire impression is one of an ambitious project not backed up by the level of technical expertise required to get things done properly. Frankly, I think Michael Arrington came out of this rather better than he could have done - behind the reasonably attractive UI, the entire device is pretty much held together by string and a following wind.

Of course, releasing shoddily put together technology isn't generally illegal and from that point of view Fusion Garage aren't any worse than a number of products I've had the misfortune to actually spend money on. But they're distributing Linux (stock Ubuntu with some additional packages and a modified kernel) without any source or an offer to provide source. I emailed them last week and got the following reply:

Dear Sir,

we are still actively making changes to the joojoo software. We will make
the source release available once we feel we are ready to do so and also
having the resources to get this sorted out and organized for publication.
We seek your kind understanding on our position and appreciate your
patience on this. Thank you.

Best Regards
joojoo Support Team

Strong work, Fusion Garage. Hardware and software may not be your strong points, but you're managing copyright infringement with the best of them.

Anand Kumria: Silent Voices

Silent Voices

The introduction of this movie felt really contrived. A group of people waiting to go on a prison visit, when one of them suddenly becomes hysterical because she is unable to read the piece of paper telling her if this is the right place. The pullaway shot of one person tugging the arm of another to drag them away from the specticle was a nice touch though. There are three major story threads going on during this movie:

Alexandre + Laure A young couple who have met, fallen for each other and are struggle to remain together even though one is behind bars
Stephane + Else An older couple who are struggling to find direction, money and love with each other
Zorah A mother who is trying to understand what has happened to her son

Each of these has a number of sub-threads. Unfortunately, I found both the first two story threads to be clich d. Cute, but clich d. Obviously each of the threads intersects, and the finale helps you understand the title. Farida Rahouadj's portrayal of Zorah was very compelling and makes up for all the other imperfections of the movie. It held the movie together and made it watchable. 3.5 out of 5.

23 June 2010

Matt Zimmerman: Habit forming

I find that habits are best made and broken in sets. If I want to form a new habit, I ll try to get rid of an old one at the same time. I don t know why this works, but it seems to. Perhaps I only have room in my head for a certain number of habits, so if I want a new one, then an old one has to go. I m sure some combinations are better than others. I m currently working on changing some habits, including:

Start exercising, swimming three times per week
Stop drinking alcohol entirely
Start a consistent flossing routine

I m thinking of adding a reading habit to the set, but it s going well so far and I don t want to overdo it. I feel good, and am forming a new routine. The flossing is definitely the hardest of the three. I hate pretty much everything about flossing. It also unbalances the set, so that I have a net gain of one habit. Maybe that s the real reason, and if I broke another habit, it would get easier. Does anyone else have this experience? What sort of tricks do you employ to help you change your behavior?

John Goerzen: Thyroid Surgery & The Boys

Terah has been having thyroid troubles for some time now (you can read about it on her blog). Today was the day for it to be removed. This procedure is somewhat delicate. Running through each half of the thyroid are nerves that control the vocal chords. Also embedded in each half are tiny parathyroids, which regulate the body s calcium levels. Losing either of these things in one half of the thyroid is no big deal, but losing either of them entirely can be serious. For this reason, the general plan was for Terah to have half of her thyroid out, unless it was obvious in surgery that it would be a health risk to leave the other half in, or that it was obvious that the removal of the first half had successfully preserved the nerves and parathyroids. Jacob and Oliver spent the night with my parents last night an event that Jacob was incredibly excited about. I came home last night to find him running in circles in the kitchen. I had this conversation with him: Me: Jacob, are you excited about something? Jacob: Yes! Me: What are you excited about? Jacob: I don t know. (He usually says this when he doesn t want to say, but I figured it was his pending overnight stay) .. a minute later .. Jacob: I am excited about something blue. Me: [genuinely confused] Hmmm . I don t know what blue thing you might be excited about. Can you tell me? Jacob: A blue house! Me: Oh, is it grandma and grandpa s blue house? Jacob: YEAH! Now you ve got it! I m so excited! He was still running in circles the whole time. So Jacob and Oliver left, and Terah and I worked on the house. This morning, we arrived at the hospital at 6:15 to check in. At usual, the staff there was incredibly friendly and helpful. And two of them made connections: one of the intake nurses had taught at the college where my dad works, and another nurse knows his cousin. Living where we do, we were not surprised by this. (You sort of wonder how many connections you ll make at a place like this.) The surgery area is right next to the ER, and people waiting for people in surgery normally wait there. Having got my fill of the TV playing infomercials for the morning in the 5 minutes we sat there, I arranged to wait in the cafeteria (which is large and quiet in the middle of the morning) and they just called my cell phone when Terah was done. I was with Terah for as long as possible, then ate breakfast in the cafeteria, walked over to the doctor s office next door for my weekly allergy shots, and then waited with my Kindle in the cafeteria. They called, and a little while later the surgeon explained how the surgery went: far easier than they had expected. He was confident the left side surgery went well, and so took out the whole thing and was confident the right side removal also went well. I went to wait in Terah s room for her to exit recovery, and our pastor and his daughter showed up to wait too. When she arrived, she was very tired but said a few words before going to sleep. Our pastor gave the two of us a minute before coming in, and read a selection from Psalm 139 before leaving. I then mostly waited with my Kindle some more until she woke up. I brought back some lunch from the cafeteria, and eventually Terah woke up. We chatted just a bit (it was mostly me talking). I went to pick up the boys, and brought them to the hospital. They were glad to see her. But then, the dilemma: I had promised Jacob that we would eat in the hospital restaurant , but it was only 4 and they didn t start serving supper until 5. Jacob somehow remembered that we went exploring in the hospital when Oliver was born 11 months ago, and had been talking about doing this already. So off we went: Jacob sometimes helping me push Oliver s stroller, sometimes running on ahead, enjoying himself and spelling out letters on big signs on the walls. We got a whole bunch of smiles and compliments. Oliver was laughing, and Jacob was happy and well-behaved. We went towards the cafeteria at 4:30 and I got Jacob some of their free lemonade. He was complaining about not eating, and I remembered that he noticed a nurse walking out of there with an ice cream cone while we were exploring. Obviously the soft-serve machine was already up, so I got him and me ice cream cones. I m sure he ll be talking about the hospital ice cream for days. Anyhow, it took him about half an hour to eat it, so it was perfect timing for supper. We ate, went back to see Terah, and then headed out. I do believe that these may be the only two boys I know of that actually think of a hospital as a fun place to go. It wouldn t surprise me at all if Jacob asks to go back there. Both boys fell asleep on the way home. Jacob, unfortunately, had a rather significant accident, possibly due to the large amounts of free lemonade he insisted on drinking. And it was hot outside. So I carried Jacob in, and he sort of groggily looked at me. I suggested he take a nap on the rug in the kitchen (his room is upstairs) while I bring Oliver in. He sort of collapsed onto the rug and was back asleep a few seconds later. I got Oliver in, and brought down new shorts and an overnight pullup for Jacob. Put them on, had him use the toilet, and got him in bed. By that time, Oliver was awake and hungry. So I got him fed, and neither one of them quite went to sleep easily but they did. I watered the flowers and garden, did a load of laundry, etc. Jacob had been worried about the surgery, though had trouble verbalizing it. I think he s better about it now, though some of his trouble falling asleep tonight was probably still worry about that. Hopefully he ll be better once Terah is back home, which should hopefully be tomorrow.

21 June 2010

Matt Zimmerman: Finishing books

Having invested in some introspection into my reading habits, I made up my mind to dial down my consumption of bite-sized nuggets of online information, and finish a few books. That s where my bottleneck has been for the past year or so. Not in selecting books, not in acquiring books, and not in starting books either. I identify promising books, I buy them, I start reading them, and at some point, I put them down and never pick them back up again. Until now. Over the weekend, I finished two books. I started reading both in 2009, and they each required my sustained attention for a period measured in hours in order to finish them. Taking a tip from Dustin, I decided to try alternating between fiction and non-fiction. Jitterbug Perfume by Tom Robbins This was the first book I had read by Tom Robbins, and I am in no hurry to read any more. It certainly wasn t without merit: its themes were clever and artfully interwoven, and the prose elicited a silent chuckle now and again. It was mainly the characters which failed to earn my devotion. They spoke and behaved in ways I found awkward at best, and problematic at worst. Race, gender, sexuality and culture each endured some abuse on the wrong end of a pervasive white male heteronormative American gaze. I really wanted to like Priscilla, who showed early promise as a smart, self-reliant individual, whose haplessness was balanced by a strong will and sense of adventure. Unfortunately, by the later chapters, she was revealed as yet another vacant vessel yearning to be filled by a man. She s even the steward of a symbolic, nearly empty perfume bottle throughout the book. Yes, really. Managing Humans by Michael Lopp Of the books I ve read on management, this one is perhaps the most outrageously reductionist. Many management books are like this, to a degree. They take the impossibly complex problem domain of getting people to work together, break it down into manageable problems with tidy labels, and prescribe methods for solving them (which are hopefully appropriate for at least some of the reader s circumstances). Managing Humans takes this approach to a new level, drawing neat boxes around such gestalts as companies, roles, teams and people, and assigning them Proper Nouns. Many of these bear a similarity to concepts which have been defined, used and tested elsewhere, such as psychological types, but the text makes no effort to link them to his own. Despite being a self-described collection of tales , it s structured like a textbook, ostensibly imparting nuggets of managerial wisdom acquired through lessons learned in the Real World (so pay attention!). However, as far as I can tell, the author s experience is limited to a string of companies of a very specific type: Silicon Valley software startups in the dot com era. Lopp (also known as Rands) does have substantial insight into this problem domain, though, and does an entertaining job of illustrating the patterns which have worked for him. If you can disregard the oracular tone, grit your teeth through the gender stereotyping, and add an implicit preface that this is (sometimes highly) context-sensitive advice, this book can be appreciated for what it actually is: a coherent, witty and thorough exposition of how one particular manager does their job. I got some good ideas out of this book, and would recommend it to someone working in certain circumstances, but as with Robbins, I m not planning to track down further work by the same author.

14 June 2010

Gunnar Wolf: What Mexico feels like

I have been recently approached by several friends, from different countries. Mexico and the violence seems to be a frequent news topic all over the world. I live in Mexico City, as ~25% of the country's population does. This is not an easy city, of course, and I won't deny it has tons of problems of its own. However, Mexico City (and even more so the approximately of it that is politically located in Distrito Federal, the formal country capital) is very lucky in this regard. Still, in most of the country, the violence is mostly in the news, mostly a worrying perception that is every day more insistent. My parents live in Cuernavaca, Morelos, ~80Km south from us. Morelos has been known for decades for being the druglords' getaway and safe haven, so it remained a mostly peaceful state for most of this time. This has changed, and at some points during this year, militarization feels quite creepy... Fortunately, just for a couple of weeks, and then back to what seems like normal. The real problems in Morelos is the undeniable corruption of its successive governments, the lack of regard for the population, the inexistent urban planning... However, I know from several friends living in the North of the country (and all along the very long border - The most drug-related violent states nowadays are Chihuahua, Durango, Sinaloa, Tamaulipas and Nuevo Le n, with only two states in the South Michoac n and Guerrero) that violence is really felt by local population on the streets. Some friends say they have grown used to hearing shootings (Durango), others say that it is now usual that the cartels openly strangle the city's vial system with the express purpose of showing off their strength (Monterrey, Nuevo Le n, one of Mexico's most important cities and taken in the past as a token of industrialization and first-world-like life conditions... Just don't look towards the poor areas). About Chihuahua, I'd rather not even talk, as by all accounts (official even) it rivals Iraq in the lack of control the government has of its territory. Still, with all that as background... I am afraid of what I read today in the news. I know a single declaration is not enough to worry about (as said in El Quijote, una golondrina sola no hace verano , a single swallow does not mean it's summer), but those things always start small... Until they explode. La Jornada reports that The retired general Luis Garfias Maga a recommends suspending constitutional guarantees in the country to be able to properly fight violence. The last century we had a sad and long history of cases where the military took over civilian power and suspended the constitutional rights in basically every nation in Latin America Except for Mexico. Not one of those cases was overall successful. Not one of them went by without raging abuses, without terrible consequences. I don't see imminent we will go over to a military rule nor anything close to it, but the environment is getting each time closer to how it was like before said rights suspension. We should learn that it is just not the way, it leads nowhere. I am convinced, and will keep insisting on it at every ocassion, that the only possible way to fight violence is by reducing the social distance, and that should be achieved most importantly by reducing poverty, but also by making it harder to become incredibly rich. Mexico's percentage of poor people has grown over the last decades, but at the same time, the amount of wealth concentrated in very few hands has grown much faster. A society with terribly rich and terribly poor people leads to hatred, leads to desperation, leads to violence. A flatter society, even if the overall standard was to be somewhat lower, tends to a better equilibrium. And yes, I know the original problem with drugs is that Mexico is a great transit area for drugs to reach the USA (and I could also rant about drug legalization I won't, it's late and I must go to work), but the main fuel for young people to leave everything behind and take the risk of starting a life of open ilegality is the lack of future they face all life long. That leads many to risk their lives attempting to cross the border to the USA (Mexico "exports" 500,000 people every year), but also lures them to jobs where they will have easy money... In exchange for their lifes, ultimately. Anyway... Just to repeat and round off: The answer to this problem is not repression, is not policial or military strength. Our only way out is through social justice.

12 June 2010

Bradley Smith: Gitorious + Blog = Fun (+ Ruby)

Something I've wanted to do for a while now, is somehow combine my blog with all of my projects/git repositories, and now I've done it! Welcome to my new site :) So, I got bored a few nights ago, and started trying to find some kind of project management type system to host my git repositories in. After searching for a while I stumbled across Gitorious. I'd heard of Gitorious before, but I'd never really looked at it, nor did I know that it's codebase was infact completely open. So I thought I'd give it a try to see what it was like Now I have to admit, my first impressions of it weren't exactly great. Firstly, it uses Ruby, which I can't say I'm much of a fan of (but that's a different discussion :p), nor am I a fan of installing all of the 'packages' it needed, via gem. Deploying it is an absolute nightmare, it has 4 different daemons, all of which have hideous init scripts that don't really work properly, and low and behold you try and put the git repositories and the site itself under different users, figuring out what needs to run as what and what needs what permissions is very much a game of trial and error. In Gitorious' defence, there /are/ numerous guide lurking around on the internet explaining how to do these things. But once I'd got over these niggles, and had actually deployed it, it worked quite nicely, and really did exactly what I wanted, so I decided to stick with it. It then occurred to me that it probably wouldn't be too hard to stick a blog onto it, after all, it's written using Rails, which is supposed to be easy, right? So with no knowledge of Ruby, let alone Rails, I got stuck in. Fortunately, it turns out Rails is in fact pretty easy to use, (at least once you've got used to it implicitly doing everything behind the scenes..), I'm even starting to think I prefer it to Django... So there we have it, a brand new site, and one that looks considerably better than my old one.. even if it is just Gitorious in disguise _ The only thing I'm disappointed Gitorious doesn't have, is some kind of bug tracker, but then, I'm not sure I'd use one given most of my projects just go through Debian.

11 June 2010

Petter Reinholdtsen: Automatic upgrade testing from Lenny to Squeeze

The last few days I have done some upgrade testing in Debian, to see if the upgrade from Lenny to Squeeze will go smoothly. A few bugs have been discovered and reported in the process (#585410 in nagios3-cgi, #584879 already fixed in enscript and #584861 in kdebase-workspace-data), and to get a more regular testing going on, I am working on a script to automate the test. The idea is to create a Lenny chroot and use tasksel to install a Gnome or KDE desktop installation inside the chroot before upgrading it. To ensure no services are started in the chroot, a policy-rc.d script is inserted. To make sure tasksel believe it is to install a desktop on a laptop, the tasksel tests are replaced in the chroot (only acceptable because this is a throw-away chroot). A naive upgrade from Lenny to Squeeze using aptitude dist-upgrade currently always fail because udev refuses to upgrade with the kernel in Lenny, so to avoid that problem the file /etc/udev/kernel-upgrade is created. The bug report #566000 make me suspect this problem do not trigger in a chroot, but I touch the file anyway to make sure the upgrade go well. Testing on virtual and real hardware have failed me because of udev so far, and creating this file do the trick in such settings anyway. This is a known issue and the current udev behaviour is intended by the udev maintainer because he lack the resources to rewrite udev to keep working with old kernels or something like that. I really wish the udev upstream would keep udev backwards compatible, to avoid such upgrade problem, but given that they fail to do so, I guess documenting the way out of this mess is the best option we got for Debian Squeeze. Anyway, back to the task at hand, testing upgrades. This test script, which I call upgrade-test for now, is doing the trick:

#!/bin/sh
set -ex
if [ "$1" ] ; then
    desktop=$1
else
    desktop=gnome
fi
from=lenny
to=squeeze
exec < /dev/null
unset LANG
mirror=http://ftp.skolelinux.org/debian
tmpdir=chroot-$from-upgrade-$to-$desktop
fuser -mv .
debootstrap $from $tmpdir $mirror
chroot $tmpdir aptitude update
cat > $tmpdir/usr/sbin/policy-rc.d <<EOF
#!/bin/sh
exit 101
EOF
chmod a+rx $tmpdir/usr/sbin/policy-rc.d
exit_cleanup()  
    umount $tmpdir/proc
 
mount -t proc proc $tmpdir/proc
# Make sure proc is unmounted also on failure
trap exit_cleanup EXIT INT
chroot $tmpdir aptitude -y install debconf-utils
# Make sure tasksel autoselection trigger.  It need the test scripts
# to return the correct answers.
echo tasksel tasksel/desktop multiselect $desktop   \
    chroot $tmpdir debconf-set-selections
# Include the desktop and laptop task
for test in desktop laptop ; do
    echo > $tmpdir/usr/lib/tasksel/tests/$test <<EOF
#!/bin/sh
exit 2
EOF
    chmod a+rx $tmpdir/usr/lib/tasksel/tests/$test
done
DEBIAN_FRONTEND=noninteractive
DEBIAN_PRIORITY=critical
export DEBIAN_FRONTEND DEBIAN_PRIORITY
chroot $tmpdir tasksel --new-install
echo deb $mirror $to main > $tmpdir/etc/apt/sources.list
chroot $tmpdir aptitude update
touch $tmpdir/etc/udev/kernel-upgrade
chroot $tmpdir aptitude -y dist-upgrade
fuser -mv

I suspect it would be useful to test upgrades with both apt-get and with aptitude, but I have not had time to look at how they behave differently so far. I hope to get a cron job running to do the test regularly and post the result on the web. The Gnome upgrade currently work, while the KDE upgrade fail because of the bug in kdebase-workspace-data I am not quite sure what kind of extract from the huge upgrade logs (KDE 167 KiB, Gnome 516 KiB) it make sense to include in this blog post, so I will refrain from trying. I can report that for Gnome, aptitude report 760 packages upgraded, 448 newly installed, 129 to remove and 1 not upgraded and 1024MB need to be downloaded while for KDE the same numbers are 702 packages upgraded, 507 newly installed, 193 to remove and 0 not upgraded and 1117MB need to be downloaded I am very happy to notice that the Gnome desktop + laptop upgrade is able to migrate to dependency based boot sequencing and parallel booting without a hitch. Was unsure if there were still bugs with packages failing to clean up their obsolete init.d script during upgrades, and no such problem seem to affect the Gnome desktop+laptop packages.

10 June 2010

David Welton: Ok, first one on the block: leenooks.com

The problem with selling off these sites is that I am a bit attached to them emotionally. Leenooks.com is a cool domain, I think - it's how Linus pronounces Linux, supposedly. It's also one of the first sites I put together: the original version was done in Perl with CGI back in ... '97? The current incarnation runs on DedaWiki a wiki I put together that is built with Ruby on Rails.
The idea behind the site was that, rather than keep track of all the hardware out there that works well with Linux, let's focus on the stuff you really want to avoid as that is a smaller set of things, and hopefully one that, one day, will be empty! It seems to have been fairly popular over the years, and has helped pay for the server it runs on. However, "popular" doesn't necessarily translate into "oodles of money", and especially now that I have a daughter who is a lot of fun to play with, I need to cut back on my "spare time" projects. So this one is the first one up on the auction block. I fervently hope that whoever acquires it can dedicate a bit more time and energy to making it do what it does, only better.

8 June 2010

Dirk Eddelbuettel: Rcpp 0.8.1

Early this morning I sent Rcpp version 0.8.1 off to CRAN and Debian. In the meantime, Romain has already provided a very nice blog post about it. There are a few fairly visible new things in this release. As we want to focus the next few minor releases on completing the documentation, we started by adding a total of four (!!) new vignettes:

Rcpp-package showing how to write your own package using Rcpp,
Rcpp-FAQ addressing several frequently asked questions,
Rcpp-modules discussing how to expose C++ functions and modules with ease using an idea borrowed from Boost::Python, and
Rcpp-extending detailing the steps needed to extend Rcpp with user-provided or third-party classes,

The most interesting new feature is what we call Rcpp modules and is modeled after Boost::Python. This makes it pretty easy to expose C++ functions and classes to R -- without having to write glue code. This is pretty new and may change a tad over the coming releases, but it is also quite exciting. Other changes concern more improvements for use of inline which should now allow packages like our RcppArmadillo to be used with it, and some bug fixes. The full NEWS entry for this release follows below:

0.8.1   2010-06-08
    o   This release adds Rcpp modules. An Rcpp module is a collection of
        internal (C++) functions and classes that are exposed to R. This
        functionality has been inspired by Boost.Python.
        
        Modules are created internally using the RCPP_MODULE macro and
        retrieved in the R side with the Module function. This is a preview 
        release of the module functionality, which will keep improving until
        the Rcpp 0.9.0 release. 
        The new vignette "Rcpp-modules" documents the current feature set of
        Rcpp modules.
        
    o   The new vignette "Rcpp-package" details the steps involved in making a
        package that uses Rcpp.
    o   The new vignette "Rcpp-FAQ" collects a number of frequently asked
        questions and answers about Rcpp.
    o   The new vignette "Rcpp-extending" documents how to extend Rcpp
        with user defined types or types from third party libraries. Based on
        our experience with RcppArmadillo
        
    o   Rcpp.package.skeleton has been improved to generate a package using 
        an Rcpp module, controlled by the "module" argument
    o   Evaluating a call inside an environment did not work properly
        
    o   cppfunction has been withdrawn since the introduction of the more
        flexible cxxfunction in the inline package (0.3.5). Rcpp no longer
        depends on inline since many uses of Rcpp do not require inline at
        all. We still use inline for unit tests but this is now handled
        locally in the unit tests loader runTests.R. 
        Users of the now-withdrawn function cppfunction can redefine it as:
        
           cppfunction <- function(...) cxxfunction( ..., plugin = "Rcpp" )
    o   Support for std::complex was incomplete and has been enhanced.
    o   The methods XPtr<t>::getTag and XPtr<t>::getProtected are deprecated, 
        and will be removed in Rcpp 0.8.2. The methods tag() and prot() should
        be used instead. tag() and prot() support both LHS and RHS use. 
    o   END_RCPP now returns the R Nil values; new macro VOID_END_RCPP
        replicates prior behabiour

As always, even fuller details are in Rcpp Changelog page and the Rcpp page which also leads to the downloads, the browseable doxygen docs and zip files of doxygen output for the standard formats. A local directory has source and documentation too. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page

6 June 2010

Petter Reinholdtsen: Upstart or sysvinit - as init.d scripts see it

If Debian is to migrate to upstart on Linux, I expect some init.d scripts to migrate (some of) their operations to upstart job while keeping the init.d for hurd and kfreebsd. The packages with such needs will need a way to get their init.d scripts to behave differently when used with sysvinit and with upstart. Because of this, I had a look at the environment variables set when a init.d script is running under upstart, and when it is not. With upstart, I notice these environment variables are set when a script is started from rcS.d/ (ignoring some irrelevant ones like COLUMNS):

DEFAULT_RUNLEVEL=2
previous=N
PREVLEVEL=
RUNLEVEL=
runlevel=S
UPSTART_EVENTS=startup
UPSTART_INSTANCE=
UPSTART_JOB=rc-sysinit

With sysvinit, these environment variables are set for the same script.

INIT_VERSION=sysvinit-2.88
previous=N
PREVLEVEL=N
RUNLEVEL=S
runlevel=S

The RUNLEVEL and PREVLEVEL environment variables passed on from sysvinit are not set by upstart. Not sure if it is intentional or not to not be compatible with sysvinit in this regard. For scripts needing to behave differently when upstart is used, looking for the UPSTART_JOB environment variable seem to be a good choice.

4 June 2010

Russell Coker: Securely Killing Processes

Joey Hess wrote on Debian-devel about the problem of init scripts not doing adequate checks before using the data from a PID file under /var/run to determine which process to kill [1]. Unfortunately that still doesn t quite solve the problem, there is still the issue of a race condition causing a process to die while you are doing the checks and then be replaced by another process. Below I have included the source code to a little program that will repeatedly fork() until it finds a particular PID and then have it s child call sleep(). So you can run a command such as kill -9 1234 ; ./a.out 1234 and then have this program take over the PID 1234. From testing with this it seems that when you have a shell with it s current working directory as /proc/1234 then once process 1234 is killed the current directory is empty, ls -l returns 0 entries. This isn t surprising, it s the standard Unix behavior when the working directory is removed. So if a program (or even a shell script) changes directory to /proc/1234 it can then verify all attributes of the process (it s CWD, it s root directory, the executable used to run it, it s UID, GID, supplemental groups, it s SE Linux context, and lots of other things all atomically. The only possibility for confusion is that a process might execute a SETUID or SETGID program or a program that has a label which triggers a SE Linux domain transition. It might also change some attributes without executing a new process, for example by using the setuid(), setgid(), setgroups(), or other similar system calls. For the purposes of killing a process I don t think that the possibility of it changing it s own attributes or executing a new program are serious problems, if you want to kill a process then you probably want to kill it after it has called setuid() etc. It seems to me that it would be useful to have a file named /proc/PID/signal (or something similar) to which you could write a number and then have the kernel send the signal in question to that process. So the commands kill -9 1234 and echo 9 > /proc/1234/signal would give the same result. But you could run the command cd /proc/1234 and then some time later you could run echo 9 > signal and know that you would kill the original process 1234 if it was still running and not some other process that replaced it. What do you think? Is this worthy of adding a new feature to the proc filesystem? The Source Run the following program with a single parameter which is the PID that you want it to take. It will keep looping through the PID space until it gets the one you specify, if the one you specify isn t available (EG you give it 1 as a parameter) then it will run forever. It will take some time to get a result on a slower system. On my P3-900MHz test system it took up to 72 seconds to get a result. #include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/wait.h> int main(int argc, char **argv)

if(argc != 2)

printf("Specify the desired PID on the command-line\n");
return 1;

pid_t wanted = (pid_t)atoi(argv[1]);
int rc;
int status;
while((rc = fork()) != wanted && rc != 0)

if(rc == -1)

printf("fork error\n");
return 1;

if(wait(&status) == -1)
printf("wait error\n");

if(rc == 0)

if(getpid() == wanted)

printf("Got pid %d, sleeping\n", wanted);
sleep(200);

return 0;

wait(&status);
return 0;

[1] http://lists.debian.org/debian-devel/2010/05/msg00067.html

Russ Allbery: NVIDIA, bug handling, and patience

Recently, the long-time maintainer of the NVIDIA packages for Debian stepped down, after having not had much time to work on the packages for some time. I don't really like maintaining non-free packages, but I have some NVIDIA hardware and nouveau isn't quite far enough along yet for me to feel comfortable just switching, so I decided to help, despite having very little spare time. Thankfully, Andreas Beckmann stepped up and has been submitting patches like crazy, so I've not had to do a lot of the work. This is a very difficult package to maintain, since it's completely non-free. Nearly all the code is a binary object, which we cannot change in any way, so it's frustrating because we can't do anything about basically any bugs. Upstream distributes their code in a weird, annoying package format. It's also very complicated, full of random upstream libraries for providing various interfaces to the GPU to do computing, and it conflicts with and replaces various X bits like the GL library. And on top of that, it comes in four different variants, all of which need to be separately packaged, plus a bunch of supporting packages and libraries (some non-free and some free). Oh, and it builds a kernel module. And we historically provided pre-built kernel modules and meta-packages. And the packaging infrastructure hadn't been overhauled in quite some time, so it wasn't using current packaging techniques. Did I mention the RC bugs and the nearly 200 open bugs on just the main non-legacy package (now much lower thanks to Andreas's hard work). We're slowly making progress. nvidia-graphics-drivers migrated to testing for the first time since around the lenny release and now supports DKMS, and Andreas has massively modernized the packaging. We also have just about finished the transition to using the free libvdpao library rather than the one included with the NVIDIA packages. But given that background, you might understand why one might find blog posts like this one (about a bug that was first reported for KDE just one week ago!) just a little demotivating. (The problem had been previously observed with GDM, but it appeared to be fixed somehow in GDM 3.) I'm sure there are better ways that I could have communicated the bug status, and I probably stressed a bit more than I need to the point that the module is completely opaque and non-free and there isn't much that we can do to change its behavior. But reading negative comments about one's work on Planet Debian is really kind of frustrating, particularly when that work is on something that it's hard to get Debian to care about and that's kind of thankless to start with. I'm not trolling for praise here; I have a thick skin. But this does seem like a good opportunity for a reminder that this is a volunteer project, some packages are kind of annoying to maintain, and things take time. If you don't agree with a maintainer's determination of whether or not something is RC (I still don't think this bug is RC), one can certainly have that conversation. But unless the maintainer marks the bug wontfix, please don't jump to the conclusion that no one cares about trying to find a resolution. And one week is a rather short time period to arrive at that conclusion, even if the maintainer is fairly negative about the bug. Sometimes that just means that you caught them on a bad day. For the record, I'm currently pondering asking the people with this bug to try adding nvidia to /etc/modules and see if forcing the module load earlier works around this problem. I think what's happening is that the module is doing some sort of prolonged initialization, and it just needs more lead time before it's expected to respond to the X server.

3 June 2010

Matthew Garrett: Poulsbo still makes me sad

Meego 1.0 was released last month. Predictably enough, it lacks any form of support for the GMA500 graphics chipset[1], which is reasonably in line with Intel's placing of US15W as an embedded product for MID-type devices rather than having anything to do with netbooks. Of course, the market pretty much ignored that detail, so we're left with the release of a netbook experience that's incompatible with a large number of netbooks.

There's been hints that there might be some sort of new driver coming, though, and Intel's rapidly heading towards the release of Moorestown - their new MID platform that's x86 but not a PC, that replaces Poulsbo (unless you want to run Windows) and which has the same SGX 3D core[2] as Poulsbo. Moorestown support has started landing in the mainline Linux kernel and Intel are talking about devices shipping with it this year, so we ought to see the graphics driver soon, right?

Well, kind of. Digging through the Meego kernel git tree reveals an updated driver with Moorestown support. The blob is too big for gitorious to display, so I've put up a copy here. Things to note - this isn't a new driver (it's clearly derived from the PSB one), it includes a huge blob of Imagination's platform-independent code, the front end of the driver is still pretty much the i915 driver with a small number of PSB-specfic changes and despite the cheerily optimistic "Patch-mainline: 2.6.35?" at the top it stands pretty much no chance whatsoever of going mainline given that it's even more offensive than the previous version and that one got rejected out of hand.

So it's not clear what Intel's doing here. If this is the driver that Intel are developing for upstream then there's been a pretty serious breakdown in communication over what their driver has to look like. If it's not, Intel have another and presumably better driver somewhere that they're developing entirely behind closed doors despite having shipped millions of units of hardware that people would dearly love to be able to run mainline kernels on. Neither case looks especially good, so the continuing perception would seem to be that only a subset of the company understands the Linux development model - we'll see how this ends up interacting with Meego as a whole.

(Huh. I was about to hit "Post" on this, and then found that another and entirely different driver was submitted for the Meego kernel last week. A copy of it's here. "IVI" in this context appears to stand for "In-vehicle interface" and is aimed at those contexts rather than generic ones. It includes much the same Imagination glue code as the Moorestown driver, appears to be derived from a driver that has support for other Intel chipsets, was written to be at least partially OS-independent given that it abstracts things like PCI and stands even less chance of going upstream than the other driver - as acknowledged by "Patch-mainline: Never". Hilariously, if we include IEGD, that makes three different drivers for the same hardware from the same company, each having no chance to go upstream. Thintel.)

[1] Weirdly, it includes the kernel DRM for Matrox cards. No X driver though.
[2] It's clocked higher, though

1 June 2010

Chris Lamb: Appending the request URL to SQL statements in Django

import sys
from django.http import HttpRequest
from django.db.backends import BaseDatabaseWrapper, util
class URLCursor(util.CursorDebugWrapper):
    def execute(self, sql, *args):
        f = sys._getframe()
        while f:
            request = f.f_locals.get('request')
            if isinstance(request, HttpRequest):
                sql += ' -- %s' % repr(request.path)[2:-1].replace('%', '%%')
                break
            f = f.f_back
        return self.cursor.execute(sql, *args)
fn = BaseDatabaseWrapper.cursor
BaseDatabaseWrapper.cursor = lambda self: URLCursor(fn(self), self)

Now your SQL statements look like:

SELECT "auth_user"."id", [..] WHERE "auth_user"."id" = 1 -- /login

This allows you to quickly go from a misbehaving query in your production environment to the view that is executing it.

Russell Coker: Can SE Linux Implement Traditional Unix Users and Groups?

I was asked by email whether SE Linux could implement traditional Unix users and groups. The Strictly Literal Answer to that Question The core of the SE Linux access control is the domain-type model where every process has a domain and every object that a process can access (including other processes) has a type. Domains are not strongly differentiated from types. It would be possible to create a SE Linux policy that created a domain for every combination of UID and GID that is valid for a user shell given that such combinations are chosen by the sysadmin who could limit them to some degree. There are about 2^32 possible UIDs and about 2^32 possible GIDs, as every domain is listed in kernel memory we obviously can t have 2^64 domains, but we could have enough to map a typical system that s in use. Of course the possible combinations of supplemental groups probably makes this impossible for even relatively small systems, but we can use a simpler model that doesn t emulate supplemental groups. For files there are more possible combinations because anyone who is a member of a group can create a SETGID directory and let other users create files in it. But in a typical system the number of groups is not much greater than the number of users the maximum number of groups is typically the number of users plus about 60. So if we had 100 users then the number of combinations of UID and GID would be something like 100*(100+60)=16,000 it should be possible to have that many domains in a SE Linux policy (but not desirable). Then all that would be needed is rules specifying that each domain (which is based on a combination of UID and GID) can have certain types of access to certain other types based on them having either the same UID or the same GID. Such a policy would be large, it would waste a lot of kernel memory, it would need to be regenerated whenever a user is added, and it s generally something you don t want to use. No-one has considered implementing such a policy, I merely describe it to illustrate why certain configuration options are not desirable. The rest of this post is about realistic things that you can do with SE Linux policy and how it will be implemented in Debian/Squeeze. My previous post titled Is SE Linux Unixish? addresses this issue at a more conceptual level and also considers MAC vs DAC [1]. The History of mapping Unix Accounts to SE Linux Access Control In the early releases of SE Linux (long before it was included in Fedora) every user who could login to a system needed to have their user-name compiled into the policy. The policy specified which roles the user could access, the roles specified which domains could be accessed, and therefore what the user could do. The identity of files on disk was used for two purposes, one was logging (you could see who created a file) and the other was a permission check for the SE Linux patched version of Vixie cron which would not execute any command on behalf of a user unless the identity on the crontab file in the cron spool matched the identity used to run it this is an analogy of the checks that Vixie cron makes on the Unix UID of the crontab file (some other cron daemons do fewer checks). Having to recompile policy source every time you added a user was annoying. So a later development was to allow arbitrary mappings between Unix account names and SE Linux Identities (which included a default identity) and another later development was to have a utility program semanage to map particular Unix account and group names to SE Linux identities. This was all done years ago. Fedora Core 5 which was released in 2006 had the modular policy which included these features (apart from mapping Unix groups to SE Linux identities which was more recent). Fedora Core 5 also introduced MCS which was comprised of a set of categories that a security context may have. The sysadmin would configure the set of categories that each account would have. A recent development has been a concept named UBAC (User Based Access Control) which basically means that a process running directly on behalf of a regular user (IE with a SE Linux identity that s not system_u) can only access files that have an identity of system_u or which have the same identity as the process. This means that you can only access your own files or system files not files of other users which may have inappropriate Unix permissions. So for example if a user with a SE Linux identity of john gives their home directory the Unix permission mode of 0777 then a user with a SE Linux identity of jane can t access their files. Of course this means that if you have a group of people working together on a project then they probably need to all have the same Identity and in practice you would probably end up with everyone having the same identity. I ve given up on the idea of using UBAC in Debian. The Current Plan for Users and SE Linux Access Control in Debian My plan is to have things work in Squeeze in much the same way as in Lenny. You have a SE Linux identity assigned to a login session and everything related to it (including cron jobs) based on the Unix account name or possibly the Unix group name (if there are login entries for both the user-name and the group-name then the user-name entry has precedence). The mapping between Unix accounts and SE Linux identities is configured by the sysadmin and SE Linux identities don t matter much for the Targeted configuration (which is what most people use). The identity determines which roles may be used and also has a limit on the MCS categories. The MCS categories are also specified in the login configuration which has to be a sub-set of the categories used by the identity record. So for example the following is the output of a couple of commands run on a Debian/Unstable system. They show that the test Unix account is assigned a SE Linux identity of staff_u and an MCS range of s0-s0:c1 (this means it creates files by default at level s0 and can also write to other files at that level, but can also have read/write access to files at the level s0:c1 ). The staff_u identity (as shown in the output of semanage user -l can be used with all categories in the set s0:c0.c1023 where the dot means the set of categories from c0 to c1023 inclusive) but in the case of the test user only one category will be used. The test group however (as expressed with %test ) is given the identity user_u and is not permitted to use any categories.

# semanage login -l
Login Name    SELinux User    MLS/MCS Range           
%test         user_u          s0                     
__default__   unconfined_u    s0-s0:c0.c1023         
root          unconfined_u    s0-s0:c0.c1023         
system_u      system_u        s0-s0:c0.c1023         
test          staff_u         s0-s0:c1               
# semanage user -l
             Labeling   MLS/       MLS/                         
SELinux User Prefix     MCS Level  MCS Range         SELinux Roles
root         sysadm     s0         s0-s0:c0.c1023    staff_r sysadm_r system_r
staff_u      staff      s0         s0-s0:c0.c1023    staff_r sysadm_r
sysadm_u     sysadm     s0         s0-s0:c0.c1023    sysadm_r
system_u     user       s0         s0-s0:c0.c1023    system_r
unconfined_u unconfined s0         s0-s0:c0.c1023    system_r unconfined_r
user_u       user       s0         s0                user_r

I hope to get the policy written to support multiple user roles in time for the release of Squeeze. If I don t make it then I will put such a policy on my own web site and try to get it included in an update. The policy currently basically works for a Targeted configuration where the users are not confined (apart from MCS). How MMCS Basically Works The vast majority of SE Linux users run with the MCS policy rather than the MLS policy. For Debian I have written a modified version of MCS that I call MMCS. MMCS is mandatory (you can t relabel files to escape it) and it prevents write-down. If a process has the range s0-s0:c1,c3 then it has full access to files labelled as s0, s0:c1, s0:c3, and s0:c1,c3 and any files it creates will be labeled as s0. If a process has the range s0:c1-s0:c1,c3 then it has read-only access to files labelled as s0 and s0:c3 and read-write access to files labelled as s0:c1 and s0:c1,c3. This means that any secret data it accesses that was labelled with category c1 can t be leaked down to a file that is not labelled with that category. Now MCS currently has no network access controls, so there s nothing stopping a user from using scp or other network utilities to transfer files. But that s the way with most usable systems. I don t think that this is necessarily a problem, the almost total lack of network access controls in a traditional Unix model doesn t seem to concern most people. Now to REALLY Answer that Question SE Linux is a Mandatory Access Control (MAC) system, this makes it inherently different to a Discretionary Access Control (DAC) system such as traditional Unix access controls. Unix permissions are based on each file having a UID, a GID, and a set of permissions and each process having a UID, a GID, and a set of supplementary GIDs. If a user runs a setuid or setgid program then the process will have extra privileges. It also has a lot of stuff that most people aren t aware of such as real vs effective UIDs, the tag bit, setgid directories, and lots more including some quite arbitrary things like making ports <1024 special. SE Linux is based on every object (process, file, socket, etc) having a single security label which includes an identity, a role, a type, and a sensitivity label (MCS categories or an MLS range). There is no support for an object to have more than one label. The SE Linux equivalent to setuid/setgid files is a label for a file which triggers a domain transition when it s executed. This differs from setuid files in that the domain transition is complete (the old privileges can t be restored) and the transition is generally not to a strict super-set of the access (usually a different sub-set of possible access and sometimes to lesser access). These differences are quite fundamental. So really SE Linux can t implement traditional Unix access control. What SE Linux is designed to do is to provide a second layer of defense and to also provide access controls that have different aims than that of Unix permissions such as being mandatory and implementing features such as MLS.

[1] http://etbe.coker.com.au/2008/08/25/is-se-linux-unixish/

Julien Danjou: Thoughts and rambling on the X protocol

Two years ago, while working on awesome, I joined the Freedesktop initiative to work on XCB. I had to learn the arcane of the X11 protocol and all the mysterious and old world that goes with it. Now that I've swum all this months in this mud, I just feel like I need to share my thoughts about what become a mess over the decades. When I was unborn

the Toto band were releasing their song "Africa" and some smart guys were working on a windowing system: the X Window System (this is its full name) which therefore has a (too) long history. The latest version of its protocol, the 11th one, has been designed in the 80's. You can learn more about the history in the Wikipedia article about X. In 2010, we still listen disco music and we still use various protocols designed in the 80's and even before X. Music have evolved, protocols have evolved, and so did X11. The problem is that X11 did not evolve that well. The guys at MIT-and-some other-places-with-very-smart-people-in-it created X version 1 in 1984, and updated it until X version 11 (the one we're still using) in 1987. Eleven version in 3 years, that was following the "release early, release often" model. But I don't know why, it just stopped to happen for the last 23 years¹. I don't know what changes have been made in the first 11 major versions of the X protocol, but I'm rather sure we should have deserve a couple of major version updates this last 2 decades. In my humble opinion, X11 was not designed to live 23 years. But hey, I'm not blaming anyone here: I was 4 years old and playing Lego when they released this latest version of the X protocol, so there is little chance I'd have done something better.

1. That's not totally true: they added (and then deprecated) many extensions. We won't fix. We'll work-around.

That is probably one of the guideline of the X protocol for the last years. And don't misread me: I'm not bashing anyone thereafter. Since the X11 protocol was aging, the X guys started to add extensions. They added tons of them over the years. This, in application of one of the early principles of X:

It is as important to decide what a system is not as to decide what it is. Do not serve all the world's needs; rather, make the system extensible so that additional needs can be met in an upwardly compatible fashion.

All of them with no exception were added because, bad luck, the X11 protocol did not anticipated the things that happened in the last 23 years, like video, OpenGL, multiple monitors, or the pleasure to draw oval windows. Some of this extensions are still in use, while some of them have been dropped. While this is not a bad thing to extends the protocol, it seems like a bad thing to try to fix the protocol with for example the XFixes extension, even with all the good intentions Keith Packard might have in his greatness. Actually it's even worst than you think

The X11 protocol (without extensions) defines about 120 types of requests: create a window, move a window, etc. Nowadays, there's at least 25 % of them which are useless: usage of server-side font, or the drawing of squares and polygon, are unused by any modern application or toolkit. All of this is superseded by requests from extensions, like the XRender one. The handling of multiple monitors displays has totally been screwed up. X11 has been designed to work in Zaphod mode (independent monitors). But Xinerama, and nowadays XRandR have replaced it up: recent X servers (released after ~2007) does not support Zaphod mode anymore, even if it's a core piece of the X11 protocol. Worst: on many requests, there's limitation or design flaws, like described in this document: Why X Is Not Our Ideal Window System by DEC researchers. We'll add more broken standard on top of that

Following its early principle, X does not define policies but only mechanisms, which seems like a good thing, Consequently, people started writing specifications to determine a number of stuff and dogmas: ICCCM. That was 22 years ago in 1988. It's useless to add that many things in this specification are now obsolete, useless, or that it misses many modern stuff. I was not the only one to think that. The people from what will be the major desktop environments, KDE and GNOME, saw that too in the 90's while I was learning to count. So they wrote EWMH, another standard that comes on top of ICCCM and extends it with nifty features like maximization, full screen mode, etc. The problem is that this standard has also been written by narrow-minded people who at that time, were working on GNOME or KDE (and maybe others). This desktop environments were having and still have some strong concepts of how should work a desktop: "it should have work-spaces", "a window is only on one workspace", "we only see a workspace at a time", "you do not have multiple screens", etc. Dude, we don't care: we have toolkits!

This vision of how the desktop should work have now been written in marble in all applications and libraries implementing EWMH, like GTK+ or Qt. Nowadays, everybody forgot about all of this standards. Toolkits have implemented this, circumvented the X11 protocol limitation and flaws, and nobody wants to look back. Like all standards, obviously some people implemented them badly. This had some side effects, like OpenOffice acting like a pager. We don't look back? Worst, we forgot where we came from!

With all these layers of bad designed standards, the desktop continued to evolve for more than a decade. They continued to add more standard, the more recent ones being based on D-Bus like the Desktop Notification Specification or the latest Status Notifier Specification developed by KDE. The Status Notifier is a new implementation of the good old system tray based on XEmbed, using D-Bus instead of the X11 mechanisms, and adding the possibility to show the system tray with something else than icons. This specification draft saw an important issue and design flaw raised by Wolfgang Draxinger in this thread on the XDG mailing-list. What Wolfgang points out, is that X is network-oriented, and D-Bus is not. Therefore, making the Status Notifier specification to use D-Bus to pass system tray messages around is a bad idea, since running a X application from host A on host B will draw the system tray on the wrong host! Apparently, reading the thread, this does not fear some of the KDE people:

of course this is a bizarre corner case not worth much thought. at least that's what you'll think until you actually run into it yourself (be it because you are testing something or because you are setting up some weird kiosk environment).

What Oswald describes as a corner case is an actual common use case for many of us. Of course, YMMV. From my point of view, this is a step back in the wrong direction. But we can conclude that the network part of X is now worthless, to at least KDE. I used to believe in XCB

When I joined Freedesktop, it was to work on XCB, the X C Binding. XCB is a nice, clean, 21st century technology based API to play with the X11 protocol. Its code is auto generated based on XML file describing the protocol. In comparison, Xlib is 80's obfuscated code with almost no comments and hard-coded things. Only a few people can understand some of its corner like its i18n or XKB implementations. And all its code is synchronous. For people not knowing it yet, X is a network protocol where you send request (like a GET in HTTP) and then get a response. Xlib forces the application to wait for the reply to its request, so the application is blocked until the X server sends the reply to the request. XCB on the other hand does not block and allows the application to send a batch of requests, do some other stuff in the mean time, and then gets the replies. It's like your Web browser would send one request at a time to a Web server, and would wait until you downloaded all the images one by one to display the page. In cases where X and all its clients are on the same host, the latency is small and not really visible, therefore the gain for XCB to be asynchronous is small. On slow network however, the gain can be huge, as proved in the rewrite of xlsclients with XCB by Peter Harris. One of the long standing goal of the XCB folks is to kick-out Xlib, to increase speed and hides latency in X11 applications. That requires to port many libraries, because almost none of them (Cairo being an exception) supports XCB. From where I stand, I don't really see if the work is worth it now. The desktop world is trusted by GNOME and KDE, meaning GTK+ and Qt. It seems none of this toolkits are interested to work on XCB, neither on the X protocol. They probably put hard effort in bypassing X limitation and flaws, and they now sit on top of crap of workarounds and broken-by-design-standard implementation. It seems to me they don't want to go back in the layers and improves things. They're too high to go back down and they don't see what the gain would be. Enlightenment with its EFL was the first toolkit to have an XCB back-end with the work of Vincent Torri. Unfortunately, the back-end is not maintained and nobody cares about it. Last time I tried it, it did not compile at all. X12 ?

There's a page called X12 on the Freedesktop wiki, listing all the things that should be fixed some days. Unfortunately, the list continues to grow up an no one talks about working on X12. On the other hand, there's a handset of people trying to work when they will have time on XKB2, the second version of the "let's-try-to-fix-up-the keyboard-part-of-the-protocol-we-wrote-23-years-ago-a-second-time" extension. To me, it does not seem X12 will happen in the next decade neither. Alternative ?

Do we got alternative to X ? There's Wayland, but it's far from being usable. There's DirectFB, but that's not very portable. None seems candidate to replace X some days to me. Anyhow, none of the main toolkits around support this alternative. GTK+ once supported DirectFB, but as far as I know, it is not supported nor works nowadays, as stated by Josselin Mouette. This is why recent versions of the Debian installer have migrated to X for the graphic part, thanks to Cyril Brulebois work. Conclusion

XCB has been around for more than half-a-decade, and very few people showed interested in it. As far as I can see, nobody is interested to use the X protocol and everybody tries to encapsulate it in some higher-level API as soon as possible to stop seeing it. This leads to poorly written application and toolkits, with a lot of ugly hack. All of that also means that starting to write applications and graphical toolkits based on XCB would be a very interesting project, but that would lead to spend too much time learning to circumvent the X protocol flaws, things that have been done in years by predecessors like Qt and GTK+. Major toolkits implementations have almost nothing to win in going back in the dark water of X. I guess most of their folks prefer to work on shiny 3D effects based on your GPS location, rather than redefining better basis for everyone. The manpower available in the X world is very small. Debian lacking of X maintainers is just the summit of that. There is very smart and very competent and skilled guys in the X world, as you can see by simply reading blog posts on Planet Freedesktop for example (me excluded). Unfortunately, there's not enough of them to cover all the things involved in X: input devices, graphics devices, new protocol extension specification and so on. The X server is really late, and it seems most of the developers prefers to work on the server itself than on the protocol behalf. Which is understandable. I'm curious to see where all of that will lead in the upcoming years. I've been walking in the X world hallways for about 3 years now, and I feel desktop alternatives to KDE and GNOME will all die sooner or later. The time were you could choose between a dozen "modern" window managers has passed away. After all, maybe that is simply Darwinism applied to computer software.

31 May 2010

Piotr Galiszewski: The end of the first mockups iteration

Last week was very busy for me. Unfortunately, I spent most of my time no my study duties. An exam session is fast approaching, so in next 3 weeks the situation will not be better. But as I promised, during second part of week, I am working full time on my project.

So, here are missing mockups of future Aptitude Qt GUI:

Changes Preview tab:

Only one "Preview Tab" can be opened at the same time. Changes will be live updated here.

Resolver:

Perform Changes tab:

This time I am not too innovative. I think that current Aptitude GTK design for this tabs is quite intuitive and good-looking, so I have added only minor tweaks.

To sum up mockups topic, below are links to all presented mockups (with some comments which raises during my recent private discussions). Now, I am open for any suggestions and comments about current design. At the end of next week, second iteration will be presented. Depending of the level of required changes there could be third iteration, before sending mockups to Piotr "Patpi" Pe zowski, who is the person behind Kadu Usability Project. I am glad that he agreed to spend his spare time and help me with this task :)

Packages tab:

This tab in second iteration will have only small changes. I was told that will be nice to select multiple categories at the same time. I agree, so categories list will support multi selection. There will be also an option in configuration window (There is no mockup now. Currently, I do not know what option will be configurable and it is not the most important thing at this stage. The window will be patterned upon KDE configuration windows) to move this list on the right side of this tab.

It will be possible to have multiple "Packages tabs" opened at the same time. It will not be allowed to close first "Package Tab". Ctrl + T shortcut, action in main menu and toolbar (I have forgotten about toolbar in this iteration - maybe it is not necessary?) will open new tab. There will be also an option that each text search will do this. I will try to add shortcuts wherever is it possible to allow using the GUI without mouse.

"Show changes" button will be change to "Resolve dependencies" when necessary.

Updates widget:

Most of the comments from "Packages tab" apply here too. In the table showing updates will be also "Current Version" column.

Package Informations tab:

Only one clarification: multiple "Packages Informations" tabs for the same package will not be allowed.

I am looking forward to read any comments regarding presented design. Please leave comment below this post or contact me directly (see About Me page).

On Monday/Tuesday I will write first weekly report.

Cheers.

Next.

Previous.