Gunnar Wolf: Happy Public Domain day, even for the inhabitants of the longest-copyright-term country
I can t work out the logic behind the above advert for Energy Watch which was on a billboard near Ringwood Station in Melbourne, Australia. The only thing that it clear is that it spreads bad ideas about mental illness and psychiatric treatment. It doesn t make me want to do business with them.
The above picture is a shop-front for the Antons clothing store (I m not sure if they are a tailor or if they sell ready to wear). It was taken on Lonsdale St, Melbourne where the store apparently used to be, now they are in Melbourne Central.
The above pictures show more detail. Unfortunately the combination of lighting and my camera (Xperia X10 phone camera) wasn t adequate to show the apparent ethnic differences between the two men. It seems that the most likely Australian interpretation of the ethnic groups that are represented are African (maybe Afro-American), Southern-European or maybe American Hispanic, North-Western European, and Japanese. It s good to have mannequins representing the fact that not everyone in Australia is white, but different facial expressions for different races seems a strange choice (admittedly it might be a choice made by mannequin manufacturers). Also the Japanese woman with fan idea is rather outdated.
I ve just started reading You May Ask Yourself: An Introduction to Thinking Like a Sociologist (Second Edition)
by Dalton Conley. I ve only read the first chapter, but that was good enough that the entire book has to be good enough to recommend.
So, I intended to be completely away from my computer during my vacations, but hey. I have been interested in this new extension Apple added to the C language a little while ago which introduces the equivalent of closures to C. Today I spent a few minutes looking into it and writing a few tests with the help of clang.
Here s something I came up with, to use a block as the callback for a GIO asynchronous call:
#include <Block.h>
#include <gio/gio.h>
typedef void (^Block)();
static void async_result_cb(GObject* source,
GAsyncResult* res,
gpointer data)
Block block = (Block)data;
block(res);
int main(int argc, char** argv)
g_type_init();
if (argc != 2)
g_error("Blah.");
return 1;
GMainLoop* loop = g_main_loop_new(NULL, TRUE);
GFile* file = g_file_new_for_path(argv[1]);
g_file_query_info_async(file,
G_FILE_ATTRIBUTE_STANDARD_CONTENT_TYPE,
G_FILE_QUERY_INFO_NONE, G_PRIORITY_DEFAULT,
NULL, async_result_cb, (gpointer) ^ (GAsyncResult* res)
GError* error = NULL;
GFileInfo* info = g_file_query_info_finish(file, res, &error);
if (error)
g_error("Failed: %s", error->message);
g_error_free(error);
return;
g_message("Content Type: %s",
g_file_info_get_attribute_string(info, G_FILE_ATTRIBUTE_STANDARD_CONTENT_TYPE));
g_object_unref(info);
g_main_loop_quit(loop);
);
g_main_loop_run(loop);
g_object_unref(file);
return 0;
Pretty neat, don t you think? To build you need to use clang and have the blocks runtime installed (libblocksruntime-dev in Debian). Here s the command I use:
$ clang -fblocks -o gio gio.c -lBlocksRuntime pkg-config --cflags --libs gio-2.0
Summary: It is important that we (the Debian community that relies on OpenPGP through
GNU Privacy Guard) stop using short key IDs. There is no vulnerability in OpenPGP and GPG.
However, using short key IDs (like 0x70096AD1) is
fundementally insecure; it is easy to generate collisions for short key IDs.
We should always use 64-bit (or longer) key IDs, like: 0x37E1C17570096AD1
or 0xEC4B033C70096AD1.
TL;DR: This now gives two results: gpg --recv-key 70096AD1
$ gpg --keyserver pgp.mit.edu --recv-key 0x70096AD1 gpg: requesting key 70096AD1 from hkp server pgp.mit.edu gpg: key 70096AD1: public key "Asheesh Laroia <asheesh@asheesh.org>" imported gpg: key 70096AD1: public key "Asheesh Laroia <asheesh@asheesh.org>" imported gpg: no ultimately trusted keys found gpg: Total number processed: 2 gpg: imported: 2 (RSA: 1)I also saw it as an opportunity: I know that cryptography tools are tragically easy to mis-use. The use of 32-bit key IDs is fundamentally incorrect -- too little entropy. Maybe shocking people by creating two "identical" keys will help speed the transition away from this mis-use.
$ gpg --list-keys grep 70096AD1 pub 1024D/70096AD1 2005-12-28Just ask GPG to refresh:
$ gpg --keyserver pgp.mit.edu --refresh-keys gpg: refreshing 1 key from hkp://pgp.mit.edu gpg: requesting key 70096AD1 from hkp server pgp.mit.edu gpg: key 70096AD1: public key "Asheesh Laroia <asheesh@asheesh.org>" imported gpg: key 70096AD1: "Asheesh Laroia <asheesh@asheesh.org>" not changed gpg: Total number processed: 2 gpg: imported: 1 (RSA: 1) gpg: unchanged: 1 gpg: no ultimately trusted keys foundYou can see that it set out to refresh just 1 key. It did that by querying the keyserver for the short ID. The keyserver provided two hits for that query. In the end, GPG refreshes one key and actually imports a new key into the keyring! Now you have two:
$ gpg --list-keys grep 70096AD1 pub 1024D/70096AD1 2005-12-28 pub 4096R/70096AD1 2011-03-11There is a bug filed in GNU Privacy Guard about this. It has a patch attached. There is, at the moment, no plan for a new release.
[options]
auth = no_ccache
account = no_ccache
session = no_ccache
[run]
authenticate = PAM_SUCCESS
acct_mgmt = PAM_SUCCESS
open_session = PAM_SUCCESS
close_session = PAM_SUCCESS
[prompts]
echo_off = Password: %p
[output]
INFO user %u authenticated as %u
That's a complete and fairly complex test. The test framework takes care
of running the listed entry points, passing them the given PAM
configuration, and checking the return status. It provides a conversation
function that checks the prompt and its type and replies with the text
after . As you can see, it supports some escapes that are
replaced by data passed into the test suite driver, in this case the
password to use for testing. And it checks the logging output, including
the priority level, and similarly supports escapes there.
Running simple tests is very easy and is doable with a tiny C program.
Here's a complete test program from pam-krb5, one that tests functionality
that doesn't require a valid password and hence doesn't need to do much
setup:
#include <config.h>
#include <portable/system.h>
#include <tests/fakepam/script.h>
int
main(void)
struct script_config config;
plan_lazy();
memset(&config, 0, sizeof(config));
config.user = "root";
run_script_dir("data/scripts/basic", &config);
return 0;
That's all there is to it. That finds every configuration file like the
above in the tests/data/scripts/basic directory in the package
source and runs through each one, checking the results, and outputing the
results as TAP output (the protocol used for the Perl test suite, and also
my C TAP Harness package).
There are, of course, other things that it can do: more substitutions,
setting the authtok in advance of calling the module, and a callback so
that one can inspect PAM state before the PAM session is shut down. I've
started writing some
documentation, although so far it primarily covers the configuration file
syntax and the headers are the best reference for the API.
The source code of the pam-krb5 package
are the best reference so far. The library itself is part of
rra-c-util and, like the rest of that
package, is designed to be copied into the package that uses it and built
alongside it so that it can be linked easily with the test programs.
It's worth noting that there isn't a way to use it to test installed PAM
modules that are already bound to the system libpam library. The way one
builds test programs currently is to link the test program with the
individual objects making up the PAM module and then link with this
library and the TAP library, since that ensures the right symbols are
called. But it may be possible to do something tricky using LD_PRELOAD if
anyone feels inspired.
--buildresult .., so if yoy use it, .pbuilderrc really has to
handle everything.
You can get the latest version from my scripts distribution page, and I suspect it will show up in the
git-buildpackage package before too long.
Chris Siebenmann
sez:
The profusion of network cables strung through doorways here demonstrates that two drops per sysadmin isn t anywhere near enough.What I actually suspect it demonstrates is that Chris company hasn t learnt about the magic that is VLANs. All of the reasons he cites in the longer, explanatory blog post could be solved with VLANs. The only time you can t get away with one gigabit drop per office and an 8 port VLAN-capable switch is when you need high capacity, and given how many companies struggle by with wifi, I m going to guess that sustained gigabit-per-machine is not a common requirement. So, for Christmas, buy your colleages a bunch of gigabit VLAN capable switches, and you can avoid both the nightmare of not having enough network ports, and the more hideous tragedy of having to crawl around the roofspace and recable an entire office.
$ cp -r /usr/share/doc/openvpn/examples/easy-rsa/2.0 /etc/openvpn/easy-rsa $ cd /etc/openvpn/easy-rsaIn the vars file change the KEY_SIZE variable from 1024 to 4096 for good measure:
export KEY_SIZE=4096Then, read in the vars file, clean old keys and certificates (if any) and create new ones:
$ . ./vars $ ./clean-all $ ./build-caYou'll now have the chance to enter some data such as country code (e.g. "DE"), state/province, locality, organization name, organizational unit name, common name, name, and email address. The values you choose don't really matter much (except for commonName, maybe, which could be your hostname or domain or such). Finally, the ca.key (root CA key) and ca.crt (root CA certificate) files will be created. Next, we'll create the server key:
$ ./build-key-server serverYou'll have to enter lots of info again (see above), commonName could be "server" or such this time. Upon "Sign the certificate? [y/n]" say y, as well as upon "1 out of 1 certificate requests certified, commit? [y/n]". Finally, the server.key and server.crt files will be created. Same procedure for creating a client key (I used "client1" as filename and commonName here):
$ ./build-key client1Next up we'll generate Diffie Hellman parameters (this will take a shitload of time due to keysize=4096, go drink some coffee):
$ ./build-dhWhen this step is done, you'll have a dh4096.pem file. As we want to use OpenVPN's "tls-auth" feature for perfect forward secrecy (it "adds an additional HMAC signature to all SSL/TLS handshake packets for integrity verification"), we'll have to generate a shared secret:
$ openvpn --genkey --secret ta.key $ mv ta.key keysSo much for creating keys. Now, we'll have to configure OpenVPN. Copy the default server config file and edit it:
$ cd /etc/openvpn $ cp /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz . $ gunzip server.conf.gzThe most important change in my setup is that I use port 443/TCP instead of the usual OpenVPN default of 1194/UDP. This increases the chances that you'll be able to use OpenVPN in almost all places, even in environments which firewall/block lots of stuff. Port 443/TCP (for https) will almost always be usable. I also uncommented the following line, which tells the client to use the VPN interface (usually tun0) per default, so that all the client's traffic (web browsing, DNS, and so on) goes over the VPN:
push "redirect-gateway def1 bypass-dhcp"Here's my server config file (comments and commented out lines stripped):
port 443 proto tcp dev tun ca /etc/openvpn/easy-rsa/keys/ca.crt cert /etc/openvpn/easy-rsa/keys/server.crt key /etc/openvpn/easy-rsa/keys/server.key # This file should be kept secret dh /etc/openvpn/easy-rsa/keys/dh4096.pem server 10.8.0.0 255.255.255.0 ifconfig-pool-persist ipp.txt push "redirect-gateway def1 bypass-dhcp" keepalive 10 120 tls-auth /etc/openvpn/easy-rsa/keys/ta.key 0 # This file is secret comp-lzo user nobody group nogroup persist-key persist-tun status openvpn-status.log log-append openvpn.log verb 3You can now start the OpenVPN server, e.g. via
$ /etc/init.d/openvpn restartServer firewall setup/changes: I'm running a custom iptables script on pretty much all of my boxes. Here's the relevant changes needed to allow the OpenVPN server to work properly. Basically, you need to enable IP forwarding, accept/forward tun0 traffic and setup masquerading (change "eth0" below, if needed):
echo 1 > /proc/sys/net/ipv4/ip_forward iptables -A INPUT -i tun+ -j ACCEPT iptables -A FORWARD -i tun+ -j ACCEPT iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -t nat -F POSTROUTING iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADEMy firewall script gets run upon every reboot. If you don't use such a script, you could add the above stuff to your /etc/rc.local file. On the client: Install OpenVPN (apt-get install openvpn), then copy the default client config file and edit it:
$ cd /etc/openvpn $ cp /usr/share/doc/openvpn/examples/sample-config-files/client.conf .Change the parameters to match the server config (port 443/TCP, and so on) and use "tls-auth /etc/openvpn/ta.key 1" (note the "1" on the client, and the "0" on the server!). Replace xxx.xxx.xxx.xxx with the public IP address of your OpenVPN server. If it doesn't have a public, static IP address already, you can use services such as DynDNS, or (my preferred method), my ssh-based DIY poor man's dynamic DNS setup. Here's my full client config:
client dev tun proto tcp remote xxx.xxx.xxx.xxx 443 resolv-retry infinite nobind user nobody group nogroup persist-key ca /etc/openvpn/ca.crt cert /etc/openvpn/client1.crt key /etc/openvpn/client1.key ns-cert-type server tls-auth /etc/openvpn/ta.key 1 comp-lzo verb 3Now you only need to copy the required certificates and keys to the client (into /etc/openvpn): ca.crt, and ta.key. Do not copy the other, server-specific private keys and such to the client(s)! Also, the root CA key (ca.key) should not even be left on the server, but rather moved to some offline storage/box, so that it cannot fall into the wrong hands, e.g. in the case of a server compromise. I prefer to manually start the client on my laptop when needed, so I use AUTOSTART="none" in /etc/default/openvpn and then start the client via:
$ openvpn /etc/openvpn/client.confThat's it. Comments and suggestions for improving the setup and/or the security aspects of it are highly welcome!
"Static program analysis" is a technique whereby a program is
verified for errors without actually running it. Finding bugs manually
with a debugger and one's brain is tedious, so every shortcut that can
help you avoid having to do so is great.
There are some commercial tools available to do such analysis, some
of which are rather expensive; but there are also some open source tools
available to do similar things. One of these is built into clang, the C compiler of the
LLVM project.
Using it is fairly simple. Instead of compiling something with
'make', compile it with 'scan-build make'. This will
set the CC (and similar) environment variable(s) so that before the
compiler is ran, the clang static-analysis checker is run over the very
same source code. The output of this checker is an HTML file with your
source, but with comments added to explain the bugs which the tool
found.
What does that mean? well, let's look at an example,
shall we? <iframe height="500px" src="http://barbershop.grep.be/~wouter/scan-view-example#LN1493" width="80%"></iframe>
The iframe above contains one out of three reports produced by a
scan-build run over the nbd source code (if there's no
iframe, someone scrubbed some HTML in your RSS reader. Just follow the
link just above instead). The other two are 'dead assignments', which
might mean that I'm currently depending on some undefined behaviour
(which would be bad), or it might mean that I'm being overly cautious
(which makes my code future-proof, which would be good), or it might
mean something else I still need to investigate. But this one is
pretty interesting.
In the example, there are eight, numbered, comments in the source
code. The first seven show the code path which scan-build took through
my code before getting at the eighth comment; and the eighth is where
things go bad. In this case, when going through the function as shown,
we have a NULL pointer dereference.
When looking at the scan-build output, it's important to realize a
few things. First, the code path shown may be just one
of a number of possible code paths. For instance, the null pointer
dereference would still happen if the phase function parameter
would not contain the NEG_INIT bit with the client
pointer set to NULL. However, clang does not show these other code
paths; this is presumably an optimization ("if we've already shown that
this kind of bug is possible at a particular location through one code
path, don't bother recording future instances of that very same bug at
the exact same location through another code path"). This means that
sometimes, some of the branches shown may be completely irrelevant to
the bug at hand. In this particular case, in fact, it's possible to show
the bug with just the eighth comment; the first seven are in fact
totally irrelevant.
Second, the fact that the clang static analyser found a bug
does not mean that it's possible to crash the application. Yet.
In this particular case, the negotiate function will never be
called with the NEG_INIT or NEG_MODERN bits not set,
and with the client parameter set to NULL. That's an
implicit assertion; there are a few ways in which this function may be
called, but the client parameter may only be NULL if
NEG_INIT and NEG_MODERN are both set at the same
time.
Since nbd-server doesn't currently call the
negotiate function in that way, it is not currently possible to
crash the server by exploiting this bug. But that doesn't mean it won't
ever be possible, nor that there isn't a bug in the code. We
may assume that the above rules are true, but we never check
it. Adding an assertion to that effect should make sure that no future
change to the code will accidentally introduce that error and cause a
NULL pointer dereference.
Is this a silly and useless precautionary measure? Not really.
Usually, bugs happen in code not because someone wasn't thinking
straight, but because there's so much going on inside a piece of
software that it can be too much for any programmer to remember. If a
function assumes that its parameters are within a given subset
of all possible states, but does not check that this is in fact true,
then when (not if) some future change incorrectly introduces a state
that is outside of the assumed states, things will break. And that's
Bad(TM).
Calypso CalDAV/CardDAV/WebDAV for Android and Evolution
Ever since I bought my first Palm Pilot in 1997, I ve relied upon a
pocket-able device to carry a copy of my calendar and contacts, and for
that same database to be present on my laptop. I went through a long
list of Palm-compatible devices, including both the Palm Treo and Palm
Centro telephones. I even wrote a number of my own Palm
applications. Years ago, it was pretty obvious that I d have
to find a new phone, but I was stuck looking for something that could
provide the same hot-sync functionality.
SyncML on the Series 40
I bought a Series 40 Nokia phone in Shanghai that promised SyncML
support. Given that I had seen numerous SyncML implementations for
Linux, it seemed like I should be able to get something to work.
SyncML on the Series 40 is a disaster the phone couldn t actually
store all of my contacts, and it couldn t hold half of the data
fields I used. So, that phone landed in the box and back to the Centro
I went.
SyncML on the N900
Nokia kindly sent me an N900 at some point, so I gave SyncML another
try. Given that the N900 runs evolution-data-server, and that I ve had
evolution-data-server running on my laptop, it seemed like I should be
in business. Well, almost. It took several days of hacking to fix bugs
in the evolution SyncML back end, then another several days fussing
with opensync.
I ended up abandoning direct synchronization as unworkable opensync
would sit in an infinite loop, or worse, trash my database
completely. I finally found syncml-ds-tool , which is a debugging
tool that comes with opensync. This tool simply synchronizes a set of
disk files, one per contact or calendar entry, with the phone. That
worked for well over a year. And then, a few months ago, Bluetooth on
the laptop stopped connecting with the phone s SyncML server. I d get
ECONNREFUSED every time I tried to use it. So much for the N900. DUN
still worked, mostly, although it too would get ECONNREFUSED at times,
but retrying seemed to make it work.
However, While the N900 SyncML solution worked, I discovered another
thing I wanted contacts and calendar entries stored in individual
files and revision controlled with git. This makes it reasonable to
delete stale calendar entries and know that they re never really gone,
just left behind in an older version of the calendar. And, if you mess
up, you can recover by poking at the database with git directly.
I switched back to the venerable Palm Centro; it turns out that
calendar and contacts are more important to me than being able to surf
the web on my phone. Alas, my Centro went swimming in August and has
passed on to the great electronics recycling house in the sky. I pulled
the SIM out and switched back to the N900.
I got my contacts imported on the N900 by copying files over the net
work; not a long-term strategy, but at least I had phone numbers
again. There was no hope for my calendar. I started looking for a
solution in earnest.
How about Android?
At this point in my story, I m sure you re asking why I didn t just
use one of the numerous Android phones that came through my hands. The
answer is simple my calendar and contacts are probably some of my
most personal data, and I m not willing to store them outside of my
direct control, for reasons similar to those which are driving the
development of the FreedomBox.
When Android first came out, it could only talk to Google
services, which didn t meet my hard requirement for personal data
storage.
One of my co-workers had his Google account suspended for violating
the terms-of-service; he asked what he had done, but they wouldn t
say. He asked if he could get his data back, and they said no . They
invited him to create a new account, but it would not ever get any of
the old data. A few days later, he got a nice apologetic email letting
him know that they d made a mistake and that he hadn t, in fact,
violated any of the terms-of-service, and that his old account was
restored with all of his data intact. Wasn t that nice of Google?
WebOS?
I got a WebOS phone over the summer and discovered that while it had
multiple contact/calendar back ends, none of them used standard
protocols and so you only had the choice between multiple corporate
data centers, which isn t actually a choice at all.
Furthermore, the WebOS phone refused route PAN packets over the phone
network, even though I have a data plan which allows this. It s not
that it couldn t support it, it s that it refused.
A couple of weeks after the WebOS phone arrived, HP canceled all of
their WebOS hardware products, which made me less interested in trying
to solve this problem.
Android recovers
About the same time the WebOS phone arrived, I discovered that Google
had published enough information about the calendar/contacts internals
for Marten Gajda to write CalDAV-Sync and
CardDAV-Sync. And then, Andrew McMillan
wrote aCal, which is a
complete replacement for the built-in calendar and contacts
applications and supports CalDAV and CardDAV.
With two different standards-compliant solutions available, it seemed
like it might be time to try Android again.
I d love for CardDAV-Sync and CalDAV-Sync to become free software like
aCal is. Andrew makes money from aCal by offering it for sale via the
Android Market, while still publishing the sources for those who want
to build their own copy.
CalDAV/CardDAV on Linux
I think the most widely known CalDAV server for Linux is probably
DAViCal, a huge pile of PHP and SQL sitting
on top of Apache. I m sure it s suitable for running on a server
and being accessed over the internet, but I m not interested in that,
nor am I interested in having my laptop run Apache and PostgreSQL.
I found a tiny little CalDAV server, Radicale,
which seemed like a lot better fit. It s written in Python and uses
the usual Python HTTP server infrastructure, which provides SSL and
authentication support along with some fairly convenient APIs for
parsing and generating HTML.
Before long, I discovered that Radicale was actually too simple for
my needs. It stores the whole calendar in a single file, re-parsing it
whenever a request is made, so a calendar with just hundreds of
entries caused the server to slow down enough that evolution would
time-out when talking to it.
Also, Radicale doesn t actually parse the calendar entries completely,
it has some ad-hoc code that finds various pieces of data, but without
dealing with the whole syntax.
I started hacking at Radicale to see how far I could get. I changed
the storage code to store one event per file, then added hooks to use
git for change management. Then, I found a full vcalendar/vcard
parsing library in python,
vobject, which I used to
replace the ad-hoc parsing code. Finally, I added support for VCARD
entries as well, allowing the system to store both calendar and
contact information.
Introducing Calypso, a CardDAV/CalDAV server
With this much divergence from the original project, I ve figured I d
best rename things to avoid confusion, so I decided to call it
calypso , after a brief trip through the dictionary looking for names
starting with ca .
Calypso works with evolution, iceowl and the Android CalDAV/CardDAV
plugins. It does not yet work with aCal; for some reason aCal cannot
find any calendars on the server.
Calypso also supports importing calendar changes from the command
line, allowing you to integrate support into a text-based email
application like notmuch or
mutt.
Calypso is available via git from git://keithp.com/git/calypso and is
distributed under the GPL (v3 or later). I still consider it a work
derived from Radicale, and so the code retains all of the Radicale
copyrights along with my own.
Using Calypso
Initial setup
Calypso runs as a regular user, all data are stored in
~/.config/calypso. To initialize calypso:
$ mkdir ~/.config/calypso ~/.config/calypso/calendars
$ cat > ~/.config/calypso/config << EOF
[server]
ssl=true
certificate=/home/keithp/.config/calypso/ssl/server.crt
key=/home/keithp/.config/calypso/ssl/server.key
[acl]
;type=htpasswd
type=fake
filename=/home/keithp/.config/calypso/passwd
$ python ./calypso.py
$ mkdir -p ~/.config/calypso/calendars/private/my_calendar
$ cd ~/.config/calypso/calendars/private/my_calendar
$ git init
$ git commit --allow-empty -m'initialize new calendar'
https://localhost:5233/private/my_calendar
You can add files to the directory at any time; calypso will check the
directory mtime at each operation and update its internal state from
that on disk automatically when the directory changes.
Importing files
Given a set of files with VCALENDAR or VCARD entries, you can import
them with:
$ calypso --import private/my_calendar <filenames...>
Statement of Accomplishment - AIClass 2011
Here's the mail archiving script I was talking about:
http://github.com/jmtd/detachment. Sorry about the name-pun.
There's still a LOT of work to do, but it's useful enough to deploy, with
modifications, now. If you set up a way of pushing stuff in a local directory
to a remote webserver (ideally behind an SSL certificate and with access
control configured) and you have a resolvable hostname for that site, then
you can get at your files from most mail/web client combinations, including
smartphones.
Here's some stats from running it on a sample mailbox:
Before
$ du -sh ncl/archive/2010
116M ncl/archive/2010
$ du -sh ncl/archive/2010 bucket
41M ncl/archive/2010
51M bucket
U=\d+,FMD5=[0-9a-f] 32
component of filenames seemed to do the trick.switch (thing)
case VALUE:
/* Stuff */
break;
case BAR:
/* Nonsense */
break;
default:
/* Whatever */
break;
with if statements instead:
if (thing == VALUE)
/* Stuff */
else if (thing == BAR)
/* Nonsense */
else
/* Whatever */
(where stuff, nonsense and whatever are usually a bit larger). I really don t understand where this has come from the if based form isn t nearly so idiomatic for selecting between a range of values and this seems to have come from nowhere pretty much. Is there some code base out there where this is common practice or something?
Time flies... and very fast.Last time I wrote here I mentioned about my graduation and another post to talk about that, I'll write about it as soon as I get my diploma (because of different printing problems it was delayed for almost 2 years). And I do plan to write more frequently. :-)
There are so many things I'd like to share and tell you about but that would make a long and boring post, so I'll divide it in future entries, so I can keep this diary alive, keep people informed and tell a little bit about my story. Eventually, I may split this diary into a technical and a non-technical blog, but for now, I will stick around mixing topics. :-) Last time I wrote was back in 2009 at DebConf9 in Spain and a lot of things happened that year. Not only for Debian, but also for me.
My last year studying Computer Science was 2009 and that same year I was working full time, I helped organizing a large event for Computer Students (ENECOMP 2009), we had some troubles and side effects with Influenza A (H1N1) in my city (Curitiba, PR) and towards the end of the year I got really sick (not from Influenza) and it took a while to know what was going, during this process I did hurt some people I really love and I'm truly sorry. The past, 2010 went on as busy and unstable as 2009, my laptop's hard disk broke twice (January and October) and I survived thanks to backup and recovery procedures. I took some wrong decisions but fixed it later and learned a lot from my mistakes, decisions and choices.
Then 2011 came, my laptop's hard disk broke again and I lost almost 6 months of emails, I find out that after the second crash in 2010 part of my backup got b0rk3d. Fine, I didn't die, everything seems to be fine, but I'm still catching up with a lot of work and backlog. At different times one of my parents also got really sick and I learned quite a bit on how to deal with it.
Due to the laptop and the different things going on in my life I didn't work for Debian as much as I want and I still feel guilty. :-( But that's fine, this is a kind of public apologize for my peers in Debian (i18n, mirrors, release), I still want to help all of you, but I still have quite a bit of backlog to clean and quite a few things to learn in the process. And in general, I'm really sorry if I didn't (or I couldn't) work for Debian as much as I want.
Although I'm taking the chance to apologize in this post, I still want to make clear that I'm quite happy. This last year was pretty good, I had the opportunity to attend DebConf again and also got to know Sarajevo and Zagreb. New lessons were learned, better work cycles, nicer solutions. Today I'm completing 29 years old. 29. This is quite some time, not a long ride, but for one reason or another, I have high hopes for 2012 and what awaits me. And I do plan to learn more, to help more and whenever possible, to contribute back.
Google Maps is now mapping the indoors. I saw an ad for this while passing through MSP yesterday (given how much time I spend on the Internet, it's strange and a little embarrassing to learn about new things on the Internet from airport billboards), since one of their initial targets is the infamous Mall of America.
Detailed floor plans automatically appear when you re viewing the map and zoomed in on a building where indoor map data is available. The familiar blue dot icon indicates your location within several meters, and when you move up or down a level in a building with multiple floors, the interface will automatically update to display which floor you re on. All this is achieved by using an approach similar to that of My Location for outdoor spaces, but fine tuned for indoors.Thoughts about this:
I've released version 0.24 of Obnam,
my backup application.
USER VISIBLE CHANGES
--exclude regular expression is wrong, Obnam now gives an
error message and then ignores the regexp, rather than crashing.--compress-with=gzip.--deduplicate setting can be one of never (fast, but uses more space);
verify (slow, but handles hash collisions gracefully); and
fatalist (fast, but lossy, if there is a hash collision). fatalist
is the default mode.--dry-run option. Thanks to Peter Palfreder for
the bug report.--verify-randomly allows you to check only a part of the
backup, instead of everything.
here's my RCBW
report for this week. again, nothing spectacular, mostly uploading packages
where patches were already in the BTS. thanks to all the patch
creators and forwarders!
Next.