Hello all.

Last week I was very busy, due to my university duties. On Tuesday I had my first exam in this semester (in Numerical Analysis), which took me more time than I had thought it would be.
From this reason my project is slightly behind schedule, but now I will do my best to catch the plan.

On the other hand, there are also some good news for me. Some time ago, Daniel Burrows migrated aptitude repository from mercurial to GIT. I am git user for nearly year, so I strongly support this move ;) .

Here are some basic thoughts which functionalities good package manager must have (and which approach (from aptitude-gtk, synaptic and adept) I like the most):

• upgrade packeges with good conflict resolution - aptitude conflict resolver is the most advanced. Without a doubt, it has to be in Qt version
• fast searching and installing new packages - I prefer synaptic/yast approach with categories on the left and packages on the right, with single click behavior from KPackegeKit/adept (single click shows package description under selected package and with detailed informations available in new tab - as in aptitude-gtk)
• viewing detailed package informations
• downgrading, holding etc
• fetching packages list, cleaning cache etc

All of this will be elaborated in mockups. Am I forgetting something important?

The most important questions is: "What is the most common use case for package manager? Installing packages or upgrading packages?". I am not sure if this two actions require different views, or there should be only new category in install package view.

This is all now. More updates (and mockups) will be available today's midnight (or tomorrow morning). So please stay tuned :)

Hello Planet Debian readers!

I've never thought that such a thing can ever happen, but I've started blogging ;) So now it is time to introduce myself.

My name is Piotr Galiszewski and I am second year student of computer science at AGH - University of Science and Technology in Krakow (Poland). I have been GNU/Linux user for about 5 years (mostly Debian based distributions).

Thanks for Debian and Google, this summer I will be working on creating Qt-based user interface for aptitude as my Google Summer of Code project. I hope that my mentors Sune Vuorela and Daniel Barrows will be patient with me ;) I am sure I will learn a lot from them. Please look at abstract of my project made by Debian GSoC administrator Obey Arthur Liu:

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.

As I wrote in my proposal I will split my work into three main parts:

1. writing low level classes which will abstract aptitude signals and slots (which uses sigc++) into Qt slots and signals.
2. creating and evaluating GUI mockups
3. implementing GUI on top of classes from the first point

Point 1 and 2 will be made simultaneously and will take all May and half of June. Low level classes should implement all necessary functions for further use in GUI. This classes allow me to avoid direct usage of none Qt code in GUI classes and also give much more time to prepare completed and usability-wise mockups. Every mockups version will be presented and discussed on this blog. First version should be ready in next few days and updates will appear each week (or to weeks).
After finishing this two steps I will start coding GUI. With mockups and finished low level classes this should not be complicated (Yeah, I know that this is only my dream).

Full text of my proposal (including more precise time-line) can be found at Debian wiki.

Currently, project is slightly behind the schedule . It is caused by changes in my studies plan. The Juwanalia students' festival took place earlier, and yesterday it finished. But my first exam will take place one week later on 18 May, so I will have more time to catch up with time-line.

This project is my first direct contribution to Debian, but not first involvement in free software movement. I've been Kadu Instant Messenger developer for more then two year. In last two years I have been second most active developer with more than 700 commits in master branch. During GSoC period my Kadu activities will be limited. If time allows me to do this, I will be still contributing to Kadu. I still can be found at Kadu forum or #kadu channel on irc.freenode.net. I will also continue reviewing patches and fixing low time-consuming bugs.

My plans for the next few days:

• continue researching aptitude codebase
• discover all functionalities that should be implemented by Qt frontend
• review of other graphical package manager GUIs (and probably write about my thoughts on this blog)
• create first draft of my mockups

If you have any thoughts about this project, please add comment to this post or contact me directly. I will be glad to read all yours opinions

Cheers

PS. As you can see English is not my mother tongue, so please forgive me my mistakes

With the 10.10 developer summit behind us, several teams have published engineering plans for the 10.10 release cycle, including:

• The Desktop team plan, via Rick Spencer, includes both Desktop Edition and Netbook Edition, and covers Software Center, GNOME, application and browser selection (including Chromium), X11 and social networking
• The Server team plan, via Jos Boumans, covers migrating services to Upstart, improvements to the mail stack, cloud and cluster storage systems, cloud deployment and load balancing, Ubuntu Enterprise Cloud, and Java
• The Foundations team plan, via Duncan McGreggor, covers system initialization, btrfs, cleaning house, improvements to the installers, Software Center (also) and Upstart (itself), along with a batch of miscellaneous projects, including compiling Ubuntu for the i686 instruction set
• The Kernel team plan, via Leann Ogasawara, covers the choice of kernel 2.6.35, the current Ubuntu patch set, the configuration of our various kernel flavours, bug management, and the availability of backports of newer kernels to Ubuntu LTS releases

I've updated my BPM tap toy, which started behaving strangely since some GTK update. I've identified two issues, and it is working again now.The BPM tap toy is a tiny Python script to obtain a BPM estimation by tapping on your mouse or keyboard. In contrast to many other such applications it does give you an error estimation and will visualize your precision in tapping. This way, you can judge how precise the value is.I have some ideas to further increase precision while adding another useful visualization to judge the result quality.

Some little warning to everyone using ghostscript: Ghostscript always looks for files in the current directory first, including a file that is always executed first (before any safe mode is activated). So by running ghostscript in a directory you do not control, you might execute arbitrary stuff. Two things make this worse:

• When viewing a pdf file with gv, gv always changes in the directory where the file is, so don't use it to view files in such directories.
• The option to disable this behaviour (-P-) does not seem to work at all.

You have been warned.

Martin Meredith wrote a blog post about logging in as root and the people who so strongly advocate against it [1]. The question is whether you should ssh directly to the root account on a remote server or whether you should ssh to a non-root account and use sudo or su to gain administrative privileges. Does sudo/su make your system more secure? Some years ago the administrator of a SE Linux Play Machine used the same home directory for play users to login as for administrative logins as for his own logins he used newrole to gain administrative access (like su or sudo but for SE Linux). His machine was owned by one of his friends who created a shell function named newrole in one of his login scripts that used netcat to send the administrative password out over the net. He didn t immediately realise that this was a problem until his friend changed the password and locked him out! This is one example of a system being 0wned due to having the double-authentication of course if he had logged in directly with administrative privs while using the same home directory that the attacker could write to then he would still have lost but the attacker would have had to do a little more work. When you login you have lots of shell scripts run on your behalf which have the ability to totally control your environment, if someone has taken over those scripts then they can control everything you see, when you think you run sudo or something they can get the password. When you ssh in to a server your security relies on the security of the client end-point, the encryption of the ssh protocol (including keeping all keys secure to prevent MITM attacks), and the integrity of all the programs that are executed before you have control of the remote system. One benefit for using sshd to spawn a session without full privileges is in the case where you fear an exploit against sshd and are running SE Linux or some other security system that goes way beyond Unix permissions. It is possible to configure SE Linux in the strict configuration to deny administrative rights to any shell that is launched directly by the sshd. Therefore someone who cracks sshd could only wait until an administrator logs in and runs newrole and they wouldn t be able to immediately take over the system. If the sysadmin suspected that a sshd compromise is possible then a sysadmin could login through some other method (maybe visit the server and login at the console) to upgrade the sshd. This is however a very unusual scenario and I suspect that most people who advocate using sudo exclusively don t use a SE Linux strict configuration. Does su/sudo improve auditing? If you have multiple people with root access to one system it can be difficult to determine who did what. If you force everyone to use su or sudo then you will have a record of which Unix account was used to start the root session. Of course if multiple people start root shells via su and leave them running then it can be difficult to determine which of the people who had such shells running made the mistake but at least that reduces the list of suspects. If you put PermitUserEnvironment yes in /etc/ssh/sshd_config then you have the option of setting environment variables by ssh authorized_keys entries, so you could have an entry such as the following: environment= ORIG_USER=john@example.com ssh-rsa AAAAB3Nz[...]/w== john@example.com Then you could have the .bashrc file (or a similar file for your favorite shell) have code such as the following to log the relevant data to syslogd:
if [ "$SSH_TTY" = "" ]; then
logger -p auth.info "user $ORIG_USER ran command \"$BASH_EXECUTION_STRING\" as root"
else
logger -p auth.info "user $ORIG_USER logged in as root on tty $(tty)"
fi I think that forcing the use of su or sudo might improve the ability to track other sysadmins if the system is not well configured. But it seems obvious that the same level of tracking can be implemented in other ways with a small amount of effort. It took me about 30 minutes to devise the above shell code and configuration options, it should take people who read this blog post about 5 minutes to implement it (or maybe 10 minutes if they use a different shell or have some other combination of Bash configuration that results in non-obvious use of initialisation scripts (EG if you have a .bash_profile file then .bashrc may not be executed). Once you have the above infrastructure for logging root login sessions it wouldn t be difficult to run a little script that asks the sysadmin what is the purpose for your root login and logs what they type. If several sysadmins are logged in at the same time and one of them describes the purpose of their login as to reconfigure LDAP then you know who to talk to if your LDAP server stops working! Should you run commands with minimum privilege? It s generally regarded that running each command with the minimum privilege is a good idea. But if the only reason you login to a server is to do root tasks (restarting daemons, writing to files that are owned by root, etc) then there really isn t a lot of potential for achieving anything by doing so. If you need to use a client for a particular service (EG a web browser to test the functionality of a web server or proxy server) then you can login to a different account for that purpose the typical sysadmin desktop has a dozen xterms open at once, using one for root access to do the work and another for non-root access to do the testing is probably a good option. Can root be used for local access? Linux Journal has an article about the distribution that used to be known as Lindows (later Linspire) which used root as the default login for desktop use [2]. It suggests using a non-root account because If someone can trick you into running a program or if a virus somehow runs while you are logged in, that program then has the ability to do anything at all of course someone could trick you into running a program or virus that attempts to run sudo (to see if you enabled it without password checks) and if that doesn t work waits until you run sudo and sniffs the password (using pty interception or X event sniffing). The article does correctly note that you can easily accidentally damage your system as root. Given that the skills of typical Linux desktop users are significantly less than those of typical system administrators it seems reasonable to assume that certain risks of mistake which are significant for desktop users aren t a big deal with skilled sysadmins. I think that it was a bad decision by the Lindows people to use root for everything due to the risk of errors. If you make a mistake on a desktop system as non-root then if your home directory was backed up recently and you use IMAP or caching IMAP for email access then you probably won t lose much of note. But if you make a serious mistake as root then the minimum damage is being forced to do a complete reinstall, which is time consuming and annoying even if you have the installation media handy and your Internet connection has enough quota for the month to complete the process. Finally there are some services that seek out people who use the root account for desktop use. Debian has some support channels on IRC [3] and I decided to use the root account from my SE Linux Play Machine [4] to see how they go. #debian has banned strings matching root. #linpeople didn t like me because Deopped you on channel #linpeople because it is registered with channel services . #linuxhelp and #help let me in, but nothing seemed to be happening in those channels. Last time I tried this experiment I had a minor debate with someone who repeated a mantra about not using root and didn t show any interest in reading my explanation of why root:user_r:user_t is safe for IRC. I can t imagine that good the #debian people expect to gain from denying people the ability to access that channel with an IRC client that reports itself to be running as root. Doing so precludes the possibility of educating them if you think that they are doing something wrong (such as running a distribution like Lindows/Linspire). Conclusion I routinely ssh directly to servers as root. I ve been doing so for as long as ssh has been around and I used to telnet to systems as root before that. Logging in to a server as root without encryption is in most cases a really bad idea, but before ssh was invented it was the only option that was available. For the vast majority of server deployments I think that there is no good reason to avoid sshing directly as root.

• [1] http://www.sourceguru.net/login-root/
• [2] http://www.linuxjournal.com/article/7166
• [3] http://www.debian.org/support
• [4] http://www.coker.com.au/selinux/play.html

why Debian for scientific computing: a case study Yesterday I've been invited to visit EDF R&D center at Clamart, near Paris. They wanted to discuss their Debian usage and present some of the cool stuff they're doing. The most interesting component is an in-house Debian-based distribution called "calibre", which has been presented at RMLL 2008. Even though it is now growing desktop profiles (currently deployed on about 1'200 desktops and counting), calibre was mainly developed for clusters dedicated to scientific computing. Current cluster deployments at EDF are not that big, but still comprise hundreds of machines for about 40 teraFLOPS, with their largest cluster in Top 500. The main goal of calibre was to quickly bring a complete cluster from the bare metal to production state. The goal has been quite successfully achieved: using Debian and FAI they get a cluster of 200 machines ready for production in about 1 hour and a half, installing more than 3'000 packages on each machine (as the cluster will be used for heterogeneous purposes, rather than for a handful of specific applications). What I found most interesting of the visit are the reasons for choosing Debian over other (commercial) distros for their scientific computing purposes:

• They use a wide range of open source scientific softwares (some developed in house): according to their claims Debian is the mainstream distribution with the largest offering of such software, with the additional benefit that corresponding Debian maintainers are experts of the software they package, so that they can trust them. They have kudos for Debian Science, which I'm happy to proxy.
• They need to rebuild packages to trigger specific optimizations for their clusters. On one hand, that defeats the typical management argument of "commercial support" that other distros offer, as rebuilding packages void support guarantees.
• On the other hand, it really helps them the focus on quality that we do have on Debian: we fight FTBFSs to death, and people which need to rebuild our packages really appreciate that.

EDF is generally keen of contributing back to Debian (even though the team behind calibre is still small), and I've been happy to walk them through how they can contribute. The last interesting feedback I've to share, is that they feel a bit alone in what they're doing (which is unsurprisingly, given that their communication on the matter has been rather limited thus far ...). Still, there is probably room for synergies that can be better exploited among users with similar needs. So, are you a cluster / scientific computing user of Debian? Then let me know, and I'll be happy to get you in touch with EDF and other users with similar interests.

Debian-based scientific computing at EDF Yesterday I've been invited to visit EDF R&D center at Clamart, near Paris. They wanted to discuss their Debian usage and present some of the cool stuff they're doing. The most interesting component is an in-house Debian-based distribution called "calibre", whish has been presented at RMLL 2008. Even though it is now growing desktop profiles (currently deployed on about 1'200 desktops and counting), calibre was mainly developed for clusters dedicated to scientific computing. Current cluster deployments at EDF are not that big, but still comprise hundreds of machines for about 40 teraFLOPS, with their largest cluster in Top 500. The main goal of calibre was to quickly bring a complete cluster from the bare metal to production state. The goal has been quite successfully achieved: using Debian and FAI they get a cluster of 200 machines ready for production in about 1 hour and a half, installing more than 3'000 packages on each machine (as the cluster will be used for heterogeneous purposes, rather than for a handful of specific applications). What I found most interesting of the visit are the reasons for choosing Debian over other (commercial) distros for their scientific computing purposes:

• They use a wide range of scientific softwares: according to their claims Debian is the mainstream distribution with the largest offering of such software, with the additional benefit that corresponding Debian maintainers are experts of the software they package, so that they can trust them. They have kudos for Debian Science, which I'm happy to proxy.
• They need to rebuild packages to trigger specific optimizations for their clusters. On one hand, that defeats the typical management argument of "commercial support" that other distros offer, as rebuilding packages void support guarantees.
• On the other hand, it really helps them the focus on quality that we do have on Debian: we fight FTBFSs to death, and people which need to rebuild our packages really appreciate that.

EDF is generally keen of contributing back to Debian (even though the team behind calibre is still small), and I've been happy to walk them through how they can contribute. The last interesting feedback I've to share, is that they feel a bit alone in what they're doing (which is unsurprisingly, given that their communication on the matter has been rather limited thus far ...). Still, there is probably room for synergies that can be better exploited among users with similar needs. So, are you a cluster / scientific computing user of Debian? Then let me know, and I'll be happy to get you in touch with EDF and other users with similar interests.

People who use and promote free software cite various reasons for their choice, but do those reasons tell the whole story? If, as a community, we want free software to continue to grow in popularity, especially in the mainstream, we should understand better the true reasons for choosing it especially our own. Some believe that it offers higher quality, that the availability of source code results in a better product with higher reliability. Although it s difficult to do an apples-to-apples comparison of software, there are certainly instances where free software components have been judged superior to their proprietary counterparts. I m not aware of any comprehensive analysis of the general case, though, and there is plenty of anecdotal evidence on both sides of the debate. Others prefer it for humanitarian reasons, because it s better for society or brings us closer to the world we want to live in. These are more difficult to analyze objectively, as they are closely linked to the individual, their circumstances and their belief system. For developers, a popular reason is the possibility of modifying the software to suit their needs, as enshrined in the Free Software Foundation s freedom 1. This is reasonable enough, though the practical value of this opportunity will vary greatly depending on the software and circumstances. The list goes on: cost savings, educational benefits, universal availability, social rewards, etc. The wealth of evidence of cognitive bias indicates that we should not take these preferences at face value. Not only are human choices seldom rational, they are rarely well understood even by the human themselves. When asked to explain our preferences, we often have a ready answer indeed, we may never run out of reasons but they may not withstand analysis. We have many different ways of fooling ourselves with regard to our own past decisions and held beliefs, as well as those of others. Behavioral economics explores the way in which our irrational behavior affects economies, and the results are curious and subtle. For example, the riddle of experience versus memory (TED video), or the several examples in The Marketplace of Perception (Harvard Magazine article). I think it would be illuminating to examine free software through this lens, and consider that the vagaries of human perception may have a very strong influence on our choices. Some questions for thought:

• Does using free software make us happier? If so, why? If not, why do we use it anyway?
• Do we believe in free software because we have a great experience using it, or because we feel good about having used it? (Daniel Kahneman explains the difference)
• Why do we want other people to use free software? Is it only because we want them to share our preference, or because we will benefit ourselves, or do we believe they will appreciate it for their own reasons?

If you re aware of any studies along these lines, I would be interested to read about them.

Michael Specter gave an interesting TED talk about the dangers of science-denial [1]. Most of his talk is about the people who oppose vaccines, such as the former Playboy model Jenny McCarthy who thinks that she knows more about medicine than people who do medical research. He notes that a doctor who advocates vaccination has been receiving threats from the anti-vaccine lobby, including threats to his children. An good new development is that Andrew Wakefield (the British ex-Doctor behind the discredited research linking Autism and Vaccination) has been barred from practicing by Britain s General Medical Council [2]. Michael also mentions the opposition to GM food which has the potential to save many lives in developing countries that have food shortages. This convinced me to reduce my opposition to GM food, it s really not GM food that I m opposed to but the poor testing, the bad features (such as the Terminator Gene), and the Intellectual Property controls which allow GM companies to sue farmers who accidentally have GM crops grow on their land due to wind-borne seeds. It s also a pity that there is no work being done on GM versions of any food crop which is only used for feeding poor people. Every GM plant is one that is used to provide food for rich people and is essentially a way for farmers in first-world countries to make more money. But GM versions of Cassava (with less of the toxic chemicals among other things) and Sorghum would improve the situation of many poor people. One interesting related development is that Craig Venter has just announced the creation of the first synthetic life [3]. This technical development could lead to dramatic changes in the production of basic foods, such as algae that produce proteins that have the ideal mixture of all the essential amino acids needed for humans as well as the semi-essential ones that children need. While feeding pond slime to children isn t going to be glamorous it would be a lot better than the current situation where a significant number of children in developing countries have their physical and mental development stunted due to malnutrition. Craig mentions the possibility of using his research to develop vaccines much faster, including perhaps the possibility of vaccinating people against fast evolving viruses such as the common cold!

• [1] http://www.ted.com/talks/michael_specter_the_danger_of_science_denial.html
• [2] http://news.yahoo.com/s/ap/20100524/ap_on_sc/eu_britain_autism_doctor_11
• [3] http://www.ted.com/talks/craig_venter_unveils_synthetic_life.html

Rog rio Brito writes:

[...] whenever I was typing a command line, changed my mind and pressed C-c, I got a ^C printed on the screen, usually overwriting one or two characters of what I had typed. And this prevented me from automatically copying and pasting the command that I had typed.

There is an alternative to using C-c, and that is M-#. This adds a '#' to the start of the line, commenting it out, and then behaves as if you pressed Return. The result is that the command is cancelled but still remains on-screen and in your history. You can then copy the command later using the mouse or keyboard.

Two of my most frequently used tools are, hands down, Emacs and bash. Having a pleasant configuration of one s toolbox is necessary for long-term productivity. However, newer versions of the programs (any programs) don t always have good, comfortable defaults. That is the case with Emacs 23 and bash 4. With Emacs 23, by default, the scratch buffer shows some text that, if you want to quickly enter text to be saved, has to be deleted. This can be tolerated for some invocations of the editor. But at some point, it gets on one s nerves. Luckily, Emacs is so fully customizable that this is not a problem, unless you have to hunt down the right knobs and you are an e-lisp illiterate. That is my case. After reading an admittedly small amount of documentation, some good lines that ought to be put into one s .emacs file are:

(setq inhibit-startup-echo-area-message "rbrito")
(setq initial-scratch-message nil); show an empty scratch buffer
(setq inhibit-startup-message t); remove splash screen

Another line that may make things more comfortable (especially if you, like me, use Emacs s dired as a filemanager to navigate your folders):

(defalias 'yes-or-no-p 'y-or-n-p)

But configuring Emacs is not always that hard. Seeing a change of behaviour with your shell is scarier. When bash 4 was released, one thing that got implemented is the echo of some characters from the terminal to the screen. In practice and with my usage pattern, this meant that whenever I was typing a command line, changed my mind and pressed C-c, I got a ^C printed on the screen, usually overwriting one or two characters of what I had typed. And this prevented me from automatically copying and pasting the command that I had typed. Looking for an answer to that was much harder than to see how to change a parameter on Emacs: every search that I tried on Google with the words bash and Ctrl-C or some variants of that eventually lead me to how do I trap a Ctrl-C on my shell script? . Decided to see what changed, I read the documentation of readline. It didn t help, because I was reading something from version 5. I, then, downloaded the source code and started looking for SIGINT. Then, perusing the code (and the changelog), I saw that with bash 4 and readline 6, a new configuration option was introduced: the echo-control-characters option of readline. Of course, after knowing this, stopping the undesired behaviour was a simple matter of inserting set echo-control-characters off in my .inputrc and think about how much time I spent with that uncomfortable behaviour in some of my preferred tools. As an addendum to the previous paragraphs (written on February of this year, but only now published), the Debian package of Emacs 23.2, the newest version as of this writing, comes with some configuration that makes it ignore the settings that are used with fontconfig. I did not spend any time trying to see the cause of the problem, but adding a simple

Emacs*font:			Mono

to my .Xdefaults file did the trick and restored back the ability to use DejaVu Sans Mono at the right size on my system.

I recently discovered that there are two variants of the recovery mode used on QNAP TS-11x/TS-21x (and possible TS-41x) devices and that one has a different behaviour than what my documentation claims. While this issue should hopefully affect few users (but please take a moment and check if you're affected), it has implications to all Debian users on TS-11x/TS-21x. My install guide originally told users to create backup of some mtd partitions only but from now on you need a copy of all partitions in order to use the recovery mode. Therefore, please take a moment now to create a backup of the remaining partitions: (You should have copies of mtd1, mtd2 and mtd3 already if you following my guide.) Make sure to copy the files to another machine and add them to your backup.

Recently, I ve been working on an exciting project with JaNet(UK) on a project to bring federated authentication to non-web applications. I ve worked on authentication projects a lot, although this is the first federation project I ve worked on. The big difference appears to be an emphasis on credential independence: the subject (person trying to authenticate) and service will not share a common credential type. Within their organization, the subject and their identity provider share a credential. Then, the federation has some credential mechanism such that the user s organization and the service share some (probably completely different) type of credential. The other emphasis is on providing personalization. For web applications, there are a lot of options to achieve this: Information Card, Open ID, SAML, and OAuth all provide solutions in this space. However there are not good options for non-web applications. If you out-source your mail and chat infrastructure but want to use your own chat client or IMAP client, then you will not get the same federation benefits you can get with the web. If you re using usernames and passwords and don t mind the potential problems with your out-sourcing provider being able to impersonate all your users, you can simply synchronize usernames and passwords. Within an enterprise, you can do better using Kerberos. JaNet(UK) runs the UK Access Federation, which is a SAML-based web single-sign-on federation. In order to better meet the needs of their customers they d like to expand this offering to non-web applications. This demand is apparently shared across the European academic community. I suspect there is also some demand in the US academic community and in enterprise situations. With the web, it turns out that you have a convenient platform for interactions with the identity provider: you can simply direct a web browser to the identity provider and need not specify the user interaction with the web browser at all. This is seen as a significant branding and usability advantage. With other environments, it becomes necessary to specify the interaction with the identity provider. Consider an automated client that wishes to examine a mail box and provide advanced mail sorting or aggregation. That automated client cannot directly use a web browser. OAuth solves this issue with an enrollment step that does typically involve a web browser that produces a consumer key and an authentication step that does not. However for non-web clients it seems like avoiding reliance on the browser authentication will be important. It turns out we already have widely used technologies that do this: the Extensible Authentication Protocol (EAP) mediates the interaction between a subject and identity provider for obtaining network access. It also turns out that we have fairly good technologies for abstract security services within non-web applications: thanks to Kerberos and Active Director, many application protocols and a fair number of applications support GSS-API. JaNet(UK) proposes to combine these technologies with SAML in order to produce a solution for federation beyond the web. I prepared a feasibility analysis of this proposal. At a technical level, the proposal is sound. There s a lot of standardization and implementation work, but there appears to be sufficient motivation to form the seeds of a standards activity and put together a proof-of-concept implementation. However, the big question is Will anyone use it? In particular, to be useful beyond fairly small communities, support from client vendors and application framework vendors will be needed. It s taken massive money and around 20 years to get Kerberos support to a point where it is effective within an enterprise. Moonshot can leverage that work to a large extent, but moonshot may also have greater usability and penetration goals. It s interesting that I m advocating EAP for application layer authentication. When I was a Security AD, I made a strong statement that EAP must only be used for network access. I ve been fairly consistent about that since then. I think there are two huge problems with using EAP for application authentication. The first is that EAP only authenticates the home realm; it does not authenticate what service you re going to. So you might try to connect to your e-mail and end up giving something access to your stored files and pictures instead. That is, EAP has a phishing exposure in the federated context. If the only thing you can get by using EAP is network access, that exposure is only moderate. However in a fully federated environment that is a huge exposure. Moonshot will address this problem by using EAP channel binding and by doing the necessary work to make that a viable solution. The second concern is that interoperability is reduced when you have multiple authentication approaches for the same problem. If EAP is going to be used for application authentication, we need to understand how it relates to the rest of the application authentication metasystem. Moonshot proposes such a relationship, addressing my objection. Moonshot is designed to work well with the objectives of the Identity Metasystem and its laws of identity. It uses a different technology, but does have an approach for dealing with claims-based identity and hopefully will have a user experience very similar to the identity metasystem. It uses a different underlying technology. However one of the main beliefs behind the identity metasystem is that is the user experience and universal interoperability that is important, not any specific technology. In its domain, the technologies Moonshot selects will be a better fit than a web services stack. It s strange not to be working on Kerberos; Moonshot uses some Kerberos technology, but its core is definitely not today s Kerberos. In some ways it is fun to be working on something new. There s one aspect of Kerberos I really miss: Moonshot has nothing like tickets. There s no place to remember state or exchange to directly involve the client in what the server learns. My analysis talks about ways to make Moonshot more like Kerberos; there are some potential advantages, but so far, the tradeoffs do not justify changes. We re hoping to have a bar BOF at IETF 77 and a BOF in the summer at IETF 78.

In a surprise move Apple today announced a new product closely related to the behyped iPad. This move went completely unexpected with technology analysts, who were expecting a new iPhone dubbed "iPhone 4G" to be released next.The new product is called iPad mini, and features most of the iPad functionality in a lot smaller form factor, with extended battery life and without the overheating issues. It will focus on gamers, instead of the deprecated community of newspaper readers. The smaller form factor allows the users to bring the device along at any time.Get all the specifications of the new iPad mini here [www.apple.com]. There is also a special edition with voice-over-3G functionality [www.apple.com].Yes, I'm referring to the iPod touch and the iPhone. Just goofing around.

Romain and I are happy to announce the release of Rcpp version 0.8.0. It has been uploaded to CRAN. A Debian upload is delayed until the now-required inline package is accepted into Debian. The source package is also available from here. This release brings a number of changes that are detailed below. Of particular interest may be the much more robust treatment of exceptions, the new classes for data frames and formulae, and the availability of the new helper function cppfunction for use with inline. Also of note is the new support for the 'LinkingTo' directive with which packages using Rcpp will get automatic access to the header files. An announcement email went to the r-packages list (ETH Zuerich, Gmane); Romain also blogged about the release. The full NEWS entry for this release follows below:

0.8.0   2010-05-17
    o   All Rcpp headers have been moved to the inst/include directory,
	allowing use of 'LinkingTo: Rcpp'. But the Makevars and Makevars.win
	are still needed to link against the user library.
    o   Automatic exception forwarding has been withdrawn because of
	portability issues (as it did not work on the Windows platform).
	Exception forwarding is still possible but is now based on explicit
	code of the form:
	
	  try  
	    // user code
	    catch( std::exception& __ex__)  
	    forward_exception_to_r( __ex___ ) ;
	   
	
	Alternatively, the macro BEGIN_RCPP and END_RCPP can use used to enclose
	code so that it captures exceptions and forward them to R. 
	
	  BEGIN_RCPP
	  // user code
	  END_RCPP
	
    o   new __experimental__ macros 
	
	The macros RCPP_FUNCTION_0, ..., RCPP_FUNCTION_65 to help creating C++
	functions hiding some code repetition: 
	
	  RCPP_FUNCTION_2( int, foobar, int x, int y) 
	    return x + y ;
	   
	The first argument is the output type, the second argument is the 
	name of the function, and the other arguments are arguments of the C++ 
	function. Behind the scenes, the RCPP_FUNCTION_2 macro creates 
	an intermediate function compatible with the .Call interface and handles 
	exceptions
	
	Similarly, the macros RCPP_FUNCTION_VOID_0, ..., RCPP_FUNCTION_VOID_65 
	can be used when the C++ function to create returns void. The generated
	R function will return R_NilValue in this case.
	
	  RCPP_FUNCTION_VOID_2( foobar, std::string foo ) 
	    // do something with foo
	   
	  
	The macro RCPP_XP_FIELD_GET generates a .Call compatible function that
	can be used to access the value of a field of a class handled by an 
	external pointer. For example with a class like this: 
	
	  class Foo 
		public:
			int bar ;
	   
	
	  RCPP_XP_FIELD_GET( Foo_bar_get, Foo, bar ) ;
	  
	RCPP_XP_FIELD_GET will generate the .Call compatible function called
	Foo_bar_get that can be used to retrieved the value of bar.
	
	
	The macro RCPP_FIELD_SET generates a .Call compatible function that 
	can be used to set the value of a field. For example:
	
	  RCPP_XP_FIELD_SET( Foo_bar_set, Foo, bar ) ;
	
	generates the .Call compatible function called "Foo_bar_set" that 
	can be used to set the value of bar
	
	
	The macro RCPP_XP_FIELD generates both getter and setter. For example
	
	  RCPP_XP_FIELD( Foo_bar, Foo, bar )
	  
	generates the .Call compatible Foo_bar_get and Foo_bar_set using the 
	macros RCPP_XP_FIELD_GET and RCPP_XP_FIELD_SET previously described
	
	  
	The macros RCPP_XP_METHOD_0, ..., RCPP_XP_METHOD_65 faciliate 
	calling a method of an object that is stored in an external pointer. For 
	example: 
	
	  RCPP_XP_METHOD_0( foobar, std::vector<int> , size )
	
	creates the .Call compatible function called foobar that calls the
	size method of the std::vector<int> class. This uses the Rcpp::XPtr<
	std::vector<int> > class.
	
	The macros RCPP_XP_METHOD_CAST_0, ... is similar but the result of
	the method called is first passed to another function before being
	wrapped to a SEXP.  For example, if one wanted the result as a double
	
	   RCPP_XP_METHOD_CAST_0( foobar, std::vector<int> , size, double )
	
	The macros RCPP_XP_METHOD_VOID_0, ... are used when calling the
	method is only used for its side effect.
	
	  RCPP_XP_METHOD_VOID_1( foobar, std::vector<int>, push_back ) 
	
	Assuming xp is an external pointer to a std::vector<int>, this could
	be called like this :
	
	  .Call( "foobar", xp, 2L )
	
    o	Rcpp now depends on inline (>= 0.3.4)
	
    o   A new R function "cppfunction" was added which invokes cfunction from
	inline with focus on Rcpp usage (enforcing .Call, adding the Rcpp
	namespace, set up exception forwarding). cppfunction uses BEGIN_RCPP
	and END_RCPP macros to enclose the user code
    o	new class Rcpp::Formula to help building formulae in C++
    
    o   new class Rcpp::DataFrame to help building data frames in C++
	
    o   Rcpp.package.skeleton gains an argument "example_code" and can now be
	used with an empty list, so that only the skeleton is generated. It
	has also been reworked to show how to use LinkingTo: Rcpp
	
    o   wrap now supports containers of the following types: long, long double,
	unsigned long, short and unsigned short which are silently converted
	to the most acceptable R type.
	
    o	Revert to not double-quote protecting the path on Windows as this
	breaks backticks expansion used n Makevars.win etc
        
    o   Exceptions classes have been moved out of Rcpp classes,
	e.g. Rcpp::RObject::not_a_matrix is now Rcpp::not_a_matrix

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

The systemd projecct is an interesting concept for replacing init and related code [1]. There have been a few attempts to replace the old init system, upstart is getting some market share in Linux distributions and Solaris has made some interesting changes too. But systemd is more radical and offers more benefits. While it s nice to be able to start multiple daemons at the same time with dependencies and doing so offers improvements to the boot times on some systems that really doesn t lead to optimal boot times or necessarily correct behavior. Systemd is designed around a similar concept to the wait option in inetd where the service manager (formerly inetd and now the init that comes with systemd) binds to the TCP, UDP, and Unix sockets and then starts daemons when needed. It apparently can start the daemons as needed which means you don t have a daemon running for months without serving a single request. It also implements some functionality similar to automount which means you can start a daemon before a filesystem that it might need has been fscked. This means that a large part of the boot process could be performed in reverse. The current process is to run fsck on all filesystems, mount them, run back-end server processes such as database servers and then run servers that need back-end services (EG a web server using a database server). The systemd way would be for process 1 to listen on port 80 and it could then start the web server when a connection is established to port 80, start the database server when a connection is made to the Unix domain socket, and then mount the filesystem when the database server tries to access it s files. Now it wouldn t be a good idea to start all services on demand. Fsck can take hours on some filesystems and is never quick at the best of times. Starting a major daemon such as a database server can also take some time. So a daemon that is known to be necessary for normal functionality and which takes some time to start could be started before a request comes in. As fsck is not only slow but usually has little scope for parallelisation (EG there s no point running two instances of fsck when you only have one hard disk), so hints as to which filesystem to be checked first would need to be used. Systemd will require more SE Linux integration than any current init system. There is ongoing debate about whether init should load the SE Linux policy, Debian has init loading the policy while Fedora and Ubuntu have the initramfs do it. Systemd will have to assign the correct SE Linux context to Unix domain socket files and listening sockets for all the daemons that support it (which means that the policy will have to be changed to allow all domains to talk to init). It will also have to manage dbus communication in an appropriate way which includes SE Linux access controls on messages. These features mean that the amount of SE Linux specific code in systemd will dwarf that in sysvinit or Upstart which among other things means that it really wouldn t make sense to have an initramfs load the policy. They have a qemu image prepared to demonstrate what systemd can do. I was disappointed that they prepared the image with SE Linux disabled. All I had to do to get it working correctly was to run the command chcon -t init_exec_t /usr/local/sbin/systemd and then configure GRUB to not use selinux=0 on the kernel command line. Another idea is to have systemd start up background processes for GUI systems such as KDE and GNOME. Faster startup for KDE and GNOME is a good thing, but I really hope that no-one wants to have process 1 manage this! Having one copy of systemd run as root with PID 1 to start daemons and another copy of the same executable run as non-root with a PID other than 1 to start user background processes is the current design which makes a lot of sense. But I expect that some misguided person will try to save some memory by combining two significantly different uses for process management.

• [1] http://0pointer.de/blog/projects/systemd

Since AdBlock in Chrome does not block, just hide (the same probably applies to Safari and other WebKit-based-browsers), here's a simple method to actually block Facebook Like tracking:Use a proxy.pac file, also known as Proxy auto-config. Then redirect Facebook Like to a blackhole or filtering proxy. I use privoxy, and this replaces Facebook Like embeds with an error message, which enables me to see which site uses Facebook like and that my filter is working.Here's the relevant excerpt of my proxy.pac file:

function FindProxyForURL(url, host)  
  var fblike = /https?:\/\/([^/]*)\.facebook\.com\/(plugins widgets)\/like.*/;
  if (fblike.test(url))  
    return "PROXY 127.0.0.1:8118";
   
  return "DIRECT";
 

Where "127.0.0.1:8118" is the proxy to use. If you use an unreachable proxy - I've seen 255.255.255.0:3421 used as blackhole server - then it should just time out as "unreachable". Or you use a proxy such as privoxy and block the URL there. Any proxy that refuses to serve the request will do.Note that you can add arbitrary domains and regexps to this filter, if you want to block additional sites, such as Google Analytics, that you do not want to be able to track your surfing behaviour.

Part of the problem that we face in providing Linux hardware support is that we're lucky if there's a spec, and even if there's a spec there almost certainly isn't a test suite. Linux still isn't high on the list of things that vendors test with, so as a result hardware and firmware tend to be written to work with Windows rather than some more ideal notion of what a spec actually says.

This can lead to all kinds of problems. If the spec says we can do something and Windows never does that, we'll often find that there's at least one piece of hardware out there somewhere that breaks in response. But sometimes there'll be several different workarounds, and picking the wrong one may break some other system instead. It's helpful to know what Windows is actually doing, if only because that's the only configuration most systems have been tested with.

The problem is that doing this at the hardware level is next to impossible. I'm sure there are people out there who salivate at the possibility of working out i8042 initialisation sequences by hooking up oscilloscopes to their mouse, but I'm not one of them. There's a much easier alternative involving qemu.

The qemu source base is reasonably large and complex, but that's ok - we don't need to care about most of it. For our purposes we really only want to trace accesses to given bits of hardware. There's three main types of hardware access we're likely to care about: io ports, memory mapped io and pci configuration space. io ports are easy. Each piece of qemu that performs hardware emulation will call register_ioport_read or register_ioport_write. Just grep for those, find the ports that correspond to your hardware and then edit the functions to dump the information you want. PCI configuration space will be handled via pci_default_read_config or pci_default_write_config unless the driver overrides them. Finally, for PCI devices mmio will be handled via pci_register_bar - the last argument is the function called when the memory region is accessed.

All of which makes it pretty easy to watch register reads and writes performed by Windows when it's starting up. Suspend/resume is also an interesting problem, but sadly one that's harder to work with. First of all, you need at least version 0.6c of vgabios in order to indicate to Windows that it's possible to suspend at all. Secondly, for Vista or later you'll also need a WDDM driver for the graphics. Sadly there isn't one for the Cirrus that qemu emulates, which is unsurprising given how ancient it is. So I've had to perform my testing under XP, which was enough to give me an indication as to what Windows does with the SCI_EN bit on resume (answer: Ignores both the bit of the spec that says it should already be enabled and the bit of the spec that says it should never be written by hand). Nice, but if someone would like to write a WDDM driver for Cirrus it'd make my life easier.

The other thing I've been testing is keyboard controller probing. Some Macs deal badly with you banging on the keyboard controller, which is dumb but on the other hand they don't claim to have one. Linux will look at your ACPI tables and use any keyboard controllers it finds there, but if there isn't one it'll go on to try probing the legacy locations. Adding some debug code to the read and write functions of the keyboard driver in qemu and then editing the DSDT in Seabios to remove the declarations for the keyboard showed that Windows will only probe if there's a device with a recognised keyboard PNP ID. No keyboard for you if that's missing. So we probably need to emulate that behaviour as well.

The main reason to do this work is to try to reduce the number of DMI tables in the kernel. These are cases where we alter the kernel's behaviour based on the identity string of the hardware, allowing us to work around functional differences. The problem with this approach is that Windows generally works fine on these machines without knowing anything special about them, and chances are that the tables aren't exhaustive - there may well be some other piece of hardware that's also broken, but the user just gave up and went back to Windows instead of ever letting us know. Using qemu to work out how Windows actually behaves gives us the opportunity to fix things up in a way that will (with luck) work on all machines.

Since October of 2002, HP has sponsored a "corporate subscription" to LWN on behalf of Debian, and I recently renewed the subscription through April of 2011. As of this moment, 571 Debian Developers and Debian Maintainers are enabled to take advantage of this subscription. From discussion on IRC this morning, I gather one recent change hasn't been adequately communicated: I now allow Debian Maintainers to access the subscription. The process remains unchanged: If you are a Debian Developer or Debian Maintainer and want full LWN access at HP's expense, just go to lwn.net and create an account for yourself (no money is required to create a user account). Then, send email to

lwn-subscription@debian.org

containing your LWN account name. Sign this email with your key on the appropriate Debian keyring. Then, exercise patience. Eventually, I will process your request, and add you to the "Debian Project group" and send you an email acknowledgement. Likewise, if you retire from being a DD or DM, please let me know at the same address so that I can take you off the Debian subscription. I believe I've caught up on all pending requests, but sometimes things get mis-filed, so if you're still waiting and I haven't replied, please re-send your request.