The Known Plaintext blog has a pretty interesting high-level article called Ten Commandments of Data Destruction, which gives some advice on how to handle destruction of data on hard drives or USB thumb drives (e.g. if you want to sell them on eBay)... While most of the stuff is good advice, there's one thing in there which is certainly not a good idea: "format your hard drive before giving it to the recycler"! That will usually not help at all! Don't ever think that formatting will really erase your data! Using simple, and widely-available tools everybody could restore data from such a formatted drive, even without requiring any costly equipment. If you absolutely must sell or give away an old hard drive (physical destruction is always better!), wipe it with a Gutmann-style tool, such as wipe(1), or shred(1). Oh, and apply the tools to the raw partitions (e.g. /dev/hda) after booting from a live CD. Wiping single files on a mounted file system might not yield the expected results on some (journalled) file systems, because they are caching stuff etc... The follow-up article presents some further ideas, e.g. an acid bath for your hard drive. It also mentions that simply breaking the read/write head or the motor of the disk might not suffice, forensics labs could replace those parts successfully... David Bianco makes a very good point about data on company laptops (especially so if you consider the alarmingly high rate of "laptop theft, xxx million data records lost"-type news stories): "don't put the freakin' data on the laptop in the first place!". (via Jesse Kornblum)

There are interesting developments afoot, complete with Ubuntu conspiracy theories on debian-python. Since I’m working on a couple of Python packages, a new policy has been announced. The python policy has for a long time been inadequate. Come python upgrades practically all python packages needed updates. So I am glad we have something like python-support now. The unfortunate issue is that Ubuntu uses python-central to do this. So having two ways of doing the same thing is a little confusing. The bigger issue though is how the new policy isn’t stable. New X?-Python- control fields were added and now, they look like they’re being taken out. Much to the frustration of some. Oh well, I’m going to keep watching until the dust settles. That means I’m in no rush with the Python policy transition; so don’t worry, be happy.

This Wednesday I'm heading out to Chicago to visit RailsConf. The full schedule has now been posted, and it looks like a pretty absorbing affair.It amuses me that US-based conferences often have evening sessions timetabled. In Europe, I've always preferred to leave evenings empty so people can eat, drink and socialise. But in big city hotel-land, I can understand the appeal of timetabling more of the day.Here's a selection of the talks I'm most interested in hearing: Internationalizing Rails (almost the number one question we got asked about Rails when we taught our tutorial at XTech), anything related to testing, Rails Application Optimization Techniques and Tools, Rails Deployment. Oh, and some guy's talking about his work at the BBC.I've just finished writing an article for IBM developerWorks introducing Rails to DB2 users. (I had surprisingly little problem getting DB2 up and running in a matter of minutes on my Ubuntu box.) IBM's DB2 integration for Rails is a great development, and it's nice to see them pushing forward with Rails as a platform. I'm hoping they'll post the article up before RailsConf starts.
Given a bit more hacking time, I'll be intrigued to see how DB2's XML support can play with Rails.I'll be staying at the conference hotel, and am very interested in meeting up with anyone building Rails apps of a decent scale, or looking for a project to work on. Do drop me an email.

xen-tools 2.0b1 released. Please test and let me know what breaks. After so much work, so many bugs, and so many fixes I’m reluctant to go straight from 1.6 -> 2.0, so a 2.0b1 release is in order. Changes:

• Support for arbitary hook scripts.
• Improved command completion code.
• Better handling of errors.
• The ability to allow multiple IP addresses for xen guests.
• Possible to use “sparse” vs. “full” disk images.
• Parameterised Xen configuration files (via Text::Template.)
• Better documentation (?)
• More robust passwd + shadow file handling.
• Several installation methods; debootstrap, rpmstrap, copy, and tarfiles.

Probably more that I’ve forgotten about. If I hear positive feedback expect a real release and upload to Sid this week. If not .. whenever I get round to it.

Many advances have been made in agile software development. Frameworks such as Ruby on Rails embody agile principles by making software easy to write, easy to test, and above all, easy to change.If only we could say the same for the infrastructure on which we develop and deploy web applications. Not every application can be a Rails one, especially where it's been up and running for years. The systems we deploy on often rely on configuration files scattered all over the filesystem, and can be complex results of years of change.By extension, the systems we develop on often don't exactly mirror where we deploy. If we're lucky and careful, then we have a staging server which mirrors the live environment, but that's not too much of an advantage. Among other things, we need ways to evolve and refactor the live environment, and have our development environments easily track that.I'd like to call such an environment "agile infrastructure". Infrastructure that doesn't hamper developers, and allows live configurations to change and evolve. Infrastructure that allows new things to be tried with minimum cost, and can provide the best information possible to help future planning.Tools enable techniques, of course. It's a lot easier to be agile if you're programming in Rails rather than plain old PHP. So what are the tools enabling agile infrastructure?
Techniques I've found usefulWhile there's a long way to go, I'd like to describe some of the techniques I've been using to help create a flexible environment for developing a sizeable PHP/MySQL application.Operating systemAn operating system must be easy to bring into a known state with minimum interference. For this, I've found Ubuntu or Debian to be an ideal choice. Two of the main reasons include the constancy of stable releases and the fact that it's rare you need to stray outside the distribution's servers to get the software you need.DeploymentDeploying an application shouldn't break the cleanliness of your OS build. I prefer to package deployed applications into .deb files. This enables me to build on several advantages of the package management system:

• configuration file handling: deployed machines can keep individual config in /etc, which is preserved over software update.
• no random state: you know for sure exactly the state of the deployed application, no random files left hanging around.
• natural workflow: packages take a little bit of effort to build and deploy, which means it focuses developers on getting them right. If things do go wrong, it's very easy to roll back one version.

Source controlThe case for source control, thankfully, doesn't need making these days. Yet not every source control system is created equal. Developers shouldn't be constrained by source control, it should be cheap and easy to try new ideas and merge these in later.Not only cheap branching, but also easy merging, is required to keep development agile while still retaining the benefits of source control. Many people flock to Subversion these days, predominantly because it fixes some of CVS' more egregious misfeatures. However, merging can still be pretty difficult in Subversion.I prefer to use a system allowing easy merging, such as svk or bazaar. Because so many of us use laptops these days, disconnected operation is also a huge boon. Bazaar-NG offers both repository-oriented and completely decentralized operation, giving the best of both worlds. It also wins the competition for least setup overhead.VirtualizationPreviously a high-powered technology, cheap virtualization is now with us. Many identical virtual machines can be quickly created to enable testing and experimentation. Deployment to virtual machines can enable hardware independence for applications, reducing another big headache.Large organisations have it within their reach to bring new hardware online easily, and have invested much in management systems for it. Virtualization brings this in reach of small and one-man development teams.Desktop-based virtualizationSystems such as VMWare and Parallels untether developers from their desks. I use the OS X desktop daily for its productivity software, but an Ubuntu virtual machine for a large proportion of development work. A simple keypress lets me flick between the two. The advantages of multiple desktops to hand for web development are well known. (In fact, thanks to WINE and IES4Linux I can run Internet Explorer cheaply too from the same virtual machine).
Xen virtualizationAfter the initial novelty wears off, one of the most tedious tasks in the world is bringing new machines online. Combined with the tendency development environments have to get crufty as new ideas and tools are tried out, this makes for increasing disparity between the development and deployment environments.Wouldn't it be nice just to take a clean machine off the shelf, check out the source, and pick up again? Using Xen for Linux, this cheap virtualization is possible.Sadly, Xen isn't yet a packaged part of Ubuntu, but getting it up and running on Ubuntu Dapper isn't too hard. Warning: here's where things get pretty deep. Skip this bit if you're not interested in the nitty-gritty.I followed these steps:

• Followed instructions in the Ubuntu wiki to get the first domain (vm) up and running
  
• Installed the xen-tools package, which provides wrappers for easily creating virtual machines
• Adjusted some of the xen-tools configuration (/etc/xen-tools/hook.d/20-setup-apt) to set up for Ubuntu rather than Debian
• Once the virtual machine was made, adjusted its config to allow for the kernel initrd and configure the network bridge I was using
  

Getting over the DNS mountainIf you want it to be easy to bring new virtual machines up and down, you need to adopt a different approach to managing your DNS. You need to know how to predictably connect to a virtual machine. Yet it's going to get very boring and error prone to manage the IP address space manually in your DNS, or even to map the MAC addresses of your virtual machines in your DHCP configuration.
Help is at hand in the form of mDNS (also known as Rendezvous / Bonjour / ZeroConf). In the host machine, and in each virtual machine, I ensured the avahi-daemon and avahi-utils packages were installed, providing mDNS services. (You should also check that mdns is present in the hosts entry of /etc/nsswitch.conf).What all this does is allow the machines (virtual or otherwise) on the network to resolve names using mDNS. So if I create 3 VMs, alpha, beta and gamma, I can access these right away using the hostnames alpha.local, beta.local and gamma.local.Hey presto! Easily make machines appear and disappear without any need for sysadmin involvement. All the extra steps to add avahi installation can be easily scripted with xen-tools, to reduce the number of commands needed to birth a new machine to one.With this ease of creating new machines, it's much more straightforward to experiment with server topology and conduct experiments on server environments.ConclusionAgile development is necessarily constrained by the infrastructure on which it is conducted. The infrastructure itself is constrained by the tools and platforms of choice.By appropriate tool choice we can reduce the commitment and overhead of infrastructure. This enables developers to get on with the job they do best, and makes experimentation and evolution of infrastructure much simpler.When programming, it's dangerous to fall in love with your code, as the best solution may often involve throwing half of it away. The same hazard exists with infrastructure, with bizarre and awkward effects propagating back into code and operations. Get yourself a low commitment, agile environment, and you'll be able to keep up with the pace. 

Always a tinkerer and an explorer, I've known I wanted to self-host a blog for some time. Blog hosting sites have their pluses, but I couldn't resist making something distinctively mine with cool technology like the Rails-based Typo. Besides, I couldn't be outdone by my wife, who has for months now kept a successful knitting blog. The time has come. Syn.theti.ca will include ideas about programming at work and play, Debian development, home-based learning, kids and family, or whatever else strikes my fancy or seems noteworthy at the time. No lofty goals, in other words. Just a place to collect my thoughts and connect up to the blogosphere.

Programming, windows style
I'm now in the thick of a bunch of win32 programming at my Honeywell part-time job. I don't mind it that much, but I continue to be amazed that Microsoft's IDE is still the one used most often. The autocompletion is nice, but that's about the only good thing about it. I am continually annoyed that the IDE doesn't know which definition of a function I want to use, and only seems to pop up it's hints when it decides. Add this to the fact that most win32 libraries aren't apparently setup in a way so you can put their source in the repository, and I have a lot of admin work which I'm not particularly thrilled to do. 10% programming, 90% random crap. I'm beginning to understand why the average lines of code per day is so low. I can't really complain that much though, I knew the tools we'd be using when I accepted the job.

Programming, rails style
I have been working with Ruby on Rails lately, mostly to make some new web applications which aren't released yet. Things which are possibly in the works:

• MoneyDelta - credit card and savings balance tracker - figures out how much money you are making (or losing) each day based on how the interest is actually calculated. In the end it will probably have a little graph and possibly small things you can do in order to avoid interest and how much you would save in the long run.


• DeadSimpleCMS - CMS built mostly for Diana's use. It lets you specify layouts (not done yet) and content which goes into the layouts. In a very very early stage of development, but it is actually live on a site right now. As the name would imply, the point is to be very simple.


• Gathr - scholarly conference management software. Accepts papers, assigns reviewers based on degrees of connection to avoid conflicts of interest, generally tries to make the whole conference thing easier.

I also have a couple of smaller applications which won't really go anywhere, and an internal application upgrade from php. I really enjoy building web applications in the Rails framework, and I have honed my skills at Ruby enough that I actually use it for small scripts when I get frustrated with bash. I tend to do my Ruby Coding in TextMate and with Locomotive on the iBook, although I may do some on the Debian machine soon.

Over the past few weeks, Chris Ball and I have been working with the GNOME Foundation on a program to promote the participation of women in GNOME-related development. We’ve just launched today and we’re really excited—check out the press release and the website! More specifically, the GNOME Foundation is offering USD$9000 to female students in order to promote the participation of women in GNOME-related development. The money originates from GNOME’s participation in the Google “Summer of Code” program, for which GNOME developers will mentor 20 students working throughout the northern summer on GNOME-related projects. This year GNOME received 181 applications to Google’s program, yet none were from women. The GNOME Foundation has therefore chosen to reinvest Google’s contribution into a new program designed to increase the participation of women in GNOME. If you’re interested and eligible, visit the program website and fill out the application form! If you don’t want to apply (or aren’t eligible) but would like to help out, the best way to do this is to tell others about the program and/or put up our poster, designed by the ever-awesome Mairin Duffy. C’mon people, spread the word and let’s make this program ROCK! Update: There are articles up on NewsForge, LWN, Slashdot, and LinuxFR.

One of my packages, the Linux kernel's userland support tools for the Network Block Device was chosen by Ubuntu developers to be part of their 'main'. For those not very comfortable with Ubuntu: the "main" part is their idea of "this is what we support". Everything in main is free software and supported; things that are still free software but are not supported yet, are moved to their "universe" instead. Most Debian packages live in Ubuntu's "universe"; only the desktop environments that they support and their dependencies are part of Ubuntu's "main" section. Occasionally, I was told that the nbd source packages were moved to main because ltsp declares a Depends: relationship on them, and it was decided that the ltsp packages should be part of main. Personally, I don't use Ubuntu (though I've installed it a few times in the past, being the curious software geek that I am). As such, I don't really follow their development very closely, being more focused on Debian unstable instead. This would normally not be a problem, except that I do care that my packages are in a good state when they are released by someone, whether that someone is Debian, Ubuntu, or anyone else. What triggers this post is the fact that Ubuntu has shipped Dapper with nbd 1:2.8.3-1, with a context of this changelog entry:

nbd (1:2.8.3-2) unstable; urgency=low
  * Steal patch from CVS for nbd-server.c to make children exit when they
    finish serving, rather than having them loop over "Help, I can't accept()
    anymore!". Closes: #350357.
 
 -- Wouter Verhelst <wouter@debian.org>  Tue, 31 Jan 2006 11:17:25 +0100

#350357 is a bug of severity important, and rightly so. From the bug report:

Jan 28 14:42:58 caradoc last message repeated 1190456 times
Jan 28 14:43:59 caradoc last message repeated 2478818 times

An infinite loop producing an error message, a bug which triggers when a client disconnects. Have two clients connect, then disconnect, and you have a syslog being filled up with spurious error messages, filling your entire disk in a few hours or days. It may be too late to update dapper now; however, had I been asked after #350357 was filed whether it would be a good idea to ship with this specific version of nbd, I would have said "no", and this horribly buggy version of nbd wouldn't be in a released version of Ubuntu. And since #350357 was filed a few days before the above log entry, in January, I cannot believe that it would've been too late. Of course, if anyone from Ubuntu is reading this and can tell me that yes, it is still possible to update nbd in Dapper, then by all means, please do so. Oh, and don't forget to update edgy while you're at it :-) That being said, I'm hoping something can be done to avoid this kind of SNAFUs from occurring again. Ubuntu could talk to me for those packages they care about, which (according to their policy and the status of nbd in their distribution) includes nbd. As it is, Ubuntu is just a large institution that happens to redistribute parts of Debian. I'm getting more feedback from the guy doin the 'nbd-server' port in FreeBSD than I'm getting from Ubuntu—and that FreeBSD guy only once or twice sent me an email...

In two weeks, there will againbe a codefestin Akihabara, Tokyo.I'll hopefully be attending theevent.Last year, I fixed quite a few bugs on pbuilder,which kind of speeded up pbuilder development and heated upthe momentum for cowdancer.This year, I will hopefully have some MacBookdebian-installer, emacs-muse Japanese PDF support, andLVM-snapshot support for pbuilder.Maybe.

Yesterday night, without all the stares and ceremony I would have liked for such an important moment (but, hell, it was ~500m away of the Oaxtepec entrance!), I gave the three-finger-salute and rebooted moe.mexico.debconf.org. After some seconds, I started unplugging the six Ethernet cables that this noble machine held together forming Debconf6's connection to the world (thanks, Punk0 and Jyr, for working with this bunch of crazy and nervous people, five days nonstop until the wireless link between homer and moe worked fine and reliably, and still talking to us!) and ran back to the hacklab to finish packing the van with the lent equipment.
Ok, so now moe is back in its place, my office (believe it or not, yes, today I came back to work). Its identity has been restored to mosca.iiec.unam.mx, and moe's ancient but still working hard drive now sits idly where it belongs, in my desktop drawer. I am back in my place again, tired as I can be, but really happy of having ~250 of my closest friends visit my country. Besides, I am very happy that, AFAIK, this Debconf is the one that most people spend some time on an after-trip.
I am really happy with what we did at Debconf, even given all the problems we originally had. And... Well, I eagerly wait for Debconf7, where I expect to spend much more time attending talks - but most importantly, hanging out with you, having nice, fun talks/mao/whatnot.
PS: Alfie, you are severly mentally disturbed!

Debian is love. After my scream for help a couple of days ago, and after a mountain of hard work, things are just running. No, we are not -by far- free of incidents, and it would be foolish to expect it to be so, but we are working nicely. And by the way, thank you, I have been receiving the largest amount of hugs ever, and believe me, each of them has been important. We are not over yet. At least two more days of work, and onem more day of taking all the shop back home, and that only means that the next step in the round will start: Handing back all the lent equipment, doing the travel reimbursements, closing all of our accounting stuff... And, of course, get the ball rolling towards Debconf 7. So... Well, six days into Debconf, I am currently sitting in the third talk I have opportunity to attend (of course, I have missed most of the ones I was interested in - Video team, I trust you to make a brilliant end product ;-) ), Nadezhda is printing 150 beautiful new T-shirts Pixelgirl designed a couple of days ago, and... Trust me, I still have a stressed face - but I am finally enjoying every minute of this fscking mess we decided to put up. Thank you all, folks. I am in Cristoph Berg's talk about reworking NM - And this comes very good to wrap up my post. Debian is much, much more than technical work. It is a social club. I love this social club. Just sitting here makes long months of work really worth it. A great hug back to you all!

Joey Hess blogs about possible dangerous ways to exploit the daylight savings time. Well, for the tenth year in a row (if I am not mistaken), we central-Mexicans can proudly announce we are GMT-5. When I was a kid, we were always told that daylight savings are a very important way to save energy in non-tropical areas, such as the North-Western states, USA, Canada and Europe. We understood that, as tropical beings, we didn't have to worry about that, as it would have neglegible effects for us.
Ten years (eleven?) ago, this changed, and we became first-class world citizens, together with the emotion of shifting the clock's hands twice a year. Of course, we all did stupid things once or thrice - The first time we got back to GMT-6, I moved to GMT-4 instead. We were laughing at the fools who forgot to move the watch. I went to the movies with Nadezhda, and was confronted by a less-than-amused clerk that had to explain the same to too many people along the day. At least he smiled when he noticed we were stupider than most.
Well, today I am a big fan of daylight savings. I simply like having sunlight up to 20:00, sometimes even 21:00 - But I have reversed the old logic I was taught at school. We Mexicans have very little variation in our clocks - We go from maybe 11 to maybe 13 hours of daylight comparing Summer and Winter. Ok, make it 10 and 14, to make it sound more dramatic. Having the sun raise at 6AM makes sense, no matter what time of year it is. Most electricity is spent in the early night (8-10PM)... So it makes a lot of sense. Even for the people in the USA, maybe even Canada, and most of Europe. But...
Why do Nordic countries adhere to daylight savings? I mean... You vary from 4 to 20 hours of sunlight a day - What difference does one hour make anyway? Why follow the hassle we all regular humans have to go through? I can't imagine people in Narvik and Rovaniemi trying to squeeze that little glimpse of sun they have during the winter, and trying to align their sleeping time to the exact the sun is only half-visible in Summer.

Hi! This is Comas, the conference management system we all know and love! Perhaps you remember me from /www.consol.org.mx/">/www.consol.org.mx/">CONSOL 2004 and 2005, Debconf 5 and 6, CICOL, Seminario Globalizaci n, Conocimiento y Desarrollo or other such great conferences! Well, it is a pleasure for me to announce I am moving.
That's right - My developers have felt too constrained by CVS to keep being merry and productive, and decided to move away from it and to Subversion. If you are tracking my development history, you should have noticed a new file in my base CVS directory, called DONT_USE_THIS_REPOSITORY_ANYMORE. I will reproduce it here following Gunnar's wishes, and hoping it is useful to you.

PLEASE DON'T USE THIS REPOSITORY ANYMORE! Just in the meantime, while we migrate our current installations to point to the correct server, while our users take note, and while the kind GBorg admins lock down this project: PLEASE DON'T USE THIS REPOSITORY. WE HAVE MOVED. The Comas project will no longer be hosted at GBorg - We are moving to Debian's Alioth.
Comas' webpage (although it is still ugly :) ) is still the same as always. The repository will no longer be handled through CVS - We switched to Subversion. Don't worry, the usage is basically the same. You can use anonymous access to get the Subversion tree. If you want to participate in the project, register at Alioth and ask us for commit access. You can also use the very nice SVN Web interface, which allows you to look at each of the files, view the changes, and even subscribe to the Comas RSS feeds! Development goes on. Stay tuned! Greetings, - Gunnar Wolf

Of course, as in any migration, there is still a lot of things to do. Mail the other contributors and interested people notifying them of the move. Migrate (and check the validity of) any tickets we have in the old site. Point all the places where there is Comas-related information to the new repository. Close the existing project page at GBorg. Sanely re-structure the repository in a more standard and functional way (and hope it does not break current installations ;-) ). Rework the documentation that has been neglected in the last months. Rework the bits of logic that never smelt very good but -as a dead rat- now positively stink. Fixe the things that will eventually stink as well... Anyway, I'm sure this will speed up my growth!
I am very excited on which way my dear authors will continue to push me - I know I'm quite a lousy program for many things, and I know there is a lot for me to learn until I am a military-grade conference management system - But my many parents have written me with deep love, and I understand they had to write hastily parts of my code. I understand their mistakes, but I hope they make them go away soon.

Over one month ago, I truly hoped an evasive network misbehavior issue was solved. In the institute, we had a strange situation which caused a (seemingly random) stack of switches to go out to lunch and leave one of the floors without network access until it decided to restore itself (usually power-cycling it was not enough). The equipment, ten 4200 SuperStack switches, is new, we got it ~September, so I expected 3Com to give me at least some support on the issue. The behavior was apparently random, and I could not track it down, only (thanks to the very nice Cacti) prove it existed.
December 5 was terrible. The whole building's network refused to work. Switches were able to reply to my pings for no more than a minute after booting before they got flooded with "Spanning Tree CTRL MAC PAUSE: Quanta 65535" (according to another great tool, the Ethereal protocol analyzer).
I had been bugging the support people at 3Com for at least three weeks before this incident, they kept promising they would come soon to help us track the cause of the ellusive problem - We threatened to send the switches back and pursue reimbursement through whatever means we could (we had much better stability and performance with our old 10Mbps hubs, so my boss insisted on replacing them), so we got them to come. The answer they gave me? Upgrade your firmware to version 2.50 (not available at their website, of course) and disable spanning tree functionality at the switches.
I have to admit the big problem immediately ceased. This is not to say I was pleased with the response time or with the switches' software quality, but at least we could work.
Happily, ~7 weeks passed by with no major outages (although with a few small ones).
Yesterday, we got back the complete chaotic conditions. This time, though, I was able to get a good and useful tcpdump snapshot, passed it through Ethereal, and actually got something interesting (available to whoever requests it to me if it sounds interesting). In short: Something happens that confuses a switch (I guess it's a faulty NIC), and makes it request to all of the neighbouring switches (via spanning tree protocol - Yes, it's disabled, but still) for their complete ARP tables. But somehow, this noise or whatever keeps confusing it, so the spanning tree requests start repeating every two seconds for slightly over one minute. Then, the same switch which requested this information gets tired of too many ARP tables being thrown at it, and sends out a storm of packets (one each 0.04 seconds) asking every other switch _not_ to send updates anymore. This is broadcasted to all of each of the switches' ports, and the network dies.
My grudge against 3Com is: How come this frigging noise (at least that's what I assume it to be) on one of the ports kill all of the network? If a switch is supposed to be smart, would it be too much for it just to disable the misbehaving port?
Anyway... One and a half days went down the drain trying to find the cause for the problem, sending the report to the 3Com guy (who is very nice in person, yes, but that's by far not enough!), running up and down the stairs to reset different switches, lock down on the source of distress... And as my 3Com contact was busy with another client (who presumably had not yet given them money), I never got a call back from them.
All my good intentions to spend a nice quiet time coding for three projects we currently need to have ready soon (one of them is in production and many of you have used, my dear Comas conference management system, but requires heavy tinkering to be able to extend it) were stuck at that: Good intentions.
I seem to have locked down the problem in one of three computers (that is, network seems stable again once I disconnected them). I insist it must be a faulty NIC. My boss bets it's an ber-contaminated Windows machine. My boss' boss insists we should get the switches double-grounded just to be sure that's not the reason for failure. I am tired, bad mooded, and -again- bored you to death with a too-long blog entry.
Blame it all on 3Com.

I'm at Where 2.0 2006 this week, and I've got to say that from the perspective of this conference room it's like geo-data is the most important development on the Web since the <img> tag. I'm getting a little tired of seeing Google Maps mashups -- although I'm hoping to see someone who does a mashup of Google Maps on Google Maps. Or Yahoo Maps on Google Maps. Overlay them, so you can click a link on Google Maps and get a Google Map of that particular place. Over and over and over forever.

When I bought notebook I had to find out some use for previous box. It was great opportunity to test etch installer (and my Polish translation at the same time) so I did it several times using miscellaneous settings. Eventually it was time to find out some real use for this box. I decided to try out some non-Linux port of Debian. The most stable and actively developed seemed to be kFreeBSD.
I installed it about month ago. I must admit it works great despite some initial stability problems related to buggy mount, quickly workarounded with help from people from #gnu-kbsd channel. (thanks!)
I use it mainly as a backup machine and small www server, but since it handles it without a hitch I'm probably going to make it also print and Samba server.
I was sceptical to GNU userland used with non-Linux kernels, but admittedly we're getting closer and closer to the day when switching between kernels would be piece of cake ;)

(fenio@kfbsd)~#uptime
 15:36:57 up 21 days,  6:23,  1 user,  load average: 0.23, 0.08, 0.04
(fenio@kfbsd)~#

As you can see it works. It lays in one of my wardrobe, without the case and unplugged from any external devices. I couldn't remove graphic card due to some weird BIOS limits, so it has some PCI card worth less than the beer I'm drinking now ;)
Here's its photo. Sorry for quality, but I don't have any camera around, so it's made with my cellphone.

If someone wondered if non-Linux Debian ports are worth try, then I have to say YES, THEY ARE!
Using this opportunity I would like to thank everyone involved in their development. Keep up the good work!
Now it's time to give a try to Debian GNU/Hurd... have to start gathering the hardware for that ;)

OK, so Goole has finally released a first version of Google Earth for Linux (beta, of course). Well, maybe this time they really mean it when they say "beta"...

Here's some quick observations:

• Of course, it's not open source, you basically get a bunch of *.so files and an executable.
• It uses a bunch of open source software packages, though, e.g. libcurl, OpenSSL, libjpeg, libPNG, libtiff, libmng, zlib, Expat XML Parser, FreeImage, and a bunch of other things. All the licenses of those projects are contained in a README, though.
• The installer seems to be (based on) the Loki installer, at least a ~/.loki directory is created with some stuff in it.
• The maps cache, and some other files are stored in ~/.googleearth.
• The ~/.googleearth/crashlogs directory contains log files which are generated when the application crashes, and sent to Google upon the next restart of the application automatically. The README says that you should basically chmod 000 ~/.googleearth/crashlogs if you don't want that. They say these files don't contain personal information. I haven't seen one yet (didn't crash, yet), so I cannot tell if that's true.
• The EULA says that Google Earth will phone home (they call it "check for available updates to the Software"), and that you automatically agree to that when you use it: "By installing the Software, you agree to automatically request and receive Updates".
• When I start Google Earth, I get a popup window which tells me to install Bitstream Vera Sans fonts or things might look strange. No idea which fonts extactly they mean, I've got the Debian packages ttf-bitstream-vera, and ttf-dejavu, but the warning still appears.
• After Google Earth connects to the server(s) I get to see something resembling a globe, but not really what I (or Google possibly) expected. There's simply no textures for anything, I just see (broken) wireframes (see screenshot), but that's about it.

I'll have to play around with it a bit more, maybe it's an issue with the NVIDIA drivers or something. But as I don't have the source I can basically just make stupid guesses... (via Golem, and a bunch of other sites)

Charles DiBona: “We think that Google poses a threat to Microsoft long-term by offering an alternate platform for application development. But we also believe that Microsoft recognizes this threat and is investing appropriately in its own operations to counter it.”