Digging into the fabulous world of Emacs and Lisp, I wanted to use it to build my personal Web site and my blog. I already moved from ikiwiki to Emacs Muse for my HTML pages some weeks ago. Muse provides an extension to maintain a journal, called muse-journal. Unfortunately, it was far to fulfill all my needs, and I decided that it would be a good exercise to write a better extension. Consequently, I started to wrote my own extension, which I named muse-blog. And this is now what is used to build this blog. :-)

Today, the last piece of the puzzle for roaming laptops in Debian Edu finally entered the Debian archive. Today, the new libpam-mklocaluser package was accepted. Two days ago, two other pieces was accepted into unstable. The pam-python package needed by libpam-mklocaluser, and the sssd package passed NEW on Monday. In addition, the libpam-ccreds package we need is in experimental (version 10-4) since Saturday, and hopefully will be moved to unstable soon. This collection of packages allow for two different setups for roaming laptops. The traditional setup would be using libpam-ccreds, nscd and libpam-mklocaluser with LDAP or Kerberos authentication, which should work out of the box if the configuration changes proposed for nscd in BTS report #485282 is implemented. The alternative setup is to use sssd with libpam-mklocaluser to connect to LDAP or Kerberos and let sssd take care of the caching of passwords and group information. I have so far been unable to get sssd to work with the LDAP server at the University, but suspect the issue is some SSL/GnuTLS related problem with the server certificate. I plan to update the Debian package to version 1.2, which is scheduled for next week, and hope to find time to make sure the next release will include both the Debian/Ubuntu specific patches. Upstream is friendly and responsive, and I am sure we will find a good solution. The idea is to set up the roaming laptops to authenticate using LDAP or Kerberos and create a local user with home directory in /home/ when a usre in LDAP logs in via KDM or GDM for the first time, and cache the password for offline checking, as well as caching group memberhips and other relevant LDAP information. The libpam-mklocaluser package was created to make sure the local home directory is in /home/, instead of /site/server/directory/ which would be the home directory if pam_mkhomedir was used. To avoid confusion with support requests and configuration, we do not want local laptops to have users in a path that is used for the same users home directory on the home directory servers. One annoying problem with gdm is that it do not show the PAM message passed to the user from libpam-mklocaluser when the local user is created. Instead gdm simply reject the login with some generic message. The message is shown in kdm, ssh and login, so I guess it is a bug in gdm. Have not investigated if there is some other message type that can be used instead to get gdm to also show the message. If you want to help out with implementing this for Debian Edu, please contact us on debian-edu@lists.debian.org.

That's a phrase I fully adhere to (I don't want to work), but that's not the point. There's a catchy song that I like a lot, it's sung in French and sounds like an old song (most places say it's an Edith Piaf's song). The chorus goes "Je ne veux pas travailler, je ne veux pas d jeuner...", and one would imagine that that's indeed the title. But nothing of this is true, once again the Internets is full of fail. The band who performs the song is called Pink Martini, two of them are the authors of it, and they are from Oregon. It was recorded in 1997 (some audio filters did the magic), and it's called "Sympathique". It also seems that it was a big success, but probably not in my part of the world. I thought that somebody should set this straight somewhere, as I couldn't find anybody speaking of this confusion. Having settled that, I invite you to listen to this wonderful song, and sing along that you don't wanna work (forget about the rest of the lyrics, it's a love song :-)). Tags: Planet Debian, Planet Lugfi, M sica

[107108.433300] chrome[12262]: segfault at bbadbeef ip 0000000000fbea18 sp 00007fffcf348100 error 6 in chrome[400000+27ad000] When I first tried running the Google Chrome web browser [1] on SE Linux it recursively displayed the error message in the above picture, it first displayed the error and then displayed another error while trying to display a web page to describe the error. The kernel message log included messages such as the above message, it seems that some pointers are initialised to the value 0xbbadbeef to make debugging easier and more amusing. V8 error: V8 is no longer usable (v8::V8::AddMessageListener()) When I ran Chrome from the command-line it gave the above error message (which was presumably somewhere in the 8MB ~/.xsession-errors file generated from a few hours of running a KDE4 session). type=AVC msg=audit(1274070733.648:145): avc: denied execmem for pid=12833 comm= chrome scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process
type=SYSCALL msg=audit(1274070733.648:145): arch=c000003e syscall=9 success=no exit=-131938567594024 a0=7fd863b41000 a1=40000 a2=7 a3=32 items=0 ppid=1 pid=12833 auid=4294967295 uid=1001 gid=1001 euid=1001 suid=1001 fsuid=1001 egid=1001 sgid=1001 fsgid=1001 tty=pts4 ses=4294967295 comm= chrome exe= /opt/google/chrome/chrome subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
type=ANOM_ABEND msg=audit(1274070733.648:146): auid=4294967295 uid=1001 gid=1001 ses=4294967295 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=12833 comm= chrome sig=11 V8 is the Google Javascript system which compiles JavaScript code and thus apparently needs read/write/execute access to memory [2]. In /var/log/audit/audit.log I saw the above messages (which would have been in the kernel message log as displayed by dmesg if I didn t have auditd running). The most relevant parts are that execmem access was requested and that it was by system call 9. From linux/x86_64/syscallent.h in the strace source I discovered that system call 9 on the AMD64 architecture is sys_mmap. Does anyone know a good way to discover which system call has a given number on a particular architecture without reading strace source code? Attempts to strace the Google Chrome process failed, Chrome gave the error Failed to move to new PID namespace after clone() failed. Clone was passed the flag 0 20000000 which according to /usr/include/linux/sched.h is CLONE_NEWPID. It seems that programs which create a new PID namespace (as Google Chrome does) can t be straced as the clone() call fails. It s a pity that Chrome doesn t have an option to run without using this feature, losing the ability to strace it really decreases my ability to find and report bugs in the program I m sure that the Google developers want people like me to be able to help them find bugs in their code without undue effort. Anyway the solution to this problem to allow it to run on the SE Linux Targeted configuration is to run the command chcon -t unconfined_execmem_exec_t /opt/google/chrome/chrome which causes the Chrome browser to run in the domain unconfined_execmem_t which is allowed to do such things. Of course we don t want Chrome processes to run unconfined, I think that the idea I had in 2008 for running Chrome processes in different SE Linux contexts is viable and should be implemented [3]. As a general rule if you are running a program from the command-line on SE Linux with the Targeted configuration (the default and most common configuration) then any time you see an execmem failure logged to the kernel message log or the audit subsystem then you can change the context of the program to unconfined_execmem_exec_t to make the problem go away. Note that this isn t necessarily a good thing to do, sometimes it s best to change the program to not require such access. But it seems that in this case the design of V8 requires write/execute memory access to pre-compile JavaScript code.

• [1] http://www.google.com/chrome
• [2] http://code.google.com/apis/v8/
• [3] http://etbe.coker.com.au/2008/09/02/google-chrome-the-security-implications/

I have something of an informal goal of learning a new programming language every few years. It s not so much a goal as it is something of a discomfort. There are so many programming languages out there, with so many niches and approaches to problems, that I get uncomfortable with my lack of knowledge of some of them after awhile. This tends to happen every few years. The last major language I learned was Haskell, which I started working with in 2004. I still enjoy Haskell and don t see anything displacing it as my primary day-to-day workhorse. Yet there are some languages that I d like to learn. I have an interest in cross-platform languages; one of my few annoyances with Haskell is that it can t (at least with production quality) be compiled into something like Java bytecode or something else that isn t architecture-dependent. I have long had a soft spot for functional languages. I haven t had such a soft spot for static type checking, but Haskell s type inference changed that for me. Also I have an interest in writing Android apps, which means some sort of Java tie-in would be needed. Here are my current candidates:

• JavaScript. I have never learned the language but dislike it intensely based on everything I have learned about it (especially the diverging standards of implementation). Nevertheless, there are certain obvious reasons to try it the fact that most computers and mobile phones can run it out of the box is an important one.
• Scheme. Of somewhat less interest since I learned Common Lisp quite awhile back. I m probably pretty rusty at it, but I m not sure Scheme would offer me anything novel that I can t find in Haskell except for the ability to compile to JVM bytecode.
• Lua it sounds interesting, but I m not sure if it s general-purpose enough to merit long-term interest.
• Scala sounds interesting a OOP and FP language that compiles to JVM bytecode.
• Smalltalk. Seems sad I ve never learned this one.
• There are some amazing webapps written using Cappuccino. The Github issue interface is where I hear about this one.
• Eclipse. I guess it s mostly not a programming language but an IDE, but then there s some libraries (RCP?) or something with it so to be honest, I don t know what it is. Some people seem very excited about it. I tried it once, couldn t figure out how to just open a file and start editing already. Made me feel like I was working for Initech and wouldn t get to actually compile something until my TPS coversheets were in order. Dunno, maybe it s not that bad, but I never really understood the appeal of something other than emacs/vi+make.
• A Haskell web infrastructure such as HSP or hApps. Not a new language, but might as well be

Of some particular interest to me is that Haskell has interpreters for Scheme, Lua, and JavaScript as well as code generators for some of these languages (though not generic Haskell-to-foo compilers). Languages not in the running because I already know them include: OCaml, POSIX shell, Python, Perl, Java, C, C++, Pascal, BASIC, Common Lisp, Prolog, SQL. Languages I have no interest in learning right now include Ruby (not different enough from what I already know plus bad experiences with it), any assembly, anything steeped in the Microsoft monoculture (C#, VB, etc.), or anything that is hard to work with outside of an Emacs or vim environment. (If your language requires or strongly encourages me to use your IDE or proprietary compiler, I m not interested that means you, flash.) Brief Reivews of Languages I Have Used To give you a bit of an idea of where I m coming from:

• C: Not much to say there. I think its pros and cons are well-known. I consider it to be too unwieldy for general-purpose use these days, though find myself writing code in it every few years for some reason or other.
• Perl: The first major interpreted language I learned. Stopped using it entirely after learning Python (didn t see any advantage of Perl over Python, and plenty of disadvantages.)
• Python: Used to really like it. Both the language and I have changed. It is no longer the clean language it was in the 1.5 days. Too many lists-that-aren t-lists, __underscorethings__, etc. Still cleaner than Perl. It didn t scale up to large projects well, and the interpreted dynamic nature left me not all that happy to use it for some tasks. Haven t looked at Python 3, but also it probably isn t ready for prime time yet anyhow.
• Java: Better than C++ for me. Cross-platform bytecode features. That s about all that I have to say about it that s kind. The world s biggest source of carpal tunnel referrals in my book. Mysteriously manages to have web apps that require 2GB of RAM just to load. Dunno where that came from; Apache with PHP and mod_python takes less than 100M.
• Haskell: A pretty stellar mix of a lot of nice features, type inference being one of the very nice ones in my book. My language of choice for almost all tasks. Laziness can be hard for even experienced Haskellers to understand at times, and the libraries are sometimes in a bit of flux (which should calm down soon). Still a very interesting language and, in fact, a decent candidate for my time as there is some about it I ve never picked up, including some modules and web toolkits.
• OCaml: Tried it, eventually discarded it. An I/O library that makes you go through all sorts of contortions to be able to open a file read/write isn t cool in my book.

After more than a year of using ikiwiki to run bzed.de I thought it would be a good time replace the darkish-brown style by something bright. Also I wanted to get righ of the massive changes I had to do on the template files to make the old layout work. Unfortunately I hit one of the - in my opinion - major problems in the ikiwiki templates again: You can't rely on all <div>s being available on all pages, which is quite annoying when you need them to style the page with CSS. So I had to make a tiny change to page.tmpl:

diff --git a/templates/page.tmpl b/templates/page.tmpl
index 8a9911f..dbf78a0 100644
--- a/templates/page.tmpl
+++ b/templates/page.tmpl
@@ -111,8 +111,8 @@
 <TMPL_VAR CONTENT>
 <TMPL_IF HTML5></section><TMPL_ELSE></div></TMPL_IF>
-<TMPL_IF COMMENTS>
 <TMPL_IF HTML5><section id="comments"><TMPL_ELSE><div id="comments"></TMPL_IF>
+<TMPL_IF COMMENTS>
 <TMPL_VAR COMMENTS>
 <TMPL_IF ADDCOMMENTURL>
 <div class="addcomment">
@@ -121,8 +121,8 @@
 <TMPL_ELSE>
 <div class="addcomment">Comments on this page are closed.</div>
 </TMPL_IF>
-<TMPL_IF HTML5></section><TMPL_ELSE></div></TMPL_IF>
 </TMPL_IF>
+<TMPL_IF HTML5></section><TMPL_ELSE></div></TMPL_IF>
 <TMPL_IF HTML5><footer id="footer" class="pagefooter"><TMPL_ELSE><div id="footer" class="pagefooter"></TMPL_IF>
 <TMPL_IF HTML5><nav id="pageinfo"><TMPL_ELSE><div id="pageinfo"></TMPL_IF>

Everything else is a bit of CSS in local.css and some images. There are still various things which could be optimized, but there are more important things to do now :).

After several other Debian developers convinced me that a ShortURL service, which is under control of a Debian Developer would be useful for them, I've spent some time to write the necessary code for it. And if it will be used regulary, I'll ask DSA if they want to host it on a proper machine. So I'm happy to announce the public beta test of deb.li (also available under go.debian.net)! Please note that neither the content of the pages nor the CSS is finished... As this should not become just another random, spammer-attracting ShortURL service, I will not provide a web based form to add new URLs. Instead new URLs have to be added via a simple JSON-RPC based interface. Other ways to add new URLs will be added on request (or by sending patches ;)), at least an email-gateway similar to db.debian.org is planned. The small piece of documentation which exists so far is available at wiki.debian.org/deb.li And if you want to give it a try now, log into alioth.debian.org and have a look into

/var/lib/gforge/chroot/home/users/bzed/godebian-client

- the usage is documented in the README file and should be pretty straight forward. I hope it will be useful - comments, bugreports and patches are welcome!

Yesterday I finally found the time to update gimp-plugin-registry, the (hopefully!) largest and best collection of plugins for The GIMP. As usual here comes a short summary of the changes:

• The wonderful scripts from El Samuko are included now:
  • Antique Photo Border Script
  • Che Guevara Script
  • Cyanotype Script
  • Difference Layer Script
  • Escape Line Script
  • Film Grain Script
  • First Photo Border Script
  • Lomo Script with Old Style Colors
  • Movie 300 Script
  • National Geographic Script
  • Obama "HOPE" Script
  • Rainy Landscape Script
  • Photochrom Script
  • Sprocket Hole Script
  • Sunny Landscape Script
  • Technicolor 2 Color Script
  • Technicolor 3 Color Script
  • Vintage Look Script
• Included the X11 Mouce Curser (XMC) plugin as requested by KiBi.
• Removed the GREYStoration plugin. This plugin was superseded by the gimp-gmic plugin, which is built from the gmic source. Most of the packaging work was done by Jakub Wilk (thanks!), it is waiting in NEW currently. Btw, gmic lives in the collab-maint git folder, don't hesitate to help with the packaging work.
• The following plugins were updated:
  • focus-blur
  • contactsheet
  • normalmap
  • save-for-web
  • seperate+

Hope you like my work, suggestions and bug reports are welcome as usual!

on DMs and the packages they maintain The notion of Debian Maintainer (DM) has been with Debian for about 3 years. As of now, Debian has approximately 120 DMs, which maintain a significant part of the packages in the archive. I'm hereby happy to evilly spoil that Enrico Zini has just set up an index of Debian Maintainers and of the packages they maintain. The index is linked from the people section of our website as a symbolic step in giving more credit to DMs. Now, if anyone would like to setup a nice graph for the statistics page, which monitors the evolution of DMs (and DDs?), that would be useful.
Any idea on how to do that retroactively too?

So someone thought it might be a good idea to switch the default from the time-honoured Debian style ("booting foo... ok") to the RedHat style ("<left-align>booting foo... <right-align>[ok]"). I don't think the switch adds any value (it's not like it looked bad or anything in the past); in fact, I think it's a bad idea. And I even have a technical reason. On my 26" 1920x1200 screen (when the i950 driver detects it properly and actually sets the framebuffer to that resolution), the output looks like this: Now imagine you get to see that screen for about two to five seconds. Please tell me which two initscripts failed. And no, you cannot use a ruler. Bonus points for if you manage to do so while the text is also moving upwards, which tends to happen when systems boot. Also note that because kernel mode-settings has become the default, a lot more people are going to be using framebuffers. Am I the only one who thinks this is a bad idea?

I wrote a bit ago a blog post about what debian kde is missing of distribution specific things Some of the more important things includes:

• A Qt based debian installer
• Tools to manage 3rd party modules and firmware and such
• Debconf frontend that fits in
• Report bug interface

Installer
I don t think it is the most important thing. Wether or not the graphical installer is using gtk or qt is not that important. I would love to see it happen, but it is not something I feel like putting my time in. Others are most welcome.
It will give the advantage of giving the installer the possibility to use the framebuffer directly. Modules and firmwares and such
Someone is saying that ubuntu has something called jockey that does this exact thing, with a KDE and a Gnome frontend. Unfortunately, it is python, so it is something I will really avoid. I m hoping that me mentioning it here will make someone into python&debian pick it up and bring it to debian.
It is apparantly some nice magic around discover-data. Debconf frontend that fits
A lot of work has been put into proper perl-qt bindings and they will hopefully be ready for kde4.5, which is unfortunately a series too late for Squeeze :/. But when that has happened, we just need some perl guy to adapt the old frontend to debconf. Reportbug interface
There is already a tool called reportbug-ng that is a qt interface to reporting bugs. All in all, it looks like we are quite far already. We just need to get the last bits put together. Someone: pickup jockey. And note that the comment field isn t a place to report bugs. They will be removed.

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.

There are two other approaches that are likely to come up tonight; see this message for details. These mechanisms require significantly lower infrastructure than Moonshot, but do not provide all the benefits. One question is whether there is a continuum of use-cases depending on what level of investment in client changes are made.

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

I find it surreal to have people guessing at my motivations when they could just ask me. On top of all that, I find it weird that people spend so much time with in-fighting. I just want my system not to suck. Some time ago (during in the Ubuntu Karmic development cycle maybe in September 2009), I started having giant problems with my build system. All I/O would start to stall, wait times would surge, and usually my entire system would just go unresponsive with the disk light on solid. This scared the crap out of me, and it wasn t entirely obvious what was triggering it. No one else seemed to be seeing it. I managed to start tracking things using latencytop , and saw stuff like liferea going crazy. As I eliminated more and more things, I eventually settled on it being a problem with umount, and I reported an Ubuntu bug. It seemed to look like an upstream bug that no one else but the reporter could reproduce either. Since no one else was seeing this issue, and it seemed related to LVM snapshots, I migrated off of snapshots, and started using aufs overlays for my builds. For a while, it seemed like things went away. It didn t, and I started hitting it again. I opened a new (now famous) bug in Ubuntu, since now snapshots weren t in the picture, and I didn t want to confuse the earlier history. I managed to find a relatively minimal test-case too. A few other people commenting on the bug were seeing the problem now too, but it was less pronounced for them. As an aside, this wasn t a just wait a few seconds longer kind of issue on my system. A single umount would last 30-40 minutes. And when I m doing parallel builds of security updates, this would turn into my system being unavailable for hours at a stretch. Since none of the kernel developers I was in contact with were able to track down the root cause, I asked Ted Ts o in email if he could just quickly peek in on this for me, since I figured he d be in a good position to confirm or deny it. I didn t want to start wasting upstream time with this if it wasn t reproducible (see earlier upstream kernel bug). To my great relief, Ted found a few minutes to check it, and was able to immediately confirm it and give me a viable work-around ( sync; umount ) for the time being. I confirmed the work-around, and went off to do other things. A while later, Ted came back to deliver a bit of a rant, the purpose of which was not clear to me, but I ultimately ignored it I didn t seem directed at me. I just wanted my system operating normally, and he d done me a favor to check in on it and got me a work-around. More time passes, and I eventually get caught in another I/O-wait melt-down. On investigation, it seemed that the in-kernel work-around in the Ubuntu kernel totally back-fired on me in some cases, rendering even the user-space work-around useless. After investigating the Ubuntu-specific work-around, I re-read Ted s rant in the course of researching what had happened during this bug s triage. It seemed that Ted was basically saying:
this is an upstream problem
RedHat hasn t run into it and he didn t know why I figured I should confirm for myself if Fedora was affected, so downloaded and installed Fedora to double-check there. Since I was able to reproduce it there, I opened an upstream bug, linking back to the original Ubuntu bug, and then went to open a bug in the Fedora tracker, linking back to upstream. And it seems to be these actions that everyone has jumped on. I will now bore you with the reality of my motivations: I wanted to fix the bug so no one would end up experiencing the same pain I d been through over the last 6 months. The bug was, from my perspective, a serious issue. Since I d managed to reproduce it in another distro, it was my duty as a Free Software developer to report it to them. And, in what I felt was an unambiguous gesture, I made sure to include the link to the upstream kernel bug. Reproducing it in Ubuntu, in Fedora, and with a stock kernel had me confident that it was an upstream issue. While Ted did correctly suspect the issue was upstream, I really didn t want to just open an upstream bug and have it be ignored. I wanted some additional proof of reproduction, which I got when I tested it on Fedora. So, I m rather saddened that so many people spent so much time questioning my motivations, making fun of Canonical, or doing anything other than trying to just simply solve this problem. I m totally disinterested in inter-distro fighting. Instead, I continue to assume we re all on the same team, fighting a philosophical battle against close-source software. And in that regard, I think it s still true. If I ignore the rants and jeering, I come away thankful for all the people that spent time trying reproduce the issue at Canonical, at RedHat, and in the larger community. I m hugely thankful that Ted made some time to let me know I wasn t crazy, and there was actually a problem. I m thankful for having some work-arounds, and I m thankful that the root cause was eventually ferreted out, with some possible solutions. I m even thankful that some people on the LWN thread saw that, far from malicious, I was trying to be helpful with the bug. I just wanted my filesystem not to eat my computer. And I was hoping other people could maybe help me, since I m not a filesystem expert. The drama around this bug is pathetic, and now by talking about it for almost 1000 words, I m just as guilty.

In February 2009, my friend dim tried to force me using Emacs. I know a couple of people using it and Gnus for reading their mail, and it always made me curious. At that time, more than a year ago, Emacs 22 and Gnus did not seem usable from my point of view. But around mid February, with the help of dim, I tried again to start using Emacs. Actually, this was not something new for me. I (very basically) used Emacs between 2000 and 2006. In 2006, when I finished the university and started working at Easter-eggs, I met a couple of vim enthusiasts. They taught me how to use it in various ways, and I started to know more about vim than Emacs, so I switched. This time, I started by configuring it, but reading the manual and also learning a bit of Lisp. It took me several weeks, but step by step I learned many, many things. And I must admit, I liked it. I've configured and starting to use some very important mode, like Gnus, Muse, the famous Org mode or even ERC. I'll probably talk about various Emacs related things in the near future, since I already wrote more than a thousand lines of Lisp in the last 2 months. Anyhow, I'd just conclude by asserting that my new Emacs/Gnus/Org/ERC setup beats my old vim/mutt/nothing/irssi to the death with a baseball bat. :-)

I recently read an introductory article in an IT magazine on the increased usage of new currencies. It briefly mentioned the work of a researcher called Arthur Brock in using those currencies within open source communities. While I did not find more details on the research, it led me to think again about Debian s relation with money. The reason why we have troubles using money to pay the time spent by our developers is that money is scarce and it s thus next to impossible to be fair in the way money is spent among us. So why not invent a new currency that is not scarce and that would encourage the kind of work that we really value? Apparently there is free software out there to build new currencies: see metacurrency.org or openmoney.org. Let s call the new currency swirly/swirlies for the sake of the examples below. There are then multiple ways to create a small economy within the community and/or even create bridges with the national currencies:

• we could have auctions (priced in swirlies) to redistribute goods among us (say I have this unused laptop and I want to give it away to someone who could make use of it within Debian)
• Debian sponsors/partners could offer discounts codes on their products and Debian would exchange them against the Debian-specific currency (inspired by community way);
• swirlies could be used to get funding to attend debconf and/or other meetings;
• we could donate our swirlies as bounties on important projects that we want to see implemented, we could even grant swirlies to release managers to help them drive the project towards a release (they would not end up in their accounts but they could use them to motivate people to work on release blockers);

I m sure we can come up with many similar ideas. Feel free to share yours in the comments. Partagez cet article / Share This

One thing that happens periodically is that I start a process from an interactive shell, discover that it takes longer than expected, and then want to know how long it took. Basically it s a retrospective need to have run time whatever that I discover after the process has been running for long enough that I don t want to restart it. My current procedure in such situations is to run ps from another session to discover when it started and then type date to display when it ends. A quick test with strace showed that bash uses the wait4() system call to determine when a process ends, but passes NULL as the last parameter. If it passed the pointer to a struct rusage then it would have the necessary data. I think it would be a really good feature for a shell to allow you to type something like echo $TIME_LAST_CMD to see how long the last command took. For the common case where you aren t interested in that data it would only involve an extra parameter to the wait4() system call, a small amount of memory allocated for it, and to store yet another environment variable in it s list. A quick Google search didn t show any way of filing wishlist bugs against Bash and I don t think that this is a real bug as such so I haven t filed a bug report. If anyone reads my blog and has some contact with the Bash people then please pass this idea along if you think it s worthy of being included.

I spent last week at the Ubuntu Developer Summit in Belgium, where we kicked off the 10.10 development cycle. Due to our time-boxed release cycle, not everything discussed here will necessarily appear in Ubuntu 10.10, but this should provide a reasonable overview of the direction we re taking. Presentations While most of our time at UDS is spent in small group meetings to discuss specific topics, there are also a handful of presentations to convey key information and stimulate creative thinking. A few of the more memorable ones for me were:

• Mark Shuttleworth talked about the desktop, in particular the introduction of the new Unity shell for Ubuntu Netbook Edition
• Fanny Chevalier presented Diffamation, a tool for visualizing and navigating the history of a document in a very flexible and intuitive way
• Rick Spencer talked about the development process for 10.10 and some key changes in it, including a greater focus on meeting deadlines for freezes (and making fewer exceptions)
• Stefano Zacchiroli, the current Debian project leader, gave an overview of how Ubuntu and Debian developers are working together today, and how this could be improved. He has posted a summary on the debian-project mailing list.

The talks were all recorded, though they may not all be online yet. Foundations The Foundations team provides essential infrastructure, tools, packages and processes which are central to the development of all Ubuntu products. They make it possible for the desktop and server teams to focus on their areas of expertise, building on a common base system and development procedures. Highlights from their track:

• Early on in the week, they conducted a retrospective to discuss how things went during the 10.04 cycle and how we can improve in the future
• One of their major projects has been about revision control for all of Ubuntu s source code, and they talked last week about what s next
• We re aiming to provide btrfs as an install-time option in 10.10
• In order to keep Ubuntu moving forward, the foundations team is always on the lookout for stale bits which we don t need to keep around anymore. At UDS, they discussed culling unattended packages, retiring the IA64 and SPARC ports and other spring cleaning
• There was a lot of discussion about Upstart, including its further development, implications for servers, desktops and the kernel, and the migration of server init scripts to upstart jobs
• After maintaining two separate x86 boot loaders for years, it looks like we may be ready to replace isolinux with GRUB2 on Ubuntu CDs

Desktop The desktop team manages both Desktop Edition and Netbook Edition, on a mission to provide a top-notch experience to users across a range of client computing devices. Highlights from their track:

• A key theme for 10.10 is to help developers to create applications for Ubuntu, by providing a native development environment, improving Quickly, improving desktopcouch, making it easier to get started with desktopcouch, and enabling developers to deliver new applications to Ubuntu users continuously
• With more and more touch screen devices appearing, Ubuntu will grow some new features to support touch oriented applications
• The web browser is a staple application for Ubuntu, and as such we are always striving for the best experience for our users. The team is looking ahead to Chromium, using apport to improve browser bug reports, and providing a web-oriented document capability via Zoho
• Building on work done in 10.04, we will aim to make simple things simple for basic photo editing
• Security-conscious users may rest easier knowing that the X window system will run without root privileges where kernel modesetting is supported

Server/Cloud The server team is charging ahead with making Ubuntu the premier server OS for cloud computing environments. Highlights from their track:

• Providing more powerful tools for managing Ubuntu in EC2 and Ubuntu Enterprise Cloud infrastructure, including boot-time configuration, image and instance management, and kernel upgrades
• Improving Ubuntu Enterprise Cloud by adding new Eucalyptus features (such as LXC container support, monitoring, rapid provisioning, and load balancing. If you ever wanted to run a UEC demo from a USB stick, that s possible too.
• Providing packaged solutions for cloud building blocks such as hadoop and pig, Drupal, ehcache, Spring, various NOSQL databases, web frameworks, and more
• Providing turn-key solutions for free software applications like Alfresco and Kolab
• Making Puppet easier to deploy, easier to configure, and easier to scale in the cloud

ARM Kiko Reis gave a talk introducing ARM and the corresponding opportunity for Ubuntu. The ARM team ran a full track during the week on all aspects of their work, from the technical details of the kernel and toolchain, to the assembly of a complete port of Netbook Edition 10.10 for several ARM platforms. Kernel The kernel team provided essential input and support for the above efforts, and also held their own track where they selected 2.6.35 as their target version, agreed on a variety of changes to the Ubuntu kernel configuration, and created a plan for providing backports of newer kernels to LTS releases to support deployment on newer hardware. Security Like the kernel team, the security team provided valuable input into the technical plans being developed by other teams, and also organized a security track to tackle some key security topics such as clarifying the duration of maintenance for various collections of packages, and the ongoing development of AppArmor and Ubuntu s AppArmor profiles. QA The QA team focuses on testing, test automation and bug management throughout the project. While quality is everyone s responsibility, the QA team helps to coordinate these activities across different teams, establish common standards, and maintain shared infrastructure and tools. Highlights from their track include:

• There was a strong sense of broadening and deepening our testing efforts, mobilizing testers for specific testing projects, streamlining the ISO testing process by engaging Ubuntu derivatives and fine-tuning ISO test cases, and reactivating the community-based laptop testing program
• In support of this effort, there will be projects to improve test infrastructure, including enabling tests to target specific hardware and tracking test results in Launchpad
• There is a continuous effort to improve high-volume processing of bug reports, and two focus areas for this cycle will be tracking regressions (as these are among the most painful bugs for users) and improving our response to kernel bugs (as the kernel faces some special challenges in bug management)

Design The design team organized a track at UDS for the first time this cycle, and team manager Ivanka Majic gave a presentation to help explain its purpose and scope. Toward the end of the week, I joined in a round table discussion about some of the challenges faced by the team in engaging with the Ubuntu community and building support for their work. This is a landmark effort in mating professional design with free software community, and there is still much to learn about how to do this well. Community The community track discussed the usual line-up of events, outreach and advocacy programs, organizational tools, and governance housekeeping for the 10.10 cycle, as well as goals for improving the translation of Ubuntu and related resources into many languages. One notable project is an initiative to aggressively review patches submitted to the bug tracker, to show our appreciation for these contributions by processing them more quickly and completely.

Conference Management systems are web applications designed to make the lives of conference organisers easier. They usually include features such as registration, payment, paper submission and review, scheduling and publishing of announcements.

Since Wikipedia is apparently not a place for such a "spammy list," I figured I should at least post this here:

Name	Used by	License	Programming Language
A Conference Toolkit	YAPC::Eu	Artistic License	Perl
ConMan	Utah Open Source Conference, Texax Linux Fest	GPL	Python (Django)
Open Conference Systems	various academic conferences	GPL	PHP
OpenConferenceWare	Open Source Bridge	MIT	Ruby on Rails
Pentabarf	DebConf, FOSDEM, CCC	GPL	Ruby on Rails
SCALEreg	SCALE	GPL	Python (Django)
Zookeepr	linux.conf.au	GPL	Python (Pylons)

If you know of any other Open Source systems, please leave a comment!