« April 2009 | Main | June 2009 »
Another puzzle by the Bram Cohen (the same who created BitTorrent) and Oskar van Deventer: the Geary cube.
Some of their previous puzzles are very interesting like the JumblePrism or my two favorites, the RotaCubes and the Bramboules.
Oscar van Deventer creates stranger things: the WimTvane or the Topsy Turvy are just two examples
He also has a beautiful adding machine for kids.
I like puzzles. Puzzles good.
I mentioned last week that I had started using PGP Whole Disk Encryption on my laptop (a first generation MacBook Pro 17" btw, it has a 32bit 2.16Ghz Core Duo with 2Gb RAM).
I encrypted the external FW800 500Gb hard disk that I use exclusively for Time Machine last night. It took about 8 hours. So far so good.
When I connect it to my mac, a PGP WDE dialog pop-up shows up, asking me for the correct pass-phrase. After I enter it, it shows up as a Time Machine external disk, and the backup starts.
Be aware that, in case of hard disk disasters, encrypting your TM disk can be more awkward than encrypting your internal hard drive.
With a normal non-encripted TM drive, you can boot your Mac from a Leopard DVD, and ask the Installer to restore a TM backup directly.
If you encrypt you TM disk, thats no longer an option. You have to install a bare bones system, install PGP WDE, and then restore the TM backup.
A possible solution (untested for now) is to have a clone of your internal hard drive (even an encrypted clone should work) that you update from time to time. Then you should be able to boot from the clone and restore a TM backup to the internal disk.
As I said, I haven't tried this yet. It should work, I don't see any reason not to.
I do have a clone of my internal hard drive, thats the next one to encrypt. I'll check to see if he is still bootable afterwards, and I'll try to find an extra disk somewhere to restore a TM backup.
I'm really happy with PGP WDE, works great, no surprises so far.
Google kettle let go a cloud of vapor and named it Wave. Of course we cannot know how it works and how similar it is to Drop.io.
Until we do know more about it, we can look through the Wave protocol draft spec, and notice that its built on top of XMPP.
At the same event, the new XMPP-powered mini applications where also announced. Each one is a XML file with all the HTML, CSS, and JS files packed together. Time to see how long it will take a XMPP desktop client with access to a WebKit view to implement this extension. It reminds me all the discussions about embedded applications we had in the API mailing list last year.
The Github gang developed a Mercurial plugin, hg-git, that allows Mercurial users to push/pull from Git servers.
It seems very good (I'm not a Hg user, so I don't really know). Lossless bi-directional synchronization.
Nice.
An article about immutable data structures (which is an excellent read in itself) has two interesting paragraphs about Git:
Casual observers initially criticised git for having a model so simple it was actually naive. It turns out they were confusing the model with its on disk representation. Git makes this distinction very well, and the result is that it implements powerful features (for instance idempotent patch application) which are apparently too complicated in other systems. Git itself isn't simple at all, the problem of version control is a complicated one so any system dealing with it is inherently complex. Git's advantage is that it's built on a very simple and future proof core, allowing the complex parts to evolve more easily.
A very nice way to put it, Yuval.
I've linked this excerpt differently. The linked Git documentation file is well worth a read, if you care about why git turned out as it did. Not that much interesting for day-to-day usage though.
The first release candidate of the 0.13 version of Psi was released just now, and it includes voice calls using Jingle RTP.
I'll keep it running in case you need a guinea pig for tests.
Very good news.
The local::lib module is an essential piece of my workflow nowadays. It allows me to easily keep each project Perl modules separate, and therefore minimize breakage.
Bootstrapping local::lib was reasonably simple but it got a lot simpler with the latest 1.004001 version. Basically you can just pipe the output of a URL into perl to bootstrap it.
The URL is some long beast in the cpansearch.perl.org site, impossible for me to memorize, so I created a shorter version, http:://bit.ly/local-lib. To bootstrap local::lib you now can:
wget -O- http://bit.ly/local-lib | TARGET=target_dir perl
or if you are a curl user:
curl -L http://bit.ly/local-lib | TARGET=target_dir perl
I wish I didn't have to specify the TARGET environment. It should assume, like the previous bootstrap process, ~/perl5. I'll whip up a patch tomorrow.
There is no permalink to the latest version of the bootstrap script, so until I can find a way to alter the destination URL, we are stuck with the current version of it. I do hope a more definitive URL shows up, like the suggested http://install.local-lib.pl/.
The process worked fine for me in a couple of servers around here, but it is not a complete bootstrap. This process installs the local::lib module but doesn't adjust your shell configuration to make the settings stick.
So after you need to run this:
TARGET=perl6 echo "eval \$(perl -I$TARGET/lib/perl5 \
-Mlocal::lib)" >>~/.bashrc
(see the local::lib bootstraping section for csh instructions)
Its an excellent service, and it can only get better.
One down, a lot more to go. Or so I hope...
I love TED presentations, and I was curious about one of the latest ones: 10 things you didn't know about orgasm by Mary Roach.
The presentation is very good, but starting around 10m25s there is a sequence about pig farming in the Netherlands that make me laugh out loud.
Weird stuff.
Update: well, chickens are even worse (PDF)...
For the past week or so, I've kept myself without network access for the larger part of each day.
I check my email and RSS feeds early in the morning and late at night, just before bed, and keep my IM and IRC clients closed.
I needed to take a break, really. I found myself in the worst productivity slump ever, and something had to change.
I have lot of work piled up that I really want to get done:
AnyEvent::Mojo-based implementation;Thats the top 4, and I'm not even including $work stuff. On that side of things, I'm considering switching parts of DBIx::Class-based that I have (and don't particularly like, and in need of some feature-upgrades) to KiokuDB. That's probably the top item.
So far, working offline is paying off. I'm clearly more productive and I'm slowly getting myself out of the hole. I wonder how long I'll keep myself sane this way...
One recurrent worry that I had was about my laptop security. At least once a week I get an email from a local portuguese Mac-zine about stolen Macbooks. When I got them, my first thought was always: if that happened to me, my $bussiness is screwed...
So a couple months ago I started looking around for options to secure my two macs (desktop and laptop) and their Time Machine backup drives against physical theft.
I bought a copy of PGP Whole Disk Encryption and I'm using it on my laptop. On day-to-day usage, you just don't notice the overhead. I suppose that if I had to do I/O intensive stuff I might, but so far it doesn't register at all.
The setup process is slow but painless. It took about 3 hours to encrypt my hard drive, and the laptop remains usable during the whole process. You can even stop and restart if you need to.
You can have several users each one with a different pass-phrase that can unlock the hard drive at boot time. I created two users, one for me, and another for disaster recovery. I generated a long random pass-phrase for the second user, printed two copies, and stored each copy on two different safe deposit boxes that I and my business parter have access to. This way, if I get hit by a bus, my partner can access the content of the drive.
My next step will be to encrypt the entire Time Machine external disk drive that I use. After that, I'll update the desktop machine and its Time Machine backup disk.
This should solve the physical theft problem. There are some precautions that you need to take though. For example, to be protected you must shutdown your laptop. When the laptop enters sleep mode, the hard drive remains "open". It would be nice to "lock" the hard drive when entering sleep mode, but I guess that it would require more support from Apple to do that. This is a problem for the laptop. I usually shutdown my desktop everyday when I leave the office. I do hope to see a lock-on-sleep feature in a future release.
But so far I'm very happy with this solution. Recommended.
Of course, I still have to worry about non-physical theft. People could still hack into my servers, or even hack into my desktop/laptop while they are running. But its a step.
The servers run with minimal services, and with a firewall active. I still haven't made the jump to a full SELinux enabled system, though. I do have a minimal port-knocking system for ssh connections, but its still experimental and only covers two of the ten servers I manage.
Also, some less secure services still share hosts with other higher security services. This is legacy from a time when I had less servers, and splitting them was not an option. My experiments with OpenVZ should provide an even better solution for this problem.
Small company, so small steps.
I've switched providers of OpenID. I was using ClaimID, but now I'm using MyOpenID.
The anti-pishing features are great, specially the personal icon feature. It basically sets a cookie on your browser, with a picture URL, and shows you that picture on the login page. If you don't see the picture, then the site didn't get the cookie, and the URL is probably fake. Simple and effective.
I've also gained OpenID 2.0 and XRDS support, which is nice.
And given that I was already using simplicidade.org as my identifier, I only had to update the <link>'s on that page to point to my new provider.
OpenID delegation FTW...
Last year, I was amazed with the power of Cappuccino when they showed off a Keynote.app clone written entirely with JavaScript.
The 280 North gang released version 0.7 this week, and inside there is a new tool that made my jaw drop. The nib2cib tool allows you to design your application with the gorgeous Apple Interface Builder, and then translate the resulting nib/xib into a cib that your JavaScript app can use directly.
It even supports Target/Actions and Outlets...
I'm not a JavaScript applications developer, but I find this truly impressive.
Marcus started it, Tim teased me. I was bitten so many times by this that I had to take a stab at it.
Following Tim's leads, I checked that the pod2man was producing proper nroff, with a \- for each -. It was. I tried to understand the groff tmac files, but I think we have here the first real proof that there are aliens out there, and they speak wonderful languages...
Anyway, we turned to Google and after a bit of digging we ended up at the groff CVS and a recent change (rev 1.39), just 4 months old so recent enough not to be included with Mac OS X. The description was promising:
tmac/an-old.tmac, tmac/doc.tmac: For -Tutf8, map -, -, ', and ` conservatively to ASCII for the sake of easy cut and paste.
The doc.tmac is important. When pod2man calls nroff, it asks for the an package. The an.tmac basically includes the andoc.tman and that one includes the doc.tman package.
At first I took the diff and tried to blindly apply it to the local doc.tman file. I don't speak alien, so although nroff didn't complain after my changes, it also keep on using the unicode hyphen symbol.
So I've downloaded the latest groff package (1.20.1) and did:
tar zxf groff-1.20.1.tar.gz
cd groff-1.20.1
./configure --prefix=$HOME/bin/groff-1.20.1 \
--with-appresdir=/tmp/gxditview
make -j 4
make install
You now have your own local groff install, including a brand new nroff.
To test it, I run:
perldoc -n ~/bin/groff-1.20.1/bin/nroff local::lib
Copy and paste something in there with hyphens, like my nemesis --bootstrap, and you should see that your hyphens stay in glorious ASCII, no more of that unicode mumbo-jumbo.
So stick this into your .bashrc:
alias perldoc='/usr/bin/perldoc -n ~/bin/groff-1.20.1/bin/nroff'
And live long and prosper.
Maybe it is possible to take the changes and port them successfully to groff 1.19.2, but I couldn't do it. If you do speak alien and you do port them to the groff shipped with Mac OS X 10.5, leave me a comment. Sticking a new doc.tmac in the `site_tmac/´ directory is a lot simpler than installing groff.
Update: the PROBLEMS file (kudos to this thread where you can follow the whole argument with the same problem in Linux man pages) that is included with groff mentions this problem:
- The UTF-8 output of grotty has strange characters for the minus, the hyphen, and the right quote. Why?
The used Unicode characters (U+2212 for the minus sign and U+2010 for the hyphen) are the correct ones, but many programs can't search them properly. The same is true for the right quote (U+201D). To map those characters back to the ASCII characters, insert the following code snippet into the `troffrc' configuration file:
.if '\*[.T]'utf8' \{\ . char \- \N'45' . char - \N'45' . char ' \N'39' .\}
If you stick the above code into /usr/lib/groff/site-tmac/troffrc the output will be ASCII, even with the default Mac OS X groff, but the perldoc output starts with a couple of blank pages and a warning:
<standard input>:138: warning: can't find font `CW'
So compiling groff is still the best solution.
I have a long standing love/hate relationship with package managers.
On one side, you have access to most of the software out there already compiled (presumably by someone who knows and uses the software and therefore is able to choose the proper, most useful, configuration options) and with all the administrative bits (startup scripts, example configuration files) in the "right" place (usually dictated by some standard like the LSB).
On the other all the package managers that I know of (and this is really a cry for help, please tell me of exceptions to this rule) have a Highlander-fetish with regards with package versions: there can be only one.
At any point in time, you can have one and only one version of a package installed it seems. If I have two applications running on some server, and you tested one of them with version X of the package P, and the other with version Y, you cannot have both versions installed at the same time. You have to pick the latest one and hope that backwards compatibility was not lost.
Most people with setups larger than mine that I talk to about this just tell me that "oh, you should split your applications on different servers, easier to manage, profile and tune". That's true, but most small mom-and-pop business don't have or don't want to spend capital to work around limitations on package managers.
There is also a good argument to be made for security. Keeping old versions around and in use is a security risk if the newest version was released to fix a security problems. I acknowledge this whole heartedly, but still, sometimes you know that you are using and old buddy version, but you still need to keep it running for some time, either because you evaluated the security problems and they don't apply to your configuration or because you need more time to test with the new version. We should be aware of the dangers you put yourselves in when you ignore upgrades like that, but you shouldn't be ruled by fear also. Analyze, weight your options, decide. Be rational.
One clean solution is a containers package like OpenVZ or FreeBSD jails or Solaris Zones: one kernel per server, several virtual servers. I admit that I strongly prefer this type of container-based virtualization solutions to the big ones that require processor support for decent speed, like VMWare, Xen or Parallels. I have a strong distaste for waste, and having multiple kernels running on the same metal, although extremely useful in some scenarios, is very wasteful of resources in the general case.
So although I just got a server at the office to have a second round of OpenVZ tests (and I'll probably use it in production for all my servers if I'm happy with them), I still believe that all of this is a big blanket over bad package managers.
My ideal package manager would create a base directory somewhere, lets say /p, and would create a set of directories, taking in account architecture, package name, and package version. For example, you could have perl 5.8.9 and perl 5.10 like this:
/p/i386/perl/5.8.8/{bin,lib,...}/p/i386/perl/5.10/{bin,lib,...}/p/x86_64/perl/5.10/{bin,lib,...}Also, you could keep the notion of latest using: /p/i386/perl/latest as a symbolic link to /p/i386/perl/5.10. This way other packages can require any version of perl or a specific version of perl.
The PATH environment would be tailored to the specific versions of each package you want. Just include the proper bin/ of the specific version you want. A global /p/${arch}/bin/ could be setup with symbolic links to the package/latest/bin/ files.
Clearly the solution of using OpenVZ is easier to manage today, no need to find or build a package manager like this, but still, I would really like to see it sometime.
For some jobs, you need to quickly resolve large amounts of DNS queries.
The AnyEvent::DNS module allows you to resolve DNS queries fast and in parallel.
To test this, I wrote a simple command line tool to check XMPP SRV records of a list of domains. Both server-to-server and client-to-server records will be checked and results printed out. All queries will be made in parallel.
The code is at my Ironman repository. Click the "Raw" link to download (sorry, no direct link, GitHub lacks permalinks to the latest raw version of a file).
I stop following a bunch of people on Twitter, and I've stopped using any kind of real-time Twitter client. Its an amazing waste of time.
My new relation with Twitter can be summed up like this:
@pedromelo: this allows me to read responses or comments about such links in my RSS reader, when I feel like it;There. Twitter off.
Are you ready to be an Iron Man? Join the challenge and find out! (what is the meaning of this little man?)
