Screen

by ⋅ 1 Comment

Many people I know routinely use GNU Screen but I had never used it because a) I usually work on servers locally or on-site through SSH, b) it’s quite complex to learn and key combinations interfere with other applications.

This time, however, I’m VPN-ing to the servers I’m setting up Zumastor on. There are two steps in the set up which take a lot of time, initializing the logical volume with nulls (optional, but my advice is you accomplish it for improved replication times) and creating the filesystem. If you are over a bad VPN connection (as it was the day before yesterday), you are essentially fucked because every time the VPN disconnects, the interactive command you launchped is aborted and you need to start it over again. Grrr.

So I decided it was about time to get me started with ‘screen’. Oh my. I love it. It comes with every Linux and *BSD distribution and it does its job very well. In case you want to give it a try, read the GNU Screen introduction and beginners tutorial which Kuro5hin (read “corrosion”) published four years ago.

libdigest & libpam-digestfile

by ⋅ Leave a Comment

I have started a new open source project: The Digest Software Project. It’s a small project where I develop two tiny libraries, libdigest and libpam-digestfile.

libdigest is a C library which generates RFC2617-compliant digests, used by Apache and others.

libpam-digestfile is a Pluggable Authentication Module which lets you use an arbitrarily-named text file similar in structure to /etc/passwd to authenticate users but using digested passwords (see RFC 2617 for more information about the digest algorithm).

Both libraries are stable and in production.

Ruby magic

by ⋅ Leave a Comment

Richard Moore blogged about setters/getters vs direct access to member variables and why encapsulation is good today. Ruby excels in this aspect, IMHO:

With Ruby your code is the same regardless you are accessing a variable or a method. This means something that now is a variable, you can transform it in the future in a method with calculates a value and the code accessing it does not change at all.
Imagine you have a method to print the volume of a bottle and you had stored the volumes in pints (Imperial units). Your code is:

volume = get_bottle_volume_from_database() # these are pints, you would be getting the "10" value from a database

puts "The volume is " + volume.to_s
=> The volume is 10

Now you want to move to international units (litres). You can do this:


def volume
return get_bottle_volume_from_database() * 0.473176475 # Transform from pints to litres
end

puts "The volume is " + volume.to_s # See? "volume" is a method here (it was a variable in the former example) but our code has not changed!

Of course this is a contrived example but keep in mind this syntax allows for all kinds of magic. For example, it makes Ruby on Rails feasible

MinGW & exceptions

by ⋅ 1 Comment

Did you know the code the compiler generates to handle C++ exceptions is not written in stone? I did not.

Did you know there are two preponderant styles to do that, DWARF(2) and SJLJ? I did not

When most of the unit tests in ZeroC ICE failed after building it with MinGW, I suspected something was wrong. It turned out the stable MinGW version provides gcc/g++ 3.4.5, which implements exceptions using the SJLJ style but has not implemented propagatation of user exceptions across libraries. That was the reason why unit tests were failing.

I have already built third party dependencies (OpenSSL, Bzip2, Expat and BerkeleyDB) with a gcc/g++ 4.2.1 which produces SJLJ code and is able to propagate user exceptions. ICE is now building on the side (some warnings and info messages are shown, let’s see what happens as some of them are not my fault).