• 1995: I installed a Red Hat distribution. It was crap mostly because of the RPM-hell, but better than MS-DOS or Windows 95, so I kept it.
• 1996: I installed Debian. No RPM-hell but nice apt-get. Loved it.
• 2004: My blood boiled after and entire afternoon trying to make a scanner work, which I knew was supported by SANE. Deleted the Debian and installed Mandriva. The scanner, and almost everything else, worked at once.
• 2009: After five years using and advocating Mandriva and making fun of the average Ubuntu user I switched to KUbuntu 9.04. Talk about consistency.

So, why?. Well, it's not like Ubuntu has been better all the time that Mandriva and I just keept resisting for brand loyalty; I've been testing almost every major Ubuntu release, and still found the current (at the time) Mandriva version superior. Superior for me means that more hardware was detected and configured to work, the KDE desktop was better configured and integrated (I don't use the lobotomized Gnome), and the Mandriva administration tools were superior.

But two weeks ago I tested KUbuntu 9.04 and found it superior. The hell froze. It was superior because:

o All the things that Mandriva never got really right on my Sony Vaio just worked on Ubuntu. This include:

• The suspend to disk and RAM (in Mandriva about 30% of the time the computer would never came back from suspend to RAM, and suspend to disk never worked.)
• The sound; Mandriva pulseaudio configuration would sometimes leave me without sound, usually when opening a flash video from Firefox or coming back from suspend to RAM. I fixed that killing pulseaudio and restarting the sound system, but it was a pain.
• The Firefox addons. Ubuntu uses an special Firefox extensions that install Flash, Java, and other things automatically the first time you need it. It shows a wizard and installs everything, like in Windows. With Mandriva you need to go chasing the plugins on the net and install them yourself, or fiddle with repositories. Ubuntu has some other user-friendly niceties like these, like the NVidia/ATI driver installer and configurator (envy-ng.)

o The speed. Holy cow, this thing is fast! It's not only much faster than Mandriva (much faster booting, faster desktop, much better user experience all around) is also much faster than previous Ubuntu versions.

There is only one thing I'll miss from Mandriva, and it's its awesome DrakConf. KUbuntu has a loosy collection of configuration programs under "System", some other things you're supossed to configure with KDE "SystemSettings" and some other things you are supossed to configure clicking on some taskbar icons, but Mandriva DrakConf got most of these under a single, user friendly GUI and it also got a lot more configuration modules than Ubuntu have.

So, Ubuntu users, you can mock me now. I'll not reply, as a penitence.

I found that on my system, using a compiled KDE 4 from the sources goes much better than Mandriva's provided packages. And since it's pretty easy to do, I'm writing an article detailing the steps. Back in 2004 I wrote an article about running a KDE 3 version compiled from CVS (in spanish that time). Since your distribution probably already have packages for KDE4 you could be wondering what are the advantages of compiling KDE4 over using the distro packages. These are:

• You can optimize the compilation for your target machine. This means that if you, for example, have a Dual Core 2 CPU you can instruct the GCC compiler to generate code specific to the features of your processor (like SSE and a lot of other things) that will make the binary run noticeably faster on your computer than the generic code compiled for Pentium.
• You'll always be on the cutting edge, having the very last KDE version. Of course this is both good and bad; it means you'll have always the latest features but you'll have too the latest bugs. My advice is to only install form sources when the current KDE version (4.1.0, 4.2.0, etc) is at least at beta stage.
• If you're a programmer and find a bug or want to implement some feature, you'll have the source code to it.
• You'll not depend on the options choosen by your distribution package maintainer.

[Read the rest of the article inside]

If somebody on the interwebs read my rant titled "Back to KDE3" he'll know that I was very interested in running KDE4 but could because of the general slowness and innestability of Plasma. Well, it seems that now I'll be able to finally run it. Some things have changed that have made KDE run pretty fast finally; read the article inside to find how I managed to do it.

En este artículo no se quiere hacer un recuento exhaustivo de cada aplicación que exista para el iPhone sino sólo las que el autor de la web y unos amiguetes encuentran más interesantes en cada categoría. Si tu encuentras alguna aplicación que consideras muy interesante escribe un email a juanjux+web@gmail.com o pon un comentario a éste artículo y si opino igual la añadiré a esta página.

Muchos programas de descargas de Internet, navegadores, y similares calculan el tiempo estimado para una descarga de varios archivos de la siguiente forma:

Tiempo restante = tiempo estimado para la descarga del que vaya a tardar más.

Y el tiempo de la descarga de cada fichero es:

Tiempo descarga = parte restante / velocidad por unidad de tiempo.

El problema de calcular el tiempo restante de una descarga múltiple de esta forma es que no tiene en cuenta que cuando un fichero termina normalmente su ancho de banda se reparte entre el resto de los archivos, por lo que la descarga de estos se acelera. Y cuando termina el segundo se acelera aún más... por lo que el tiempo inicial que da el programa generalmente suele ser bastante mayor del tiempo real para finalizar las descargas. En el programa "RapidSucker" que estoy haciendo poco a poco (le pondré una página en breve, aparte del cutreartículo anterior en la página) quería algo más realista, así que el módulo Calculador Casi Realista de Descargas que incluye hace:

1. Calcular tiempo restante para todos los ficheros y obtener el que terminará antes y el tiempo que falta para ello.
2. Calcular cuanto habrán avanzado la descarga el resto de ficheros cuando el primero haya terminado.
3. Y volver al primer paso, ya con los ficheros que quedan y teniendo en cuenta su avance, sumando cada vez el tiempo transcurrido al tiempo total.

En el código del RapidSucker se puede ver una implementación de ejemplo de esto, usando recursividad (y con alguna ñapa interna actualmente, todavía estoy prototipando), en los miembros calculatePendingTime y calculatePendingTimeRec de la clase RapidDownloader.