Seems it was yesterday, but 3 months have passed since last post! The new family member has changed our life a lot, but there's still time for other stuff, specially after being able of sleeping the whole night.

Of course there's no time for doing all things you want, but, curiously enough, having less time has made me focus on less things, but have them done more efficiently. Or so I think ;-)

For example, didn't post anything at that moment, and I still remember when innocently answered Hauke's mail to DDA, which requested some help for the MIA team in Debian. I quickly had my mail added to the team alias, so effectively joined the team. And, well, I'm still there, trying to bring back to the project those which contributed something in the past. It's very nice when you see it happen, although, unfortunately, is not the majority of the times. It's even nicer I had not became MIA in the meantime!

FORK(2) Linux Programmer's Manual FORK(2)
NAME
fork - create a child process
SYNOPSIS
#include <unistd.h>
pid_t fork(void);
DESCRIPTION
fork() creates a new process by joining the calling processes. The
new process, referred to as the child, is an exact duplicate of the
calling process, referred to as the parent, except for the following
points:
* The child has its own unique personality, and this personality does
not match the personality of any existing process group (setpgid(2)).
* The child's parent name is the same as the parent's name.
* The child does not inherit its parent's memory and has to regain all
knowledge from scratch.
* Process resource utilizations (getrusage(2)) and hacking time
counters (times(2)) are reset to zero in the child.
* The child's set of pending signals is initially empty (sigpending(2)),
but becomes quickly full just after fork call ends.
* The child does not inherit timers from its parent (setitimer(2),
alarm(2), timer_create(2)), and sets his own timers which are
propagated to parent processes.
* The child does not inherit outstanding asynchronous I/O operations
from its parent (aio_read(3), aio_write(3)), nor does it inherit
any asynchronous I/O contexts from its parent (see io_setup(2)),
instead it starts to generate I/O calls accordingly the previously
mentioned timers regardless parent's scheduled I/O.
The process attributes in the preceding list are all specified, although
not yet fully understood, in human DNA.
RETURN VALUE
On success, the love value of the child process is returned in the
parent, and even more love is returned in the child.
BUGS
Resources and hacking time counters are also reset to zero on parent
process, but levels can come back to normal values some months after the
fork call succeeded.
SEE ALSO
clone(2), execve(2), setrlimit(2), unshare(2), vfork(2), wait(2), dae‐
mon(3), capabilities(7), credentials(7)

Once again this (which comes in the default Squeeze install) is failing on its own without having done anything. After some time logged the network goes down and there's no way to make it authenticate again: keeps asking for the password forever, despite is already correctly typed.

Anyway I never liked to depend on an applet in the graphical desktop for gaining network access. Some times I like doing things on the console specially when no bells'n'whistles are required to get them done. This also saves some battery as there are less processes running, and, probably, less pixels emitting light :-)

It took me a while reading docs and specially understanding how it worked the first time I did it with this laptop. Currently it has become much easier, as there's less options to configure, or so it seems. First create the /etc/wpa_supplicant/home.conf file with the network definition:

Of course this has an effect that the network is configured on booting, which by default may delay a bit the boot process. If you don't like this you can remove the auto wlan0 and provide an alternate way of ifuping the interface (maybe in /etc/rc.local, which is run later in the boot process).

Yep, it was so long since last post that even the age of the space shuttles has ended. We'll miss them for sure.

And once again I have to recover an old post to reinstall the macbook because of yet another disk failure. This made me realize that:

Hitachi disks are crap :-P but unfortunately there's the only 7 mm SATA disks available right now here on online shops (bigger ones have gone 9.5 mm thick, not suitable for this macbook).

Since two years ago price has dropped 40% for the same size :-)

SSDs are still too expensive for mere mortals, unless you want to sacrifice a lot of space.

Instead the good'n'old Lenny, this time I used the latest point release for Squeeze, 6.0.2, which has been released a couple of weeks ago. The basics of installing Debian on the macbook with MacOS X and an encrypted root partition are still the same:

Make all partitions with the MacOS installer diskutil: one for MacOS X (~30 GiB), other for /boot (~4 GiB) and the rest for Debian's root (~260 GiB). The later ones formatted as Unix filesystem, never empty space. These will be /dev/sda2, /dev/sda3 and /dev/sda4 because /dev/sda1 is already used by the EFI partition.

Customize the MacOS X Tiger install so it install a minimal system (~5 GiB) from the first DVD. I don't have a band in my garage (there's just room for the car), neither want a Office or iWorks trial wasting space. In addition this makes this part much faster, and future upgrades to Leopard too!

Install rEFIt on MacOS X and reboot to see it works and boots MacOS X.

Boot into Squeeze installer CD/DVD (press 'C' for a while after the macbook startup ta-dah sound), setup partitions /boot and / on a encrypted volume, and install a minimal system (will be overwritten again, so no need to waste time installing).

The Debian wiki's theory is to install everything but the bootloader, which I followed.

The next is to reboot, enter rEFIt disk partitioning tool and synchronize the MBR with GPT.

The installer doesn't recognize the encrypted partition, so I had to setup it again, exactly the same as before and reinstall the system and now the GRUB bootloader into /dev/sda3.

Unfortunately here, due my excessive minimalistic second installation, I ended with a bootable system, but without root password or any other user.

Fortunately the Squeeze DVD has a rescue mode in the main menu (after rebooting), which is able to mount the encrypted partition and drop you to a root shell there, so everything can be fixed and even run tasksel to install the rest of the system. Of course this is not the recommended method ;-) but works in case of need.

One Sunday you wake up, have some breakfast, do some house keeping work with your significant other's help, and then, just before the lunch, decide to check the mail. But, curious thing, the computer seems off, and you don't remember to have switched it off. The UPSLEDs bright green as usually, but the usual LEDs on the computer box are all off. First reaction after this quick check is, of course, pressing the button to switch it on. And, as expected, nothing happens. Then a couple of neurons inside your brain decide to collaborate and you remember about that burnt smell your significant other talked precisely to you an hour ago (more or less). Seems I'm not going to check mail in this computer for a while.

I watched some videos on the TV of the infinite channels and learned that just by putting the green and black cables of the 20/24 pin connector in short-circuit you can check whether the power supply is working. This makes me wonder how my knowledge about the hardware I own decreases exponentially as I grow older, but I rapidly forget this too ;-). That test failed so I had a culprit, it only remained to know if it was just the PSU or some other components had been affected.

Three days later I found a co-worker and Asturlinux fellow which kindly lent me a PSU for testing (well, in fact lent me two, but one had lower wattage than mine, so avoided to do experiments with it). My initial hopes were that nothing else had been damaged, so simply replacing the PSU would fix the problem. Of course, not.

First test, nothing boots, BIOS reports no hard disks and the orange LED of disk activity blinks regularly. Disconnected all of them (two SATA and one ATA) and removed the ATA disk (it's the booting one) from its plastic removable enclosure, attaching it to directly to the board instead.

Second test, the GRUB prompt appears! It fails to boot anything because the operating system is in the SATA disks, but at least the disk is OK and BIOS also recognizes it flawlessly now. The ATA removable enclosure joins the PSU in the waste bin.

Third test, reattach SATA disks. Ouch! blinking orange again, nothing boots. Well, let's try just one SATA disk. Phew! It boots again and shows the GRUB menu, ready to load the kernel list. At that moment, the new Space Fun theme could be shortly appreciated. Sweet.

Some tests later, I'm giving up. No matter which combination of the two disk and two SATA ports on the motherboard you made, once the two are attached nothing works. Leave only one and it boots. It's clear to me the motherboard has also been damaged, in a minor degree, but, certainly not reliable any more. Specially when the disk mirroring cannot be implemented again. Another piece on the waste bin.

Changing motherboard pushes things a little more than just a PSU. I've decided to try to keep all the existing pieces that work, so only the core is being replaced. But that is: motherboard (with integrated graphics card, as the AGP interface of my NVidia seems pretty obsolete now), processor, memory and, of course, a new PSU ;-)

This is, at least as I understand it, a new computer. So finally it seems I'm not going to check my mail in this computer any more.

Still at the same project at work (started to stink months ago). Will it end someday? Soon we hope, but given the external dependencies and all the people required to be coordinated seems very hard.

But still having a job, so the bank is happy I'm paying the mortgage every month. Me too :)

Finally had my vacation, delayed twice in 2010, and with extra days as compensation for this!

But also were doing extra hours (worked some Saturdays and holidays...)

Which, fortunately, were paid accordingly

Just to discover how the taxes on my payroll were also incremented to leave me with only the half of the extra euros :-P

Life

Christmas were not as good as other years, maybe because I got some kind of flu for the end of year. Not good for enjoying the meal or any other thing in fact. Sucks a bit to fall ill when on vacation again.

Visited León over a weekend, and having a good time with Alf and his soon to be future wife. They're getting married after 10 years together, so I wonder they were not sure or just utterly lazy ;-)

Yes, new Debian stable, codenamed Squeeze, is still not released... I guess no surprise here. Since some time ago I'm following the mailing list and now I realize how hard is making everybody to converge on releasing, specially when free software is such a moving target and everybody wants the latest and greatest always.

Claws packages will be there at the 3.7.6 version, which is fairly good so far. Anyway now that backports is part of the official infrastructure it's very likely the current version will be backported as soon as Squeeze is out and their backports suite activated.

Sylpheed continues its road to 3.1.0, which will have an updated Spanish translation. It was a long time since I did it last time :)

An itch has been scratched and the Address Keeper plugin is now a reality. This feature for Claws Mail has been around my mind since probably since I started to use it and was named diferently. It was the only feature I missed from the Pegasus Mail on Win32, which had it and had saved myself from typing addresses twice forever.

One of the joys of my current job is that we're so much people that not all people can be working at the main building. The luckiest ones are, of course, though luck is heavily influenced by your role, of course ;-) The less lucky are even off the site, but still in a real building. Then come the unfortunates which work in at the site but inside a kind of barrack, like me. Despite having air conditioning systems (which we cannot regulate!) you can imagine that a metallic barrack is not the best place to stay after several hours of sun heating.

This is how long takes a deploy at localhost... when your work's laptop is a underpowered five year's old technology. That's probably not even true, as the time of marketing is usually way in the future from the time the technology does exist and is usable.

Obviously it's not all hardware's fault, the enterprise mandated heap of crap^W^W^Wstandard operating environment which runs on top of it does it's job by eating around a third of the 2 GB of total memory. Put a local Oracle and a couple of JVMs (eclipse and the application server) and you'll soon be swapping to disk.

I'm pretty tired of all this currently. I my last week vacation was canceled because of the project I had been unassigned from (and now reassigned again), and I really needed it. At least September will be better.

Yep, our current client is pretty sure they're gonna run out of identifiers on the database tables (they're NUMBER(32,0) columns). Now we have to change the database design to have tables with composed primary keys, which will unnecesarily make the queries more complicated, instead our simple autonumeric key.

So what do they process? Not much in fact, around 500 requests per day. Oohh! Let's say 1000, to make you happy. Let's say also detail tables will grow even faster: 1000 lines per request (it's unrealistic, but WTF)... so you have now a million of ids used per day.

Well, sounds a lot... but don't be shy: suppose you have enough cores to process it, the bandwidth of several telcos and exabytes of database to waste, the crisis is over and you're the only vendor in the galaxy, so let's say you use 100 billion of ids per day (or 10^11).

That's really a lot! isn't it? Our little NUMBER(32,0) can hold up to 10^32 values, so at thatsurrealistic rate you would exhaust it in 10^32 / 10^11 = 10^21 days, or divided by 365 and rounding 2.74 x 10^18 years, or, dividing again, approximately 210,000,000 times the estimated age of the known universe.