It seems I'm catching up with the pace of this course I'm following and that is compelling me to go back to posting on my blog, Arte y cultura en circulaci n: crear y compartir en tiempos digitales . This week's lesson is (again, in Spanish) Las fronteras del remix (the boundaries of remixes). An interesting text, open to everybody (regardless of whether you are signed up for the course or, I hope, whether time has passed since the course took place). And this week's homework is to find "our favorite" non-original work (I picked one among my favorite works And, yes, this is partly because I am part of the "club" of deniers of true originality: We cannot create anything without being part of a surrounding culture, without a common heritage and language with which we speak to our audience) and to find something about it, anything considered important or significative as to its antecedents. What do I like about this work, what grabs my attention. Do I consider it to be a true new creative work? Why? I am taking as an example Leo Masliah, an Uruguayan writer and musician (writer and interpreter). I have followed and enjoyed Masliah's work since 1996, and although by far I'm most familiar with his musical works, I have two books (a novel and a series of short stories). Among his facets, I most enjoy the acid, nihilistic/dadaistic streaks. I chose three of his songs to talk about I am linking to anonline resource where possible, but uploading the three songs to this blog to make his work better known, so that people understand what I talk about, and with my best intentions. Of course, if there is any request to remove the material, I will do it right away. I hope this can be seen as fair/academic use, although this blog is somewhat widely read.

La recuperaci n del unicornio

This song was in the first Masliah cassette I came across, Although musically it is an original work, the lyrics are a clear, almost line-by-line reply to the ever-repeated Unicornio song, by Silvio Rodr guez. This song (which I'm sure that every Spanish speaker reading this lines knows, like it or not It defines for me a good deal of Rodr guez hyper-sweetness and clicheness) has been analyzed over and over looking for a meaning. Silvio recorded this song in 1981, and by 1987 Masliah published this answer, mocking each of the lines.
So, this song can be seen as an original creation, as it contains no literal copy neither of the music nor of the lyrics of the original, but it cannot be understood without being familiar with Silvio's lost unicornio. It would just be an almost-dadaistic rant. But every person that has tasted Silvio Rodr guez cloying song will surely laugh with this one.

No necesitamos otro h roe Balderrama

I find this to be a very unique piece. It bonds together Argentinian folklore and USA pop.
Masliah sings the famous Argentinian song Zamba de Balderrama, (Castilla / Leguizam n), a song lamenting that the very popular bar and artist stage Balderrama, in Salta (North-Western corner of Argentina), seemed to be on the brink of closing. Of course, when Mart n, Constanza, Regina and me went to Balderrama in July 2010, the danger of closing this place had long been averted. And basically every Argentinian knows this song by heart.
The interesting part is that Masliah sings this song (as he presents it as the closing piece for one of his concerts) being short on time, and decides to present two acts together: Zamba de Balderrama and We don't need another hero, by Tina Turner, from the Mad Max soundtrack. So, of course, even if it's obvious that Masliah had to stretch bits to make them fit together, he achieved a very funny, interesting and unique blend of two completely unrelated works. He derives from one as well as from the other, but creates something unique and new.

Donna Lee

I was thinking what to write for this assignment , and had already chosen the two other songs. Yesterday, we were visiting our friends Octavio and Claudia, in Guanajuato, and I heard for the first time the original(?) version of Donna Lee, by Miles Davis (although often credited to Charlie Parker). That led me to remember Masliah's interpretation, in his Cl sicos album. This album is basically made up with similar excercises: Taking an instrumental piece, with Masliah singing over it. Some of the lyrics follow the story (i.e. the children stories), others just talk nonsense to illustrate a point (i.e. "La voz del medio", "the middle voice") follows the non-protagonist score trying not to grab much attention to the lyrics but to highlight the often ignored melody)... Donna Lee is just a fun excercise on following the melody asking what was in the head of the author that led him to invent such a strange, hard music.

Masliah is a great music performer, although often it seems he tries to hide it (i.e. by abusing the dissonances, ex-profeso singing off-key, etc), and a very funny and crazy author. Most of his works have a deep satirical tone, and it's common to find either simple winks or complete "borrowings" in a clear remix fashion, but nobody will doubt on the originality of his works.

Attachment	Size
07-Donna Lee.MP3	1.79 MB
16 No necesitamos otro h roe - Balderrama.mp3	3.49 MB
Leo Masl ah-La Recuperaci n Del Unicornio.mp3	1.87 MB

The third wheezy based beta release of Debian Edu was wrapped up today. This is the release announcement from Holger Levsen:

Hi, it is my pleasure to announce the third beta release (beta 2 for short) of Debian Edu / Skolelinux based on Debian Wheezy! Please test these images extensivly, if no new problems are found we plan to do this final Debian Edu Wheezy release this coming weekend. We are not aware of any major problems or blockers in beta2, if you find something, please notify us immediately! (More about the remaining steps for the Edu Wheezy release in another mail to the edu list tonight or tomorrow...) Noteworthy changes and software updates for Debian Edu 7.1+edu0~b2 compared to beta1:

• The KDE proxy setup has been adjusted to use the provided wpad.dat. This also gets Chromium to use this proxy.
• Install kdepim-groupware with KDE desktops to make sure korganizer understand ical/dav sources.
• Increased default maximum size of /var/spool/squid and /skole/backup on the main server.
• A source DVD image containing all source packages is now available as well.
• Updates for chromium (29.0.1547.57-1~deb7u1), imagemagick (6.7.7.10-5+deb7u2), php5 (5.4.4-14+deb7u4), libmodplug (0.8.8.4-3+deb7u1+git20130828), tiff (4.0.2-6+deb7u2), linux-image (3.2.0-4-486_3.2.46-1+deb7u1).

Where to get it: To download the multiarch netinstall CD release you can use

• ftp://ftp.skolelinux.org/skolelinux-cd/wheezy/debian-edu-7.1+edu0~b2-CD.iso
• http://ftp.skolelinux.org/skolelinux-cd/wheezy/debian-edu-7.1+edu0~b2-CD.iso
• rsync -avzP ftp.skolelinux.org::skolelinux-cd/wheezy/debian-edu-7.1+edu0~b2-CD.iso .

The SHA1SUM of this image is: 3a1c89f4666df80eebcd46c5bf5fedb866f9472f To download the multiarch USB stick ISO release you can use

• ftp://ftp.skolelinux.org/skolelinux-cd/wheezy/debian-edu-7.1+edu0~b2-USB.iso
• http://ftp.skolelinux.org/skolelinux-cd/wheezy/debian-edu-7.1+edu0~b2-USB.iso
• rsync -avzP ftp.skolelinux.org::skolelinux-cd/wheezy/debian-edu-7.1+edu0~b2-USB.iso .

The SHA1SUM of this image is: 702d1718548f401c74bfa6df9f032cc3ee16597e The Source DVD image has the filename debian-edu-7.1+edu0~b2-source-DVD.iso and the SHA1SUM 089eed8b3f962db47aae1f6a9685e9bb2fa30ca5 and is available the same way as the other isos. How to report bugs For information how to report bugs please see
http://wiki.debian.org/DebianEdu/HowTo/ReportBugs About Debian Edu and Skolelinux Debian Edu, also known as Skolelinux, is a Linux distribution based on Debian providing an out-of-the box environment of a completely configured school network. Immediately after installation a school server running all services needed for a school network is set up just waiting for users and machines being added via GOsa , a comfortable Web-UI. A netbooting environment is prepared using PXE, so after initial installation of the main server from CD or USB stick all other machines can be installed via the network. The provided school server provides LDAP database and Kerberos authentication service, centralized home directories, DHCP server, web proxy and many other services. The desktop contains more than 60 educational software packages and more are available from the Debian archive, and schools can choose between KDE, Gnome, LXDE and Xfce desktop environment. This is the seventh test release based on Debian Wheezy. Basically this is an updated and slightly improved version compared to the Squeeze release. Notes for upgrades from Alpha Prereleases Alpha based installations should reinstall or downgrade the versions of gosa and libpam-mklocaluser to the ones used in this beta release. Both alpha and beta0 based installations should reinstall or deal with gosa.conf manually; there are two options: (1) Keep gosa.conf and edit this file as outlined on the mailing list. (2) Accept the new version of gosa.conf and replace both contained admin password placeholders with the password hashes found in the old one (backup copy!). In both cases all users need to change their password to make sure a password is set for CIFS access to their home directory. cheers,
Holger

DebConf 13 report (by Andreas Tille) General impression I'm beginning my DebConf report in an unofficial "Scenic Hacklab" right at the edge of the lake in Yverdon. This is the right place to memorise the last days. When I started from this place cycling to Le Camp 12 days ago I was full of great expectations and what should I say - the reality has even beaten these. Once it comes about comparing DebConfs even if it is an unfair comparison due all the differences my secret long term favourite was Helsinki very closely followed by Argentina and also very closely followed by all the other great DebConfs I joined (and I joined all in Europe). Would Le Camp be able to beat it? The short answer is: Yes, it is now my favourite DebConf while I think I do not suffer from the last-Debconf-was-the-best-DebConf-syndrome (and I realised there are others thinking the same). As you might probably know I'm a bit addicted to swimming. While Helsinki had admittedly the better conditions I was at least able to fix the distance issue using my bicycle. (Hey, those Le Camp photographers did a great job in hiding the fact that you can not actually touch the lake right from the meadow of Le Camp.) Being able to have my bicycle at DebConf scored some extra points. However, the really great view of the lake, the inspiring "Scenic Hacklab" which was my favourite place has bumped DebConf13 at first place in my personal ranking. So it comes quite natural to say: "Kudos to the great organisation team!" They did a Swiss-like precise work and perfectly succeeded in hiding any problems (I assume there were some as always) from the attendees so everything went smooth, nice and shiny for the attendees. The local team was even precise in setting up great weather conditions for DebConf. While saying thanks to the local team I would like to also explicitly thank Luca Capello who has quite some share that this DebConf was possible at all (while I have to decrease my DebConf score one point because he was not really there - Luca to bad that you were not able to come full time!) Also thanks to Gunnar and Gannef who helped remotely (another score down because I were missing them this year as well). Even if it was my favourite DebConf I was not able to work down my todo list fully (which was not only uploading one package per day which I at least statistically fullfilled). But that's probably a general feature of todo lists anyway. One item was definitely done: Doing my daily swimming BoF. I actually was able to do the other parts of the triathlon which was skipped by Christian and have done in summary about 150km cycling with 3500m elevation and estimated 7-8km swimming (0m elevation ;-)). Considering the great view at sunrise over the lake I was not hating my "Senile bed escape" disease too much (I was every day waking up at sunset) - it was simply a great experience. I will never forget seeing water drips glimmering like gold inside the morning sun while seeing the Alps panorama in the distant. I hope I was able to help all interested swimmers with the DebConf Beach Map which was just a by-product of my activities in DebCamp. Speaking about OSM: I was astonished that the area was way less covered than I expected. Thanks to several DebConf attendees the situation became better and the map does not only show random trees in the wild but also the tracks leading to these. (Remark: It was no DebConf attendee who is responsible for plastering the map with single trees.) While I had my mapping focus basically close to the edge of the lake I was also able to even map my very own street. :-) I clearly remember one specific mapping tour when I was invited by the DPL: He convinced me to join him on a bicycle tour and since I was afraid to get fired I joined him instead to keep on hacking. Also Sorina was brave enough to join us on the tour and she did quite well. (Sorina, do you remember the agreement about your work on the installer? ;-)) Lucas described the tour as: going uphill on only asphalted roads. Sorina and me were witnessing the mighty DPL powers when we left the wood around Le Camp to reach the described road: The asphalt was just put onto the road - no doubt that it was done on the immediate demand of mighty DPL. :-) DebCamp time was flying like nose dive and a lot of known (and unknown) faces arrived at Le Camp. What I really liked a lot this year was that several really young children has pulled down the average age of DebConf attendees. I clearly remember all the discussion one year ago what to do about children. As always the issue was solved in a typical Debian way: Just do it and bring your children - they had obviously a great time as well. I think the youngest child was 2 months and the oldest "child" above 20. ;-) Actually Baptiste Perrier did great in making the C&W party a success and had obviously a nice time. (I wished my son would have been able to come as well but he needs to write his bachelor s thesis in physics. :-() It was nice to see the kids using all playing facilities and communicating with geeks. Also I would like to point out that even the very young attendees had their share at the success of DebConf: Just think of the three "bell ringing assistants" who helped me ringing the bells for lunch and dinner. I've got this cool job from Didier in the beginning of DebCamp. I must say having some real bells ringing is by far nicer than just the "lunch / dinner starts in 10 minutes" from IRC bot. The only thing I did not understand was that people did not considered ringing the bells at 8:00 for breakfast as a good idea. Regarding the food in general I would also like to send kudos to the kitchen: It was tasty, freshly prepared, regional food with a good change rate. I really liked this. Extra points for having the chance to sit outside when eating. Talks But lets have a look into the conference programme. I'd really recommend watching the videos of the talks Bits from the DPL (video) and Debian Cosmology (video). I considered both talks as entertaining and interesting. I also really hope that the effort Enrico Zini started in Debian Contributors (video) will be successful. I had some talks and BoFs myself starting with Why running a Blend (video) and I admit that (as usual) the number of attendees was quite low even if I think there is some proof (see below) that it is interesting for way more people who should consider working more "blendish" in their team. Do you know how to recruit one developer per year and relax the man power problem in your team? Feel free to watch the video. We have confirmation that ten DDs of our team have considered to join Debian only because Debian Med exists. Admittedly biology and medicine are really leaf topics inside the Debian universe. So if even this topic that has a very tiny share of the Debian users is able to attract this level of attention - how many more people could we win for multimedia, games, GIS and others? So if you feel you are quite overworked with your packaging and you have no time this is most probably wrong. The amount of time is basically a matter of priorities you set for your tasks. Try to put some higher priority onto using the just existing Blends tools I explained in my talk to attract more users and developers to your team and by doing so spread the workload over more people. It works, the prove was given in my main talk. So before you start working on a specific package you should wonder who else could have an even stronger interest to get this work done and provide him with some additional motivation and help to get the common goal done. The interesting thing is that my BoF about How to attract new developers for your team (video) - which was a simple report about some by-product of the Blends work - made it into the main talk room and got way more attention. For me this is the proof that the Blends concept itself is probably badly perceived as something like "a few outsiders are doing damn specific stuff which is not really interesting for anybody else" instead of what is really is: Smoothing the way from specific upstream applications to the end user via Debian. Once you see the video of this BoF you can observe how my friend Asheesh Laroia became more and more excited about the Blends concept and admitted what I said above: We should have more Blends for different fields. Funnily enough Asheesh asked me in his excitement to talk more about Blends. This would have been a really good suggestion ten years ago. At DebConf 3 in Oslo I had my very first talk about Blends (at this time under the name "Debian Internal Projects"). I continuously kept on talking about this (MiniDebConf Peking 2005, DebConf 5, Helsinki (video), DebConf 7, Edinburgh (video), DebConf 8, Mar del Plata (video), DebConf 9, C ceres (video), MiniDebConf Berlin 2010 (video in German), MiniDebConf Paris 2010 (not video recorded), DebConf 11, Banja Luka (video) ... and these are only (Mini)DebConfs my talks page is full of this topic) and every new year I try different ways to communicate the idea to my fellow Debianistas. I'm wondering how I could invent a title + abstract avoiding the term Blends, put "Git", "release" and "systemd versus upstart" in and being able to inform about Blends reasonably by not becoming to off topic with the abstract. I also registered the Debian Science round table. I admit we were lacking some input from remote via IRC which used to be quite helpful in the past. The attendees agreed upon the handling of citations in debian/upstream files which was invented by Debian Med team to create even stronger bounds to our upstream developers by giving their work extra reward and providing users with even better documentation (see my summary in Wiki). As usual I suggested to create some Debian Science offsprings like "Debian Astronomy", "Debian Electronics", "Debian Mathematics", "Debian Physics" etc. who could perfectly leave the Debian Science umbrella to get a more fine grained structure and a more focused team to enhance the contact to our users. Unfortunately there is nobody who volunteers to take over the lead for such Blends. I have given a short summary about this BoF on the Debian Science mailing list. In the Debian Med meeting I have given some status report. No other long term team members were attending DebConf and so I gave some kind of introduction for newcomers and interested people. I touched also the DebiChem topic which maintains some packages that are used by biologists frequently and so we have a good connection to this team. Finally I had registered three BoFs in Blends I'm actually not (or not yet) active part of. My motivation was to turn the ideas I have explained in my main talk into specific application inside these teams and helping them to implement the Blends framework. In the first BoF about Debian GIS I have shown the usual team metrics graphs to demonstrate, that the one packaging team Pkg-OSM is in danger to become MIA. There are only three persons doing actual uploads. Two of them were at DebConf but did not joined the BoF because they do not consider their contribution to Pkg-OSM as a major part of their general Debian work. I will contact the main contributor David Paleino about his opinion to move the packages step by step into maintenance of Debian GIS packaging team to try to overcome the split of two teams that are sharing a good amount of interest. At least if I might become an Uploader for one of the packages currently maintained by Pkg-OSM I will move this to pkg-grass-devel (which is the name of the packaging team of Debian GIS for historical reasons). The attendees of the BoF have considered this plan as sensible. Moreover I talked about my experiences with OSGeo Live - an Ubuntu derivative that tries to provide a full tool chain to work on GIS and OSM problems ... basically the same goal as Debian GIS has just provided by the OSGeo project. I'm lurking on OSGeo mailing list when I asked explicitly I've got the answer that they are working together with Debian GIS and are using common repository (which is IMHO the optimal way of cooperation). However, it seems that several protagonists of OSGeo Live are underestimating the resources provided by Debian. For instance there was a question about Java packaging issues but people were not aware about the existence of the debian-java mailing list. I was able to give an example how the Debian Med team managed to strengthen its ties to BioLinux that is also an Ubuntu derivative for biologists. At our first Debian Med sprint in 2011 we invited developers from BioLinux and reached a state where they are using the very same VCS on Alioth where we are maintaining our packages. At DebConf I was able to upload two packages where BioLinux developers did certain changes for enhancing the user experience. My "work" was just bumping the version number in changelog and so we did profit from the work of the BioLinux developers as well as they are profiting from our work. I plan to dive a bit more into Debian GIS and try to strengthen the connection to OSGeo Live a bit. The next BoF was the Debian Multimedia meeting. It was nice that the current leader of Ubuntu Studio Kaj Ailomaa joined the meeting. When I was explaining my ideas about cooperation with derivatives I repeated my detailed explanation about the relation with BioLinux. It seems every topic you could cover inside Debian has its related derivative. So to me it seems to be quite natural to work together with the developers of the derivative to join forces. I actually consider a Blend a derivative done the right way = inside Debian. The final work for the derivers that might be left for them is doing some shiny customising of backgrounds or something like this - but all the hard work could and should be done in common with the relevant Debian team. My dream is to raise such relevant teams inside Debian ... the Blends. Finally the last BoF of this series was the Debian Games meeting. As always I presented the team metrics graphs and the Debian Games team members who attended the BoF were quite interested. So it seems to be some unknown fact that team metrics are done for several teams in side Debian and so I repeat the link to it for those who are not yet aware of it. As a result of the BoF Debian Games team members agreed to put some more effort into maintaining their Blends tasks. Moreover Miriam Ruiz wants to put some effort into reviving Debian Jr. Regarding Debian Jr. there was an interesting talk about DouDouLinux - in case you might want to watch the video I'd recommend skipping the first 30min and rather watch the nice live demo. There was also an ad hoc BoF about Debian Jr scheduled to bring together all people interested into this cute project and Per Anderson volunteered to take over the lead. I have given a summary about this specific BoF at the Debian Jr list. For some other talks that I'd regard as remarkable for some reasons: I'd regard the talk "Debian-LAN" by Andreas Mundt as some hidden pearl because it did not got a lot of attention but after having seen the video I was quite impressed - specifically because it is also relevant for the Blends topic. Memories I also liked "Paths into Debian" by Moray Allan (and I was only able to enjoy the latter talks thanks to the great work of the video team!) because it also scratched the same topic I was concerned about in my mentoring talk. Related to this was in my opinion also "Women in Debian 2013" were we tried to find out reasons for the lack of woman compared to other projects and how to overcome this issue. Besides the talks I will probably never forget two specific moments that make DebConf so special. One of these moments is recorded on an image that clearly needs no words - just see Geert hovering over the grass. Another strong moment in my personal record was in the DebConf Newbies BoF "First time at DebConf" that unfortunately was not recorded but at least for this statement it would have been very great if we would have some reference better than personal memory. Aarsh Shah a GSoC student from India suddenly raised up and said: "Four months ago I was not even aware that Free Software exists. Now I'm here with so many people who are totally equal. If I will tell my mother at home that I was standing in the same queue where the Debian Project Leader was queuing up for food she will never believe me." He was totally excited about things we are regarding as normal. IMHO we should memorise moments like this that might be part of the key to success in cultures, where Debian is widely unknown and very rarely in use. Amongst these not scheduled great moments the scheduled day trip was also a great thing. I had a really hard time to decide what tour I might join but ended up in the "long distance walking (or should I say running) group". Inspired by the "running Bubulle" who was flashing between the walking groups we went uphill with 5.4km/h which was a nice exercise. Our destination the large cliff was an exciting landscape and I guess we all enjoyed the dinner organised by the "Trout cabal". ;-) So I had a hard time to leave Le Camp and tried hard to make sure my memories will remain as long as possible. Keeping some signs attached to my bicycle, conserving the "Scenic Hacklab" sign for my private "scenic hacklab @ home" was one part. I also have cut some branches of the Buxus sempervirens in Le Camp and have put them in my garden at home (where I create some hedgerow from places where I spent some great time). These will probably build a great part of the hedgerow ... Thanks for reading this longish report. Looking forward to see you all in Germany 2015 (or earlier) Andreas.

EFI includes support for storing persistent 'variables': it implements a key-value store where keys are (UUID, string) and values are arbitrary blobs. (There are also some flags that restrict when the variables can be accessed.) The physical storage medium is normally flash. The Linux efivars module provides access to variable storage, both through a specific interface in sysfs and through the somewhat abstracted pstore interface. An EFI implementation reads the boot order and (if applicable) Secure Boot configuration from specific EFI variables. An operating system can add arbitrary variables, using its own UUID(s). On Linux, the efibootmgr utility is used to read and write the boot order and the pstore interface is used within the kernel to dump kernel log messages or other information when particular events occur. Since efivars is needed to set the boot order on EFI systems, it's a critical part of installation. But it wasn't being loaded on Debian systems until efibootmgr was run. This doesn't work so well when using a rescue system, as the installation kernel and installed kernel may be different (Debian bug 703363). In future (Debian package version 3.2.41-1) this will be loaded automatically on EFI systems. But now comes a new problem: bugs in the implementation of variable storage can prevent a system from booting, and even worse, they may prevent manual recovery without special equipment (the system is 'bricked'). Matthew Garrett recently talked about this and mentioned that some Samsung laptops are bricked if the variable storage becomes more than 50% full. efivars now has some extra checks to avoid triggering this (both in mainline and in stable branches). This isn't the end of the story, unfortunately. Remember that nothing can be overwritten in flash without erasing a relatively large block, and that writes may fail after a few thousand erase cycles (number depending on the type of flash used). Therefore, deleting a variable usually does not free storage immediately, and overwriting a variable usually reduces the amount of free storage. In the case of the Samsung laptops, unused storage is apparently reclaimed at the next reboot. However, while testing the backported efivars changes I found that my EFI-booting system (Asus P8Z68-V LX motherboard) does not reclaim unused storage until it's very nearly full. Since the firmware itself increments a counter variable on every boot, using 36 more bytes of storage, I was able to observe the available space dropping to under 100 bytes, and then after another boot jumping to about 42K (out of 64K). This means that well over 50% of storage was unused, yet efivars would refuse to write any variables because the firmware didn't reclaim it. This would prevent (re)installation of Linux, as the boot configuration could not be written. On the assumption that both behaviours are common, I've settled on a compromise that I hope minimises overall risk:

• Applied pending changes that allow pstore integration to be disabled at run-time, and made this the default. This means only efibootmgr is likely to write to variables.
• Removed the check that variable writes will not fill storage more than 50%.

But it's essential that we find a way to identify and work safely with both behaviours. Not only do I want to eliminate the possibility of bricking or installaton failure, but I want to make EFI-backed pstore safe to enable. Crash logs are often hard to obtain and pstore can help to solve that problem. Updated 2013-09-15: The free space check has been revised (in Linux 3.2.48, 3.5.7.17, 3.8.13.5, 3.9.7 and 3.10) based on advice from Samsung. The kernel leaves at least 5K (rather than 50%) of the EFI variable store free. If it is about to breach this limit, it attempts to write a dummy variable that is larger than the free space, which will either fail or trigger garbage collection. The normal variable can then be written if garbage collection freed up enough space. This check can be disabled using the kernel parameter efi_no_storage_paranoia, but there should be no need to do so.

I ll be at the Google Summer of Code Mentor s Summit this year - looking forward to meeting with any other Debian-folk (or non-Debianfolk!) who happen to find themselves at the summit. See y all soon!

Two months to the day after the previous 0.3.0 release of RProtoBuf, we are happy to announce a maintenance release 0.3.1 which has now arrived on CRAN. RProtoBuf provides GNU R bindings for the Google Protobuf data encoding library used and released by Google. Once again, Murray lead this release and added a number improvements. The NEWS file entry follows:

Changes in RProtoBuf version 0.3.1 (2013-09-13)

• Added support for setting and getting 64-bit integer types as character strings of decimal integers to work around R's lack of native 64-bit integer types.
• Added better error handling, documentation, and tests to the extensions support (getExtension and setExtension).
• Add support to P for returning extension descriptors.
• Improved error messages to include field names when invalid fields are specified to protocol buffer messages with new, update, etc.
• Improved configure to detect and pass -std=c++0x if it is available to enable long long 64-bit integer support in Rcpp.
• Improved configure in the case when pkg-config is not available or does not know about the google protocol buffer includes.
• Replaced newly deprecated Rcpp macros with a simplified macro functionality to avoid warnings on the latest development version of Rcpp.

CRANberries also provides a diff to the previous release 0.3.0. More information is at the RProtoBuf page which has a draft package vignette, a 'quick' overview vignette and a unit test summary vignette. Questions, comments etc should go to the rprotobuf mailing list off the RProtoBuf page at R-Forge.

If you are upgrading your HP/Compaq 6715b to Debian Jessie, and suddenly Wifi stops working because the PCI device is gone, install the "rfkill" package:

# lspci   tail -2
02:04.1 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 02)
10:00.0 Ethernet controller: Broadcom Corporation NetLink BCM5787M Gigabit Ethernet PCI Express (rev 02)
# rfkill list 1
1: hp-wifi: Wireless LAN
    Soft blocked: yes
    Hard blocked: no
# rfkill unblock wifi
# rfkill list 1
1: hp-wifi: Wireless LAN
    Soft blocked: no
    Hard blocked: no
# lspci   tail -2
10:00.0 Ethernet controller: Broadcom Corporation NetLink BCM5787M Gigabit Ethernet PCI Express (rev 02)
30:00.0 Network controller: Broadcom Corporation BCM4311 802.11a/b/g (rev 02)

Reports on the internet say that the same could be done by going into the BIOS and selecting "Reset to default" - this makes the Wifi LED active until about udev is started on the next boot. To be done: figure out how to automate this.

Indeed, there is much crappy PHP appliaction code out there in the wild. Anyways ... when you have to care about webservers you may have systems which are relying on PHP. Upgrading this systems to the next major PHP version may break projects hosted on those systems, cause there is deprecated code in them which is not supported by the new PHP version. I just hacked together a smallish shell script to spot problematic functions and ini directives of the working directory. Enhancements and missing code fragments are welcome. php54_deprecated_functions.sh

I recently purchased an LG Optimus L3 ( e400 ) mobile phone. I ve to admit it would be a perfectly fine purchase if it wasn t for the huge amount of time I had to invest in order for this thing to recognize me as its master. Even though I wanted to install CyanogenMod in it, the device blocked my attempts to install it through ROM Manager. Yes, for some awkward reason LG kept on thinking they still owned the device even after they sold it to me. Anyway, as none of the rooting instructions for LG Optimus L3 I found on the net worked for me, I figured I should try with the recently-discovered master key vulnerability. A bit of research shows there s very extensive documentation on this hole and how to exploit it, as well as proof-of-concept exploits. But unfortunately, I haven t been able to find any complete solution to implement this in easy steps. On the soulders of giants After running through the whole manual setup of this exploit (and succesfully rooting my LG Optimus L3), I figured it would be useful if I put the pieces together into a unified script. So here it is, an exploit for the Android master key vulnerability which will give you root access to almost every Android device in existance: https://github.com/robertmillan/mkbreak Enjoy. Oh and btw: fuck you LG.

A couple of days ago, the upstream maintainer of autodie, Paul Jamieson Fenwick (PJF), released autodie 2.21. It includes all of the performance improvements I had proposed in Optimizing autodie (plus a few extra ones authored after I wrote the post) and a small fix to one of the tests (due to changes in Carp). As mentioned in my earlier post, these improvements gives about a factor 4 load time improvement in most cases. For the sake of it, I have decided to use Lintian as an example of how good this improvement is. First off, Lintian loads uses autodie in about 75 unique files in the current git master branch.

$ grep -lr 'use autodie' lib/ checks/ collection/ frontend/lintian   wc -l
75

As a simple benchmark, lets consider the following Perl one-liner:

$ /usr/bin/time -f "%es %Us %Ss" perl -Mautodie \
  -e 'print $autodie::VERSION, " => ";' \
  -e 'eval join("\n", map  "package X$_; use autodie;"  (1..74));'

A quick-n-dirty comparison gives:

2.20 => 0.91s 0.90s 0.01s
2.21 => 0.15s 0.15s 0.00s
# NB: the times are "wall, user and sys" in that order, in case you
# are too lazy to read time(1).   

So, 2.21 is now closer to a factor 6 rather than the original factor 4. I have to admit that the timings seem to be very machine dependent as my laptop shows a factor 7 improvement (from ~1.39 to ~0.22s). With at least 370 tests cases running in the Lintian testsuite, I can look forward to a reduction in user time on about 4 minutes.

I have upgraded all of my own computers from Debian 6.0 (squeeze) now. I no longer use it myself at all. Some of my software already doesn't work on squeeze (particularly, yarn, which is part of cmdtest). I do not want to spend my time finding ways to support, say, the python-markdown library version that is in squeeze: I would rather make functional improvements than support ancient software versions. I am hereby ending my support of squeeze in my own software. This means I will be removing squeeze from my apt repository on code.liw.fi, and will no longer test that my software works in squeeze, and will not be making packages for squeeze. (I am removing squeeze from the apt repository so that people don't wrongly assume it is being kept up to date.) This change affects users of Obnam. Obnam was not part of the squeeze release of Debian, but I have maintained packages of it for squeeze on code.liw.fi. If any of my software that is packaged in squeeze has security bugs, or bugs that would be considered release-critical by Debian, I will fix those, but only by making the minimal necessary change to the version in squeeze rather than backporting the current version. Debian is committed to support squeeze for several more months, and I will help Debian do that for my packages.

I recently mentioned that there wasn't any built-in node.js functionality to perform IP matching against CIDR ranges. This surprised me, given that lots of other functionality is available by default. As a learning experience I've hacked a simple cidr-matching module, and published it as an NPM module. I've written a few other javascript "libraries", but this is the first time I've published a module. Happy times. The NPM documentation was pretty easy to follow:

• Write a package.json file.
• Run "npm publish".
• Wait for time to pass, and Thorin to sit down and sing about gold.

Now I can take a rest, and stop talking about blog-spam.

Yesterday, I pushed my first sizable contribution to GHC, the Haskell compiler. The feature solves the problem that newtypes are not always free: If we have newtype Age = MkAge Int, then we have all learned that the Age function has zero run-time cost. But if the Int that we want to convert is inside another type, the conversion is no longer free: Converting a Maybe Int to a Maybe Age using, for example, fmap Age, will cause time and space overhead at runtime, and there was no way around it. Well, there is unsafeCoerce, but really, that ought to be avoided. So after some discussion with and encouragement of Simon Peyton Jones at RDP in Eindhoven this year I worked on a design (which was developed, as far as I know, by Simon, Roman Cheplyaka, Stephanie Weirich, Richard Eisenberg and me). In GHC 7.8, there will be a function coerce :: Coercible a b => a -> b that works, from the user point of view, like unsafeCoerce (i.e. no run-time cost), but with the big difference that it will only typecheck if the compiler can infer that it indeed is safe to coerce between a and b. So it will derive Coercible Age Int, and Coercible Int Age, and Coercible (Maybe Age) (Maybe Int) and even stuff like Coercible (Int -> Age) (Age -> Int), but not Coercible Int Bool. It will also not coerce between Age and Int if the constructor MkAge is not exported, to respect module boundaries. Under the hood this relies on the also new feature of roles, which were solved to make the previously unsafe GeneralizedNewtypeDeriving feature safe again, and which also guarantee that coerce is indeed as safe as the name suggests. The feature will come with 7.8, but not fully advertised , so things might change again for 7.10, and bugs with the feature may not necessarily qualify to be fixed in further 7.8.x releases, so beware. It also does not automatically convert fmap Age into coerce, but it is a step in that direction.

Portslave is a project that was started in the 90 s to listen to a serial port and launch a PPP or SLIP session after a user has been authenticated, I describe it as a project not a program because a large part of it s operation is via a shared object that hooks into pppd, so if you connect to a Portslave terminal server and just start sending PPP data then the pppd will be launched and use the Portslave shared object for authentication. This dual mode of operation makes it a little tricky to develop and maintain, every significant update to pppd requires that Portslave be recompiled at the minimum, and sometimes code changes in Portslave have been required to match changes in pppd. CHAP authentication was broken in a pppd update in 2004 and I never fixed it, as an aside the last significant code change I made was to disable CHAP support, so I haven t been actively working on it for 9 years. I took over the Portslave project in 2000, at the time there were three separate forks of the project with different version numbering schemes. I used the release date as the only version number for my Portslave releases so that it would be easy for users to determine which version was the latest. Getting the latest version was very important given the ties to pppd. When I started maintaining Portslave I had a couple of clients that maintained banks of modems for ISP service and for their staff to connect to the Internet. Also multi-port serial devices were quite common and modems where the standard way of connecting to the Internet. Since that time all my clients have ceased running modems. Most people connect to the Internet via ADSL or Cable, and when people travel they use 3G net access via their phone which is usually cheaper, faster, and more convenient than using a modem. The last code changes I made to Portslave were in 2010, since then I ve made one upload to Debian for the sole purpose of compiling against a new version of pppd. I have no real interest in maintaining Portslave, it s no longer a fun project for me, I don t have enough spare time for such things, and no-one is paying me to work on it. Currently Portslave has two Debian bugs, one is from a CMU project to scan programs for crashes that might indicate security flaws, it seems that Portslave crashes if standard input isn t a terminal device [1]. That one shouldn t be difficult to solve. The other Debian bug is due to Portslave being compiled against an obsolete RADIUS client library [2]. It also shouldn t be that difficult to fix, when I made it use libradius1 that wasn t a difficult task and it should be even easier to convert from one RADIUS library to another. But the question is whether it s worth bothering. Is anyone using Portslave? Is anyone prepared to maintain it in Debian? Should I just file a bug report requesting that Portslave be removed from Debian?

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

The first time I found this cute game, was around 2009, but for a bunch of reasons I haven t been able to get it into the archive until now. Pink Pony is a cute game in which you have to control a pink pony who s main goal is to last in the game more time than the other ponies. You might remember the game Tron, or the film, in which there were light cycles who left a trace behind, with which the other cycles crashed. Well, this is the similar game concept, only with cute ponies instead of light cycles. You can see a video of the game in action, if you want to get a feeling of how it is. Thomas Weber (Ginko), has published a newer version of the game (1.3.1) a couple of days ago, and that is the one that has entered Debian repositories (sid) today. Thanks, Ginko, for this lovely game! Even though the game might not seem too appealing for some of the adult users of Debian or Ubuntu, maybe some of their kids will like it as much as I do. The game is quite quick, though, so very young kids might have trouble controlling the pony. I would suspect it might be all right for kids above 9 years old, but I haven t been able to test my hypothesis, so if you find out, please tell me

... at least until the cgroup interface is fixed. So, what can it do?

• There is tasks and cgroup.procs. There are no thread IDs on Hurd, so cgroupfs works only on a per-process basis, not per-threads. Consequently tasks has the same semantic as cgroup.procs. Seeing that PIDs and TIDs can be used (mostly) interchangeably on Linux I think this is okay to do.
• You can create and destroy cgroups, child processes are properly tracked.
• You can register an release_agent and it is executed whenever the last process in a cgroup dies.
• There is notify_on_release to enable or disable the use of release_agent.
• There is cgroup.clone_children, one can toggle this bit but it is ignored.

So, what's missing?

• There are no controllers. I haven't looked into this and resource accounting is one of Hurds weakest points, but it is fathomable that one could e.g. advise the scheduler inside the Mach kernel based upon the state of the cgroups if the cgroupfs process is sufficiently privileged (did I mention that any user can use cgroupfs?).
• The notification API aka cgroup.event_control. The Hurd lacks eventfd(2), but even if that was implemented, this interface would still be impossible to implement. Rant below.
• A patch for gnumach to make this bulletproof. I made some encouraging progress with that one this week, but there's nothing presentable yet.

So, what's wrong with Linux cgroup API? Well for one thing the whole API is underspecified. Yes, there is Documentation/cgroups/cgroups.txt, but that is not a specification, that's a howto at best. Second, the notification API is not particularly nice:

To register a new notification handler you need to:
 - create a file descriptor for event notification using eventfd(2);
 - open a control file to be monitored (e.g. memory.usage_in_bytes);
 - write "<event_fd> <control_fd> <args>" to cgroup.event_control.
   Interpretation of args is defined by control file implementation;

Seriously? There is a POSIXly way to pass file-descriptors around, but smashing the decimal representation of it into a string is not the way to do that. Linux gets away with this hack because the kernel knows the process who wrote(2) that string in the first place, parse the string into an integer and look it up in the table of file descriptors for that process. Now the trouble for cgroupfs is, that it is not the kernel and even if it were, it wouldn't solve the problem because on Hurd there are no file descriptors (well there are, but that's only to appease all the POSIX programs out there). Instead Hurd has ports, and you can send messages to ports, and this is pretty much everything that you can do on a Mach system. Reading a file works roughly like this:

1. You open a file and get a port X.
2. You send a message like "I'm like really interested in the first Y bytes of that file" to X.
3. Whoever has the receiving end of X (probably the one who gave you X in the first place) answers your request.

Ports look pretty much like file descriptors, they are (usually small) integers, you can make them, destroy them, pass them around easily (yes, ports are first class objects in the Mach messaging system). Everything is implemented atop of this mechanism. It is transport-agnostic, the other end could be on another machine and you wouldn't even know. You can create proxies or filters (in fact, that is exactly how the firewall eth-filter is implemented). It's beautiful and extensible at it's heart, like Lego bricks. So if X were a port to e.g. memory.usage_in_bytes and the cgroups interface would be less braindead^W^Wmore carefully designed so that on Hurd it could be transported like ports usually are, then cgroupfs could in fact use port X' to look up which file the caller is interested in (this is possible because cgroupfs was the one handing out the port in the first place) and generate notifications for that file. This is not possible when X is "serialized for transport" using sprintf because port names are specific for each process, so X != X'. The kernel would do the translation while sending the message, but it obviously cannot do that if the number is carried in a character array. I'm not sure what I'm going to do next week. The gsoc timeline suggests a soft-pencils-down, time to scrub code and write documentation, not sure that this is applicable to me as I have pushed most of my work upstream as early as possible. I guess I will nag Samuel so that he merges the outstanding patches and continue working on my gnumach patch.

So I have upgraded my main workstation at last, but there are a few things I wanted to figure out. Some of these I found an answer to, but others I haven t and some answers open more questions: Where did debian-menu.menu go and why doesn t lxlauncher have the Debian menu by default anyway? Answer: It seems this is a combination of debian bug 333848 and bug 722563 which I reported yesterday in that lxlauncher doesn t use the debian menus. Workaround for now: install menu-xdg and hack the lxlauncher menu file. Why don t my xterm shells load .profile any more? Did I bodge that before without making a note? How do I stop kernel or initrd or whatever it is configuring the network with the dhcp settings at boot time instead of the better wicd ones that are available once the system is up? Continuing with networking, how did network-manager (which doesn t cope with my network configuration) get installed again? Answer: debian bug 645656 explains that debian is simply following a silly decision taken upstream and refers to attempts to make network-manager optional as the Crusade . Workaround: remove gnome and install its dependencies like gnome-core directly instead. Drawback: any new dependencies of gnome will have to be installed manually. Why is the audio capture volume at 10% by default and what s the best way to change that? I suspect this might be 682731 but that bug is untouched in over a year. I m tempted to remove pulseaudio, but gnome-core Depends pulseaudio so this is yet more hardware-breaking caused by gnome dependency changes and the only way out of this one would be to remove gnome-core and install its dependencies. Or maybe I should just give up and finally remove gnome because its packages have jumped the shark. I installed gnome to make the system easier to use and it s broken it in at least two ways now. One question that makes me hesitate is: why is gdm3 faster to start than lightdm?

One of the very long-standing problems with AFS is that it doesn't have a stable library interface or API. The situation with shared libraries is even worse. Despite that, there is a native XS AFS Perl module that tries to provide a native Perl interface to the various AFS libraries, despite all of their quirks. We've used that off and on for various things over the years. Unfortunately, the historic AFS code used an LWP (lightweight threading) implementation that relied on hairy C internals, and when Perl switched over to being threaded with POSIX pthreads by default, the loadable module started having trouble. Various people managed to keep it limping along through Debian's squeeze release, but as of wheezy it just no longer worked; the thread mismatches and the mismatches between the various AFS libraries were too severe. There's work in progress to fix this by building yet another profile of the AFS libraries, with all their warts, but in the meantime we needed access to the AFS PAG functions for various backend scripts. Everything else the Perl module did could be replaced by running the regular commands and parsing their output, but setpag has to be called in the process that should be affected to work safely. Hence this module. AFS::PAG provides a native Perl interface to the API exposed by libkafs and libkopenafs for PAG manipulation: hasafs, haspag, setpag, and unlog. (Eventually it might provide access to pioctl, but I haven't done that work yet.) It supports any platform that has a libkafs or libkopenafs, or Linux without either (by implementing the pioctl interface itself). You can get the latest version from the AFS::PAG distribution page.

I signed up to take part of an online, massive course Arte y cultura en circulaci n: crear y compartir en tiempos digitales (The circulation of arts and culture: Creating and sharing in digital times). As the activities of us the attendees are to be published by each on their personal blog/space, I will be publishing them here. I hope they are interesting to some of my other regular readers. I am late in joining, and I should already be posting the second activity. Anyway, this text goes towards the first week's lesson: Qu es un autor: la (de)construcci n hist rica del concepto de autor a (What is an author? Historic (de)construction of the concept of authorship). Our homework is to find an example of a current discussion where the notion of authorship is discussed, and share it this way. And I'm somewhat in a hurry right now, so this will be hasty. But I didn't want to delay my (late) submission anymore! In the Debian Ruby mailing list, Hleb Valoshka asks basically how deep should copyright recognition be. Because, yes, while copyright attribution is simple (simpler, at least) in literary / artistic works, computer programs (and even more those developed following the Free Software distributed fashion) are harder to properly attribute. Is a two-line patch to a tens-of-thousands-of-lines project enough to warrant mention in the copyright file? Most of us would agree it is not. Few would contend this were the amount of changes to make up, say, even 1% of that scale of project. In the coding projects where I am the main author (which, yes, are usually very small I cannot recognize myself as a good programmer, and the size of my successful works proves me), I try to take care to mention explicitly each of the contributors, even if their contribution is quite small. But were I to lead a larger development work, with enough following to generate on the order of one submitted patch a day, would it make sense for me to follow up with such detail the authorship information? And as a minor side note: How much does the law require me? A very small patch can fix important functionality issues (think security or performance). If somebody sends a very small patch fixing an intellectually hard to grasp problem... I am sure it should be properly acknowledged! Anyway, I have to flee now. I am just dropping some ideas on the table. Of course, if anybody is willing to discuss them further, I'm interested in any debate that springs off it! (Meanwhile... I expect to spam you with this topic a couple of times. But it should not bug you much, as it's one of my usual blog topics!)