A release candidate for v1.0.0 of transloadit-api is out. You can install it via npm and give it a try.

npm install transloadit-api@1.0.0-rc1

Now it supports the full transloadit API, together with signature's creation, assemblies, notifications and templates management. The source is on github, the docs are in this website as well as in the comments in the code (which is the source for the website) and of course, any issue just report it on the github's tracker. It has a lot of tests but there are some tests missing, specially for operations that require internet. Hopefully I will have time to write them this week and then release a proper v1.0.0.

Did I get your attention with the title? Good. In this post I will outline something that I have been thinking about for some months:

I believe it is possible to build a system with the simplicity and functionality of WhatsApp or Viber, which provides end-to-end encryption, is built on free software and open protocols, that supports federation and is almost decentralised, and that would allow interested companies to turn a profit without compromising any of these principles.

Introduction This is the first post of a series that I will be publishing in the next few days. Many parts of these posts will be technical, but I expect that the main concepts can be understood by a wider audience. What I am proposing seems like a bold statement, I know. Maybe there is some fatal flaw somewhere in my thinking, and that is why I am publishing this: I hope to get constructive feedback, and maybe get enough traction to start implementing it Real Soon Now . I have been thinking about this problem since February, when I discussed this extensively with friends at FOSDEM. I have already published a critique of Telegram, which had way more impact than I ever imagined, showing that there is people out there interested in this kind of stuff. The last posts about DNSSEC and DANE were part of my musings about this, too. There are many components that need to be built for this to happen. But more importantly, this can only be useful if it gains a critical mass. And that's why I think making this a viable business tool is very important. At the same time, that means I need to think extra carefully to make it impossible for any for-profit company to mutate this effort into Just Another Walled Garden. My goals for this architecture are:

• First and foremost, target the same people that nowadays is using a plethora of walled gardens for their instant communication needs. That is WhatsApp, Viber, Skype, Facebook messenger, etc.
• It must focus on mobile, that is what people care about, without forgetting about other use cases.
• Creating an account and placing the first call/text message should be as easy as it is currently with the competition.
• All communication must be encrypted end-to-end with public-key cryptography; nobody but the user has access to the private keys.
• Most components must be decentralised, and allow for competition.
• There should be as little trust as possible placed on any part of the system.
• Anybody can set up a compatible service provider and offer it to its users, while having full interoperability with other providers.
• Compatible services which are not part of the network must be able to interoperate.
• Contacting a person should happen even if they are not subscribed to the service. The client application must fall-back seamlessly to using interoperability gateways, PSTN termination, or the mobile network.
• Interoperability with the competition is desirable, but possibly is better left to be implemented by the client applications.

Components I have identified a few components needed for this to work, I will expand on each one later.

1. A flagship mobile application for Android and iOS, based on Lumicall or CSIPSimple, but with several important modifications.
2. One or many directory and authentication services, based on ENUM and DNSSEC. These are the most critical piece of this idea, and possibly must only be operated by community-governed non-profits.
3. One or many service providers, that offer simple account creation, registration, and optionally PSTN termination (which can be the main way of generating profit). An API needs to be defined for operations that are not part of the communications protocol, like account creation, credit purchasing, and balance querying.
4. A network governing charter, and a trusted non-profit organisation that oversees that any participating parties are following the charter. This organisation defines which directory services are to be trusted (and possibly operates one of them), and which service providers the client application can use to create accounts.

Key points Some of the issues that need to be solved are:

• How to handle and distribute public keys securely without the user understanding anything about security.
• How to make registration painless and password-free, while offering an acceptable level of security.
• How to fund development of the client application, and maintenance of the directory services.
• How to get companies interested in this, so them would bring users to the network.
• How to allow the user to migrate from one service provider to another, to improve competition.
• How to prevent any party from subverting the spirit of the network.
• How to make the client application work everywhere and have reasonably quality.

To be continued I think I have answers to most of these problems. I will elaborate in the next few days, stay tuned!

Footnotes The name is something I've chosen a name in less than 2 minutes, while starting this post, so probably is awful. The distributed part is only half true, as the directory services need to be centralised, but I think it's good enough. I am aware that Lumicall seems to be trying to build something similar. I only found about that recently, when I was thinking about this design. Sadly, I think it has several shortcomings, but it is definitely one of the building blocks of this project.

I have just tagged Obnam (my backup program) 1.8 in git, and built and uploaded Debian packages to code.liw.fi and Debian unstable. NEWS snippet below. Version 1.8, released 2014-05-13

• The error message has been improved for when setting metadata (owner, permission, and similar) of a restored file fails.
• obnam force-lock now works even when the client running it is not in the client list.

Security issues:

• Joey Hess found a problem in obnam restore: restored files would be created with quite liberal default permissions, which would be set to the backed-up permissions later. This could allow a snooper to read files they shouldn't be. This has been fixed now by using restrictive default permissions. A workaround for older versions is to create a directory, set its permissions to 0700, and restore to a subdirectory of that directory.

Bug fixes:

• --help output no longer shows the default value of any options. It was shown only for a few options anyway. The proper way to see the current settings is with the --dump-config option. The bug that was fixed that the generated manual page no longer contains values that are specific to the machine doing the generation, such as the hostname as the default value for --client-name. Reported by SanskritFritz.
• When a file was backed up, and later excluded with --exclude, Obnam wouldn't remove it from the new backups. Now it does. Bug fixed by Anssi Hannula, though his patch got changed because it no longer applied.
• When restoring extended attributes not in the user namespace (named like user.foo) Obnam now ignores them, instead of trying to set them and crashing.
• When restoring from a directory that is not a repository, the error message is now clearer.
• Obnam would previously allow the backup root to be a symbolic link pointing at a directory. However, this only worked for backups. No other operations would work and would only see the symbolic link, not the directory it pointed at. Obnam now gives an error message even for the backup.
• Obnam no longer excludes files named syslog or none, if the setting --log=none or --log=syslog is used.

Endlich tut mal jemand was gegen die rechte Hetzpartei! Ein Arbeitskollege fragt, ob man die nicht einfach mit einem langen Heckenschneider abmachen kann aber sie so l cherlich zu machen hat auch was

Finally, someone is doing something against this Nazi party! A coworker wondered whether it s legal to cut them off with a long tool, but making them ridiculous like this is also funny

(Explanation: the Pro NRW people put their campaign thingies (sorry, I don t speak English well) up on lamp posts very high, because they are taken down by other citizens immediately otherwise, so there s now people making fun of them for using long ladders (to put them up there, so the offended citizens need equally long ladders or tools with long arms) in leaning on the saying that lies have long legs here: ladders.)

Recently I've been seeing lot of posts about DNSSEC on Internet and I thought I should configure my domain to be secured by DNSSEC. copyninja.info domain is now secured with DNSSEC you can verify this by DNSSEC analyzer by Verisign and DNSViz online tool or by installing DNSSEC validator addon for your browser. There are good amount of tutorials and guides available to enable DNSSEC for your domain, still I want to note down steps I followed to here for the record (of course it will be helpful for me if I forget it ;-)) First step will be installing bind9 and dnssec-tools package, if you use aptitude installing dnssec-tools will pull down the bind9 unless you have configured aptitude to not install the Recommends. Next setting up the zone file for your domain, for this first make a copy of /etc/bind/db.local as /etc/bind/db.example.com, replace example.com with your domain name. Now you need to add your zone records to the zone file. Next edit the /etc/bind/named.conf.local file and add following lines

zone "example.com"  
    type master;
    file "/etc/bind/db.copyninja.info";
    allow-transfer  secondary; ;
 ;

Here replace secondary with your secondary DNS servers, if you don't have one you can ommit this but its always recommended to have secondary DNS servers for a zone, in cases when primary fails. After this we need to enable DNSSEC on bind, this is done by editing the file /etc/bind/named.conf.options. Add following lines into options section.

dnssec-validation yes;
dnssec-enable yes;
dnssec-lookaside auto;

A more explanation on this can be found on Linux Journal article. Now its time to create DNSSEC keys and sign your zone, more about different DNSSEC keys and records can be found in the Linux Journal Article on implementation. I used zonesigner utility from dnssec-tools which does job of signing and including KSK and ZSK keys into bind configuration which otherwise should be done manually. Here is the command line I used for generating keys, thanks to Jonas for this.

mkdir -p /etc/bind/keys
zonesigner -algorithm RSASHA256 -keydirectory /etc/bind/keys\
       -dsdir /etc/bind/keys -archivedir /etc/bind/keys/archive \
       /etc/bind/db.example.com

Here we store our keys into /etc/bind/keys directory, and use RSASHA256 algorithm for key generation which is more stronger than the default used RSASHA1 (atleast thats what Jonas told me). This will create ZSK and KSK for the signing zone and creates a signed zone file db.example.com.signed in same directory as original zone file. Now all you need to do is replace the zone file from db.example.com to db.example.com.signed in file directive with your named.conf.local file.

Note that this keys expire after 30 days so you need to resign your zone before 30 days. For resigning just run zonesigner from /etc/bind/keys. You can setup cron job to do this periodically.

zonesigner -zone example.com /path/to/db.example.com

Our signed zone is ready but we are not done yet! For DNSSEC to work others should trust your signed record for this you need to register your public keys with registrar for your domain and this can be done via your domain provider (in my case this is Gandi). You need to check your domain name providers documentation on how to do this. For Gandi users there is a nice documentation.

So I was needing a resulting JSON array with possible solutions for a given address or city name and then angular-geocomplete was made. The great thing is that you can use it together with typeahead and now you have address/location autocomplete, just like the one on Google Maps. And yes, it does uses Google Maps's API. What's the advantage of this thing? You get coordinates together with all the names. Installable via bower as well with bower install angular-geocomplete. Any issue: to the GitHub tracker.

This is an updated version of an earlier post in March. A number of talks about Rcpp are scheduled over the next couple of months:

• On Wednesday May 14 I will be speaking at the Chicago R Users Group meeting charmingly titled Warm Up for R/Finance, along with fellow R/Finance organizer Josh Ulrich, fellow R/Finance regular Kent Hosxey as well as Cliff Clive. I will talk about Redis and my rather recent nascent RcppRedis package.
• Our sixth international conference R/Finance will take place May 16 and 17, 2014, at UIC in Chicago. See the current agenda for details of the program---which once again will be preceded by one-hour workshops. And as in the past, I will offer a one-hour gentle introduction to Rcpp. This workshop requires registration and a fee, and registraion will close shortly. I will also present a short lightning talk about the RcppRedis package as part of the conference proper.
• A few days later, on May 20, 2014, I will present a one-hour webinar which is part of a series organized by Ray DiGiacomo and the Orange County R Users Group. See this page for details and registration information; the talk itself will be free of charge.
• Later in the month, on May 30, 2014, I will give a talk / guest lecture about Rcpp and RcppArmadillo and over in Economics at the University of Chicago. I reckon that this event is not open to anybody not part of U of C.
• Another three-hour tutorial is scheduled for the tutorial day preceding useR! 2014 at UCLA in early July. This tutorial will also require registration as part of the annual useR! conference. I am very honoured to have been asked to give one of the invited keynotes at useR! 2014. The talk may (or may not) cover at least some aspects of Rcpp. As my talk proposal about the recent RcppZiggurat package for faster Normal RNGs was accepted, I will also give a regular conference talk.

So the month of June remains pretty open. If someone wants me to talk somewhere else, preferably on a Saturday, feel free to get in touch.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

Oracle has demonstrated that implementing an API is effectively the same as copying code from a program. To me, as a non-lawyer programmer, this surprising court decision seems to mutate copyrights into a kind of Software-Patent-Lite(tm) without the benefit of examiners or a 15 year term limit. This seems like a chilling new tool for deep pockets companies like Oracle to go about tormenting people. Thinking more deeply, however, you begin to wonder if Oracle hasn t inadvertently created some kind of Free Software Doomsday weapon. After all, if simply implementing an API makes you code a derivative work then doesn t that mean the terms of the GPL will apply on any code that implements the API of a GPL d system? Even if you didn t copy code you have implemented that API and according to Oracle that s a derived work. If you ask me, its the most excitingly vauge and contagious information phenomena since the Open Data Base License.

The aaddition of lambdas in C++11 has greatly improved the flexibility of the language as a whole. C++14 will add a few more abilities. C++ Truths has a very nice and brief overview of what C++14 will allow. Part 1 goes from the very basics via closures to a small demonstration of partial function application. And Part 2 continues by showing recursive lambdas, overloaded lambdas, pattern matching, in-place parameter pack expansion (neat) and finally even memoisation. These code examples have been the most inspiring ones I have seen lately. If you have any interest in C++, go read them.

I had a really productive day today actually working on Debian, as planned for my Mondays. I'm still working through my list of packages, trying to get them all vaguely up to date for jessie. It's mostly just addressing Lintian issues that mostly revolve around old standards versions, with the occasional new upstream release. I've also been doing bug triage where the bugs aren't overwhelming. Today I made uploads for pssh (a new upstream release), pymetrics (mostly just a rebuild), rcs-blame (mostly just a rebuild) and simpleproxy (mostly just a rebuild). I need to revisit simpleproxy, because I'm having problems convincing the resulting binary to be linked correctly for relro. It's weird, because I'm doing everything I'm supposed to be doing and I can see all the other hardening flags being passed in except for this one. I really like simplifying down debian/rules using dh, that really makes things readable. You can see the useful stuff without losing it in all the boilerplate. For some reason I was never a fan of CDBS, but I'm quite liking dh. I think it's because it's less opaque than CDBS.

For some years LVM (the Linux Logical Volume Manager) has been used in most Linux systems. LVM allows one or more storage devices (either disks, partitions, or RAID sets) to be assigned to a Volume Group (VG) some of which can then allocated to a Logical Volume (LVs) which are equivalent to any other block device, a VG can have many LVs. One of the significant features of LVM is that you can create snapshots of a LV. One common use is to have multiple snapshots of a LV for online backups and another is to make a snapshot of a filesystem before making a backup to external storage, the snapshot is unchanging so there s no problem of inconsistencies due to backing up a changing data set. When you create a snapshot it will have the same filesystem label and UUID so you should always mount a LVM device by it s name (which will be /dev/$VGNAME/$LVNAME). One of the problems with the ReiserFS filesystem was that there was no way to know whether a block of storage was a data block, a metadata block, or unused. A reiserfsck --rebuild-tree would find any blocks that appeared to be metadata and treat them as such, deleted files would reappear and file contents which matched metadata (such as a file containing an image of a ReiserFS filesystem) would be treated as metadata. One of the impacts of this was that a hostile user could create a file which would create a SUID root program if the sysadmin ran a --rebuild-tree operation. BTRFS solves the problem of filesystem images by using a filesystem specific UUID in every metadata block. One impact of this is that if you want to duplicate a BTRFS filesystem image and use both copies on the same system you need to regenerate all the checksums of metadata blocks with the new UUID. The way BTRFS works is that filesystems are identified by UUID so having multiple block devices with the same UUID causes the kernel to get confused. Making an LVM snapshot really isn t a good idea in this situation. It s possible to change BTRFS kernel code to avoid some of the problems of duplicate block devices and it s most likely that something will be done about it in future. But it still seems like a bad idea to use LVM with BTRFS. The most common use of LVM is to divide the storage of a single disk or RAID array for the use of multiple filesystems. Each filesystem can be enlarged (through extending the LV and making the filesystem use the space) and snapshots can be taken. With BTRFS you can use subvolumes for the snapshots and the best use of BTRFS (IMHO) is to give it all the storage that s available so there is no need to enlarge a filesystem in typical use. BTRFS supports quotas on subvolumes which aren t really usable yet but in the future will remove the need to create multiple filesystems to control disk space use. An important but less common use of LVM is to migrate a live filesystem to a new disk or RAID array, but this can be done by BTRFS too by adding a new partition or disk to a filesystem and then removing the old one. It doesn t seem that LVM offers any benefits when you use BTRFS. When I first experimented with BTRFS I used LVM but I didn t find any benefit in using LVM and it was only a matter of luck that I didn t use a snapshot and break things. Snapshots of BTRFS Filesystems One reason for creating a snapshot of a filesystem (as opposed to a snapshot of a subvolume) is for making backups of virtual machines without support from inside the virtual machine (EG running an old RHEL5 virtual machine that doesn t have the BTRFS utilities). Another is for running training on virtual servers where you want to create one copy of the filesystem for each student. To solve both these problems I am currently using files in a BTRFS subvolume. The BTRFS kernel code won t touch those files unless I create a loop device so I can only create a loop device for one file at a time. One tip for doing this, don t use names such as /xenstore/vm1 for the files containing filesystem images, use names such as /xenstore/vm1-root. If you try to create a virtual machine named vm1 then Xen will look for a file named vm1 in the current directory before looking in /etc/xen and tries to use a filesystem image as a Xen configuration file. It would be nice if there was a path for Xen configuration files that either didn t include the current directory or included it at the end of the list. Including the current directory in the path is a DOS mistake that should have gone away a long time ago. Psychology and Block Devices ZFS has a similar design to BTRFS in many ways and has some similar issues. But one benefit for ZFS is that it manages block devices in a zpool , first you create a zpool with the block devices and after that you can create ZFS filesystems or ZVOL block devices. I think that most sysadmins would regard a zpool as something similar to LVM (which may or may not be correct depending on how you look at it) and immediately rule out the possibility of running a zpool on LVM. BTRFS looks like a regular Unix filesystem in many ways, you can have a single block device that you mount with the usual mount command. The fact that BTRFS can support multiple block devices in a RAID configuration isn t so obvious and the fact that it implements equivalents to most LVM functionality probably isn t known to most people when they start using it. The most obvious way to start using BTRFS is to use it just like an Ext3/4 filesystem on an LV, and to use LVM snapshots to backup data, this is made even more likely by the fact that there is a program to convert a ext2/3/4 filesystem to BTRFS. This seems likely to cause data loss.

Republished by Slate. Translations available in French (Fran ais), Spanish (Espa ol), Chinese ( ) For almost 15 years, I have run my own email server which I use for all of my non-work correspondence. I do so to keep autonomy, control, and privacy over my email and so that no big company has copies of all of my personal email. A few years ago, I was surprised to find out that my friend Peter Eckersley a very privacy conscious person who is Technology Projects Director at the EFF used Gmail. I asked him why he would willingly give Google copies of all his email. Peter pointed out that if all of your friends use Gmail, Google has your email anyway. Any time I email somebody who uses Gmail and anytime they email me Google has that email. Since our conversation, I have often wondered just how much of my email Google really has. This weekend, I wrote a small program to go through all the email I have kept in my personal inbox since April 2004 (when Gmail was started) to find out. One challenge with answering the question is that many people, like Peter, use Gmail to read, compose, and send email but they configure Gmail to send email from a non-gmail.com From address. To catch these, my program looks through each message s headers that record which computers handled the message on its way to my server and to pick out messages that have traveled through google.com, gmail.com, or googlemail.com. Although I usually filter them, my personal mailbox contains emails sent through a number of mailing lists. Since these mailing lists often hide the true provenance of a message, I exclude all messages that are marked as coming from lists using the (usually invisible) Precedence header. The following graph shows the numbers of emails in my personal inbox each week in red and the subset from Google in blue. Because the number of emails I receive week-to-week tends to vary quite a bit, I ve included a LOESS smoother which shows a moving average over several weeks. From eyeballing the graph, the answer to seems to be that, although it varies, about a third of the email in my inbox comes from Google! Keep in mind that this is all of my personal email and includes automatic and computer generated mail from banks and retailers, etc. Although it is true that Google doesn t have these messages, it suggests that the proportion of my truly personal email that comes via Google is probably much higher. I would also like to know how much of the email I send goes to Google. I can do this by looking at emails in my inbox that I have replied to. This works if I am willing to assume that if I reply to an email sent from Google, it ends up back at Google. In some ways, doing this addresses the problem with the emails from retailers and banks since I am very unlikely to reply to those emails. In this sense, it also reflects a measure of more truly personal email. I ve broken down the proportions of emails I received that come from Google in the graph below for all email (top) and for emails I have replied to (bottom). In the graphs, the size of the dots represents the total number of emails counted to make that proportion. Once again, I ve included the LOESS moving average. The answer is surprisingly large. Despite the fact that I spend hundreds of dollars a year and hours of work to host my own email server, Google has about half of my personal email! Last year, Google delivered 57% of the emails in my inbox that I replied to. They have delivered more than a third of all the email I ve replied to every year since 2006 and more than half since 2010. On the upside, there is some indication that the proportion is going down. So far this year, only 51% of the emails I ve replied to arrived from Google. The numbers are higher than I imagined and reflect somewhat depressing news. They show how it s complicated to think about privacy and autonomy for communication between parties. I m not sure what to do except encourage others to consider, in the wake of the Snowden revelations and everything else, whether you really want Google to have all your email. And half of mine. If you want to run the analysis on your own, you re welcome to the Python and R code I used to produce the numbers and graphs.

Hello, World! I ve deployed my first instance of lenin to my backup VCS (lucifer.pault.ag), and it s going great. (Screenshot of the first few instances for good measure) I m excited to see how it develops!

Recently I was wearing my Free Hugs shirt to different Free Software meetings, and I came up with the idea if we are advocating the Free in Software specificly, why not come up with Free Hugging Guidelines, too. So here they are, from now on considered to be named the RFHG.

1. Free Redistribution Your hugs may not restrict any party from passing on the hugs they received from you.
2. Source Code The hugs must be possible to be perceived and understandable in complete. You are not allowed to use any special techniques that can not be perceived.
3. Derived Works Your hugs must be allowed to be modified, and must allow the modified forms of your hugs to be distributed under the same terms as they received them.
4. Integrity of The Author's Source Code While you are allowed to pass on the hugs in modified form, you are not allowed to modify the DNA of the original person you received the hugs from. Genetic modification is out of the scope of the RFHG.
5. No Discrimination Against Persons or Groups While we acknowledge that you might not feel willing to hug everyone, you must apply rules that do not distinquish by rules which would violate The Universal Declaration of Human Rights. Furthermore, you have the right to not hug a person if you are not in the mood for it. Please refrain from wearing any Free Hugs markers at those times though.
6. No Discrimination Against Fields of Endeavor The hugs can not be restricted to be used in a specific field of endeavor. For example, you may not restrict the hugs from being passed on only in times of sorrow.
7. Distribution of Hugs The rights attached to the hugs must apply to all to whom the hugs are redistributed without the need for execution of an additional license by those parties.
8. Hugs Must Not Be Specific to Rhonda The rights attached to the hugs must not depend on the hugs being related to Rhonda. If the hugs are extracted from Rhonda and used or distributed without Rhonda nearby but otherwise within the terms of the hug's permissions, all parties to whom the hugs are distributed should have the same rights as those that are granted in conjunction with Rhonda.
9. Hugs Must Not Contaminate Other People If you are contagious (e.g. got the flu, or worse) you have to apply appropriate counter measures to not transfer your illness with your hugs.
10. Example Hugs This Group Hug modification and of course the Free Hugs Campaign are great examples of what we consider Free.

One last note: If you feel like it you don't have to wait until I wear my Free Hugs shirt again. I am fine with receiving (or giving) hugs like almost always. Surprise me. I at least know then that you read the RFHG. :) Like always, enjoy!

/personal permanent link Comments: 3 Flattr this

Thanks to the great work of the XBMC Team XBMC 13.0 Gotham has been released last Sunday and now XBMC from Debian can be downloaded from experimental to Jessie and Sid systems. It will take some time to enter unstable since it is blocked by the Libav 10 transition, but that will happen, too, eventually. I have also set up a separate repository at http://people.debian.org/~rbalint/ppa/xbmc-ffmpeg/ based on the Debian packages in main but using XBMC s internal copy of FFmpeg because I received several request asking for this variant. The packages there can be used on Wheezy (stable), Jessie (testing) and Sid (unstable) but are not part of Debian. Update 1: For the interested parties the XBMC 13 Libav compatibility patches are available from a git branch in the packaging repository.

Debian has recently received a donation of 8 build machines from Marvell. The new machines come with Quad core MV78460 Armada XP CPU's, DDR3 DIMM slot so we can plug in more memory, and speedy sata ports. They replace the well served Marvell MV78200 based builders - ones that have been building debian armel since 2009. We are planning a more detailed announcement, but I'll provide a quick summary: The speed increase provided by MV78460 can viewed by comparing build times on selected builds since early april: Qemu build times. We can now build Qemu in 2h instead of 16h -8x faster than before! Certainly a substantial improvement, so impressive kit from Marvell! But not all packages gain this amount of speedup: webkitgtk build times. This example, webkitgtk, builds barely 3x faster. The explanation is found from debian/rules of webkitgkt:

# Parallel builds are unstable, see #714072 and #722520
# ifneq (,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))
#   NUMJOBS = $(patsubst parallel=%,%,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))
#   MAKEARGUMENTS += -j$(NUMJOBS)
# endif

The old builders are single-core[1], so the regardless of parallel building, you can easily max out the cpu. New builders will use only 1 of 4 cores without parallel build support in debian/rules. During this buildd cpu usage graph, we see most time only one CPU is consumed. So for fast package build times.. make sure your packages supports parallel building. For developers, abel.debian.org is porter machine with Armada XP. It has schroot's for both armel and armhf. set "DEB_BUILD_OPTIONS=parallel=4" and off you go. Finally I'd like to thank Thomas Petazzoni, Maen Suleiman, Hector Oron, Steve McIntyre, Adam Conrad and Jon Ward for making the upgrade happen. Meanwhile, we have unrelated trouble - a bunch of disks have broken within a few days apart. I take the warranty just run out... [1] only from Linux's point of view. - mv78200 has actually 2 cores, just not SMP or coherent. You could run an RTOS on the other core while you run Linux on the other.

Some brief notes, between tourist-moments.

Temporary file races

I reported some issues against the lisp that is bundled with GNU Emacs, the only one of any significance related to the fall-back uudecode option supported by tramp.el. (tramp allows you to edit files remotely, it is awesome.) Inadvertantly I seem to have received a CVE identifier refering to the Mosaic web-browser. Damn. That's an old name now.

Image tagging

A while back I wrote about options for tagging/finding images in large collections. Taking a step back I realized that I mostly file images in useful hierarchies:

Images/People/2014/
Images/People/2014/01/
Images/People/2014/01/03-Heidi/  RAW JPG thumbs  
Images/People/2014/01/13-Hanna/  RAW JPG thumbs  
..

On that basis I just dropped a .meta file in each directory with brief notes. e.g:

name     = Jasmine XXX
location = Leith, Edinburgh
source   = modelmayhem
theme    = umbrella, rain, water
contact  = 0774xxxxxxx

Then I wrote a trivial perl script to find *.meta - allowing me to create IMAGE_123.CR2.meta too - and the job was done.

Graphical Applications

I'm currently gluing parts of Gtk + Lua together, which is an experiment to see how hard it is to create a flexible GUI mail client. (yeah.) So far its easy if I restrict the view to three-panes, but I'm wondering if I can defer that, and allow the user to handle the layout 100%. I suspect "not easily". We'll see, since I'm not 100% sold on the idea of a GUI mail client in the first place. Still it is a diversion.

Finland

I actually find myself looking forward to my next visit which is .. interesting?