Good news from the Portable C compiler (PCC): their latest snapshot supports multiarch. This means pcc will compile and work out-of-the-box on Debian and Ubuntu. I couldn’t resist sharing my debs, so I learnt how to use Launchpad and set up a dedicated repo. Feel free to use and comment.

The developers of PCC (the Portable C compiler) released version 1.1.0 of the compiler and compiler library, so I decided to give it a run on my computer.

Source packages are available at ftp://pcc.ludd.ltu.se/pub/pcc/. To get a working compiler, one needs to build both pcc and pcc-libs. I followed the instructions for earlier versions of Ubuntu, with some modifications.

First, for uniformity reasons, everything will be installed in /usr instead of the default /usr/local. All libs go to /usr/lib instead of libexec. So, the ‘configure’ command looks like ./configure --prefix=/usr --libexecdir=/usr/lib.

for both packages. The order probably does not matter. I started with ‘pcc’. If ‘flex’ and ‘bison; are missing, the ‘configure’ script will not complain, but the build will fail. So we need to ‘sudo apt-get install flex bison’ before going any further. Compilation is lightning fast, but you can accelerate it a bit by using

make -j[number of cpu cores/threads]

Next, we install the compiled files to their places under /usr. Instead of doing ‘sudo make install’ I did ‘sudo checkinstall’.

The install of ‘pcc’ failed because of a conflict in /usr/share/man/man1/cpp.1, so I had to rename the man file and repackage the deb (here is a good guide).

The install of ‘pcc-libs’ went smoothly, but when trying to build a helloworld.c, pcc executable complained about not finding ‘crt1.o’ and ‘crti.o’. It turned out that it’s a well-known problem not yet solved in 1.1.0 (see discussion here). I just copied these files (together with ‘crtn.o’) from /usr/lib/i386-linux-gnu to /usr/lib/pcc/i686-pc-linux-gnu/1.1.0/lib, and repackaged this deb, too.

To add the final touch, I rebuilt both packages with ‘pcc’ instead of ‘gcc’ (by passing CC=pcc to the ‘configure’ scripts). Here are the packages for i386:

Although I consider myself a seasoned Seamonkey user, I regularly bump into the same problem: after I set up a new mail account, it fetches all mail from the server and happily deletes the originals. It is not much of a problem, because I delete them from time to time, but I still felt somewhat uneasy to see them deleted. Same thing happened yesterday. Recently I switched to my own mail server and, as have full control over it, I figured that this time I should be able to put my mail back. Here’s how I managed to restore all deleted mail.

Step 1. Find your local mailbox

Seamonkey stores its local mailbox somewhere like ~/.mozilla/seamonkey/8fde346h.default/Mail. In case you fetch mail from several addresses, there will be several sub-directories here (one for each source of mail). Locate the directory that corresponds to the mailserver you need, cd to it, and find the file called Inbox.

Step 2. Upload your mailbox file to your mailserver

scp Inbox username@mailserver.name:/path/to/user/home

Step 3. Transfer the messages into your mail account

This is the most important part. Once your mbox file is on the server, you need to parse it and move every message into your mail account. I did it with

formail -s /usr/lib/dovecot/dovecot-lda -d username < Inbox

Wait for the transfer to end (it may take quite some time, depending on the mailbox size), clean up (delete the Inbox file).

Downsides:

The dates will be broken (the date of transfer instead of the date when the original mail arrived).

Because of the issue above, your mail client will download all messages again.

Let’s assume we have three sibling elements (list items in this example, but it can be anything), like this:
<ul>
<li id="1">One</li>
<li id="2">Two</li>
<li id="3">Three</li>
</ul>

We want to cycle through them by pressing up/down keys. We want the “active” item to be highlighted somehow (say red text instead of black. All we need is some JavaScript:var active_id = '1';
Element = document.getElementById(active_id);
Element.style.color = 'red';

It has been almost four months since the initial release of this plugin. Here is a brief wrap-up of what was done in this time and an outline of my plans for the future.

At this point, the latest stable version is 0.4.1. Compared to 0.1, the plugin was improved in a number of ways. Both the button and the pod list are now customizable. A customizable button means that you can change the way your share button looks (shape, size, color, mouse-over effects, text on the button etc). Customizable pod list means that the blog admins can hand-pick the pods that readers are likely to use, and hide the unnecessary ones.

Some more improvements are underway and will probably be included in the forthcoming version 5.0:

Internationalization support is added. All strings from version 4.1 are internationalization-ready.

There is an ongoing effort to translate the plugin into other languages. At this point, Portuguese (Brazil), Romanian, Russian and Spanish translations are ready, with the Italian and German versions likely to follow soon. Special thanks go to Vostok, the admin of DIASPORA* BRAZIL, who contributed the Portuguese translation and to Andrew Kurtis from Webhostinghub.com, who contributed the Spanish translation.

It will also be possible to replace the button with a custom image. Some great button images can be found at Domestic Empire blog, all licenced under CC-BY-NC-SA (Note: A perfect license for end-users, but less so for plugin developers).

Ideas for the future include integration with other social buttons (to give readers more choice), color-profiles (to make it easier for bloggers to choose the right color combinations), further localizations (to widen the user base), customizable text for the reshared posts etc.

After announcing the Share on Diaspora plugin on JoinDiaspora.com, I received a comment from Marc Jay Cobbs who “managed to save a wrong pod URL”, which renders the button unusable. Because I did not read carefully the javascript function that saves URLs (I reused it from another button), my answer was misleading. Time to correct the errors.

The button can lock the user into resharing to one single Diaspora pod. The lock is pretty strong — instead of saving the preferred pod into a cookie, it saves it into a localStorage object, which proved to be very difficult to get rid of. It might be better to save it into a cookie, but I decided against this “functionality”, so I’ll be removing it in future releases.

In the meantime I wrote a little tool to inspect (and delete!) the localStorage objects. Apparently, there’s nothing like this available, or at least nothing I could find. It’s in my GitHub repo, feel free to use it: https://github.com/ciubotaru/localStorage-cleaner. It’s very easy to use: save the file somewhere, open it with your browser and delete the unnecessary objects.

Not that I’m planning to write plugins for WordPress on a regular basis, so the first attempt may very well be the only one. Anyway, that is it: I wrote a plugin for WordPress.

This plugin adds a “share on D*” button to the bottom of my blog posts. D* stands for Diaspora, a free and open-source distributed social network (basically, a network of independent, but interconnected, servers). While we can see an entire zoo of share buttons for Facebook, Twitter and the like, Diaspora buttons are really hard to come by. The existing buttons are mostly limited to one host, while the code of the “properly cooked” ones can not be used out of the box. My plugin is nothing but an effort to collect the good code and package it.

This is how it looks in the `Twenty Thirteen’ theme, under the default `Hello World’ post:

Share on Diaspora button

Choose a Diaspora pod from the list or type it in the text field.

Share on Diaspora button

The plugin is written according to Diasporial quidelines — it allows the user to select his/her pod. Its code is hosted in my Github repository. Version 0.1 of the plugin has passed the official WordPress screening and was accepted into the WordPress Plugin Directory (plugin page). Everybody is welcome to use, distribute or improve it.

While sniffing the traffic flowing through a cjdns node is not possible by design (and that’s the selling point of cjdns!), a node owner might wish to see the traffic for which his/her node is the source or the destination.

1. Add a new rule to ip6tables:

$ sudo ip6tables -A INPUT -i tun0 -j LOG --log-prefix "ip6tables: "
where ‘tun0’ is the cjdns interface (different systems can have different number), and –log-prefix key adds text to the log message, so as to make it easier to filter.

2. Create a new rule of rsyslog (rsyslog is the logging daemon on Ubuntu, other systems can have different daemons, and different settings):$ sudo touch /etc/rsyslog.d/ip6tables.conf
$ sudo echo ':msg, contains, "ip6tables: " -/var/log/it6tables.log' >> /etc/rsyslog.d/ip6tables.conf
$ sudo service rsyslog restart
where the first line creates a new config file for rsyslog, the second one adds a rule to redirect all messages that contain “ip6tables: ” to a separate log file, and the third one restarts the logging daemon with the new config.

Done! Now, if there is some incoming/outgoing (transit excluded) activity on the node, the log will contains something like:

After a year of planning I have finally made up my mind and made a case for my computer.

Because I have neither tools, nor experience in building computer cases, I had to renounce to such materials like aluminum (the case would have been much more robust if I used it), or acrylic glass (would have looked much better), and stopped at plastic — easy to cut, easy to glue, and simply easy. Here is the final result:

Since it’s an Atom-based board, it does not require active ventilation. The board is fan-less, but the fan from the power supply unit is located right above the CPU heatsink and sucks the hot air from around the CPU. Besides this, walls are missing in two of the six sides of my case, so I believe the board has sufficient air flow.