30 de noviembre de 2006

Como cambian las cosas....

(En primer lugar, gracias a los que contestaron el tema de los editores). Si bien en los últimos años Intel ha sido el hazmerreír en todo internet, las tornas en tan solo en el plazo de un año han cambiado tanto que casi da vértigo. El Core Duo de Intel supuso una mejora bestial con respecto a sus propios procesadores, pero tambien supuso una mejora - tanto en rendimiento como en consumo de energía - con respecto a AMD. La mejora de rendimiento fue especialmente grande, hasta el punto que se vaticinó en su día - y a día de hoy se ha comprobado que era cierto - que con una simple mejora de sus procesadores actuales AMD no podría volver a recuperar el liderazgo, tal y como suele ocurrir, sino que para competir tendría que renovar por fin el Opteron, un procesador que ha dado excelentes resultados durante los últimos años, pero que no puede durar siempre.

Y es que ya se están viendo pruebas del quad-core de AMD, y los resultados no podían ser más descorazonadores. El quad-core de Intel lo bate en virtualmente en todos los campos. Y los consumos de energía del AMD son ridículos, ridículamente grandes para un procesador que hace nada se caracterizaba precisamente por su bajo consumo de energía:



Cerca de 600 W. El Quad de Intel consume casi la mitad, y es más rápido. Y los dual core de Intel tambien están ganando sin ningún problema a los dual core de AMD. AMD se ha convertido en el Presscot, en esa CPU excesivamente caliente e ineficiente que necesita ventiladores gigantescos y ruidosos (el artículo dice que es de los sistemas más ruidoso que han tenido). Intel sin embargo ahora es ligero y veloz (y tiene drivers libres para sus chips gráficos, no como AMD y su ATI). Por supuesto el mercado sigue y las cosas cambiarán, pero es curioso la rapidez con la que algunas veces cambian.

26 de noviembre de 2006

¿Modelo de desarrollo chapuza? Ex-trabajadores de Vista dan pistas

Hace unos días, comenté un artículo magnífico sobre la inmensa, monumental chapuza que era el menú de apagar Windows Vista, con sus nueve opciones diferentes para apagar el ordenador, mas los botones (ver imagen). Pues bien, ahora resulta que el ex-programador de Micros~1 que se ocupó de implementarlo - y que ahora trabaja para Google - ha escrito en su blog como es posible que haya sucedido eso, como es posible funcionar tan mal, como es posible que, según el propio ex-programador, algo que debería llevar una semana diseñar, implementar y probarlo haya llegado a tardar más de UN AÑO. Y lo explica con todo lujo de detalles, haciendo del artículo una critica clara los procesos internos de Micros~1. Recomiendo su lectura. Un pequeño resumen y algunas curiosidades:

  • Su equipo tenía un Mac al cual admiraban como paradigma de las interfaces sencillas y bien hechas (parece referirse a "físicamente", como si los diseñadores de la UI lo tuvieran ahí a propósito). No hace falta decir que Allchin se pasa el día diciendo que si Vista es el mejor sistema operativo del mundo, y el entorno Micros~1 lo repite continuamente. Jamás serán capaces de admitir la superioridad de Mac OS en el escritorio. Los Linuxeros al menos lo reconocemos (no hay más que ver gnome).

  • Dice que su equipo era gente con talento, capaz, con buenas ideas. La receta para el éxito. Lo que confirma lo de siempre: Los programadores de Micros~1 no son especialmente malos o buenos, son programadores, como todos los demás. Es la gestión, los que mandan, los que crean el infierno.

  • ...pero además de la gente encargada de hacer el trabajo, había un "manager", un "asistente de experiencias de usuario, 3 testers...un total de ocho personas que formaban el equipo básico para implementar el menú de apagado (supuestamente tambien harían alguna otra cosa como ocuparse del mismo menu en dispositivos embebidos y demás pero no mucho más; el menu de inicio era cosa de otros por ejemplo)

  • Adicionalmente, su equipo tenía que mantener relaciones con el equipo encargado del menú de inicio, el kernel que implementaba la funcionalidad necesaria para apagar...adicionalmente existen hasta 6 capas de "managers" entre los equipos. En total, alrededor de 43 personas relacionadas, de las cuales 24 podían decir o hacer algo que influyera sobre el trabajo final. 24 personas para opinar sobre como diseñar la interfaz para apagar el ordenador.

  • Cuando el programador que nos cuenta la historia se fue, despues de un año de trabajo, Vista no estaba lanzado, pero de todas maneras no se sabía como iba a acabar funcionando el tema de apagar el ordenador. El código total despues de un año era tan solo de alrededor de doscientas líneas de código. En realidad no hacía falta más, se trata de la interfaz encargada de apagar el ordenador: Unas pocas opciones mas el código encargado de ejecutar las llamadas pertinentes. No se trata del código encargado de apagar el ordenador, no, se trata del menu encargado de llamar al código encargado de apagar el ordenador. El código encargado de apagar es tarea del equipo del kernel. Estamos hablando de que su tarea era diseñar un menu, nada más, algo que debería tomar una semana a todo el equipo, sin escatimar en meticulosidad. ¿En que se había consumido el tiempo, entonces? Pues alrededor de cada 4 semanas el grupo del kernel o el de menu de inicio se quejaba de algo en la reunión semanal. Luego, en su propia reunión semanal, discutian durante 90 minutos sobre como ese cambio afectaba al menú de las 200 líneas. Hacían lo mismo en la reunión de la siguiente semana, a la siguiente, a la siguiente....y a la siguiente volvía a haber una reunión donde el kernel y/o los del menu de inicio se quejaban de algo. Vuelta a empezar. Así, un año.

  • Un detalle muy curioso: El sistema de gestión de código. Resulta que como el número de programadores con necesidad de introducir sus cambios es muy elevado, no existe un único repositorio centralizado (lógico), la infraestructura no lo soportaría. Asi que el repositorio central es en realidad un repositorio de repositorios descentralizados que a su vez está dividido en repositorios. Un repositorio para cada grupo, vaya. Y los desarrolladores incluyen sus cambios en los "nodos" finales. Despues de un tiempo se integran en los repositorios superiores. Y despues de otro periodo, se integran en el repositorio central.

  • El repositorio de este trabajador se ubicaba en una jerarquía de cuatro nodos, asi que los cambios tardaron entre uno y tres meses en llegar al repositorio central. Para más inri, los repositorios de los grupos con los cuales tenían que interactuar, el grupo del menú de inicio y el del kernel, estaban separados del suyo, no compartían ningún subrepositorio excepto el central. Consecuencia: Pasaban semanas hasta que se enteraba en qué direccion estaban yendo los programadores de esos grupos, semanas para descubrir los fallos. Chapuza total.


Reacción de Joel Spolsky al leer estos comentarios de este ex-trabajador - recordar que Joel fue programador del equipo de Excel en Microsoft -: "Every piece of evidence I've heard from developers inside Microsoft supports my theory that the company has become completely tangled up in bureaucracy, layers of management, meetings ad infinitum, and overstaffing." ("Todo lo que he escuchado de boca de trabajadores de Microsoft apoya mi teoría de que la compañía ha sido invadida por la burocracia, capas interminables de "managers", reuniones, exceso de trabajadores....")

Hay que decirlo más

Desternillante video de la Hora Chanante. "Hijo de puta: Hay que decirlo más". No he podido evitarlo.

22 de noviembre de 2006

Lista de hardware PCI soportado por Linux

En las distros comerciales (que no tiene nada de malo que lo sean) si que hay listas de "hardware soportado", pero no ninguna de la "comunidad", del kernel en si. Así que he escrito un pequeño script (muy cutre y casi sin comentarios, tal y como Dios desea que sean todos los scripts del mundo, y quien soy yo para llevar la contraria a Dios) que da una lista de dispositivos PCI (se podría extender a dispositivos USB). ¿Y por qué me gasto un mensaje del blog en anunciar una tontería semejante? Pues porque personalmente pienso que es muy útil, aunque si dicha utilidad no existe ya supongo que es precisamente porque nadie lo necesita. En fin.

Para obtener dicha lista el script tan solo tiene que mirar en /lib/modules/`uname -r`/modules.pcimap. Dicho archivo es generado por depmod a partir del hardware que cada módulo (driver) declara que puede cargar. Es decir, en el kernel existe una infraestructura "genérica" para que los modulos digan: Yo soporto tales dispositivos (y que se puede cotillear con "modinfo nombredelmodulo"). Depmod extrae la lista de todos los módulos que encuentre para ese kernel y agrupa todo en ese archivo; archivo que udev utiliza para saber qué módulo tiene que cargar cuando detecta un dispositivo en el sistema. Mi script tan solo mira esa lista, consulta los nombres de dispositivos en /usr/share/misc/pci.ids (al menos en Ubuntu está ahí) y los imprime. Nada del otro mundo.

script, y lista de ejemplo de un kernel Ubuntu, de los que activan casi todo.

21 de noviembre de 2006

Usabilidad

Joel Spolsky, el de "Joel on Software", ha escrito un gran post (en inglés) sobre como Windows Vista tiene....¡9! maneras diferentes (7 opciones de menu y dos botones) para apagar un ordenador, y lo chapucero que es ese rincón de Windows desde un punto de vista de usabilidad. Una lectura muy recomendada, especialmente para los desarrolladores de Ubuntu (distribución que uso y amo), cuyo panel de apagado tiene nada menos que seis opciones.

Por otra parte Raymond Chen, un trabajador de Microsoft muy inteligente y competente que tiene un blog en el que cuenta cosas sobre Windows, escribió hace un tiempo un interesante artículo en el que se queja de esos programitas que añaden iconos a la barra de inicio rápido o que añaden una barra nueva enterita a la barra de tareas, o iconos en el área de notificaciones que no hacen absolutamente nada excepto ocupar espacio, o añadir menus como el de ATI, que aparece cuando haces click contextual en el escritorio.

Raymond Chen cuenta que no existe una API para añadir elementos en ninguno de ellos. La teoría es que son cosa del usuario y que el usuario debe personalizarlo, no las aplicaciones. Eso no impide a muchas aplicaciones añadirlos a lo bestia. Aparentemente los favoritos del IE si que tienen una API para añadir elementos que las aplicaciones empezaron a abusar...y a raiz de aquello parece que la gente de Microsoft aprendió cosas.

Tambien cuenta que las "burbujas" de información de los iconos del área de notificaciones deben tener mensajes claros, y da como ejemplos algunos de Windows, y cuenta una anécdota en la que un amigo le llamó porque a su madre le había aparecido una burbujita de Windows Updates que decía "Las actualizaciones están listas para ser instaladas". Y el mensaje no le decía qué tenía que hacer, asi que intentó averiguar qué esperaba la burbujita de ella y llamó a su hijo...

Historias interesantes.

13 de noviembre de 2006

Sun publica Java bajo la GPL

Concretamente bajo la GPLv2. No son rumores de esos que llevan años por ahí, es algo oficial, y hay un anuncio de prensa. Como muchos saben, "Java" es un término algo difuso que incluye varios productos. Pero Sun está abriendo: Java Platform Standard Edition (Java SE), Java Platform Micro Edition (Java ME) y Java Platform Enterprise Edition (Java EE). Esperan tener un JDK compilable por completo en el 2007.

En fin. Como quizas sepan algunos, un servidor ha sido muy crítico con Sun en el pasado, por su actitud con respecto al software libre y a las empresas que trabajaban con él. Por eso precisamente me alegra ver que escuchan y que a pesar de todo, incluso a pesar dicho que nunca liberarian Java porque animaría a la gente a hacer forks, sepan corregir su trayectoria y hacer movimientos como este. Gracias a este movimiento Sun se coloca como una de las empresas mas amigables del software libre: Han redimido sus pecados y ahora están blanqueando su alma a base de penitencia.

Y no es que un servidor se haya vuelto fan de Java de la noche a la mañana precisamente. Sigo pensando que el concepto de "VM Sandboxing" es un concepto equivocado y devora-memoria, que GCC + LLVM es la Luz Verdadera, etc. Pero este anuncio cambia las cosas, porque permitirá, por ejemplo, que classpath pueda copiar y pegar el código de todas las clases "estándar" de Java, y completar de esa manera GCJ en un santiamen, y probar, comparar, mejorar, contribuir. La dirección del lenguaje en si sigue en manos de Sun y sus burocráticos comités, pero todo lo que rodea al lenguaje va a recibir un empujón brutal. En resumen, sigue siendo Java, pero de repente es libre, y eso lo pone en buena disposición hacia el futuro. Seguirá comiendome megas de RAM por un tubo pero como bien sabemos los usuarios de OpenOffice, el software cuando es libre es menos malo.

9 de noviembre de 2006

Análisis de Vista RTM por Paul Thurrot

Paul Thurrot es, como todos saben, una de las mayores referencias en el interweb a la hora de analizar productos de Microsoft. A muchos expertos de Windows no les cae bien. Una de las razones es por un cierto suceso turbio en el grupo de beta testers y MVPs que no conozco en detalle. Pero otra de las razones es porque a pesar de ser un zealot de Microsoft no tiene dudas a la hora de criticar a Microsoft cuando mete la patay cuando copia a Mac OS X.

Tambien sabrá la gente que ya se ha producido el RTM de Vista. Eso significa que Vista está terminado: No más RC's, ni betas. La RTM es la versión que millones de personas usarán en sus casas. Pues Thurrot acaba de publicar los primeros documentos sobre Vista. Y uno de los puntos más interesantes es cuando Thurrot describe el "Vista Reset", tal y como él llama a ese fatídico punto en la trayectoria del desarrollo de Vista, cuando tras dos años de desarrollo de Longhorn y un montón de videos y promesas, se vieron obligados, debido al tamaño de la chapuza que estaban montando, a retroceder y empezar de nuevo a partir de la base de win 2003. El verdadero Windows Vista, el que de verdad podía haber roto esquemas, el Longhorn de este video no verá la luz hasta la próxima versión de Windows, y eso hace que algunos pasemos totalmente de Vista en todos los aspectos. Thurrot ha resumido esta hecatombe muy bien:

"Microsoft will tell you that Vista has really only been in active development since mid-2004, when it "reset" the original Longhorn project and restarted development on the Windows Server 2003 code base. I'd argue that this is a convenient misstatement of the facts: Windows Vista is Longhorn and Longhorn is Windows Vista. In short, Microsoft did take five years to bring Longhorn--sorry, Windows Vista--to market.

As it turns out, the reason why is simple. Microsoft screwed up, plain and simple. Each version of Windows is based on the version that came before it and because Windows Vista was envisioned as a kitchen sink release that would include every major new feature imaginable, it eventually teetered and fell under the weight of the technology Microsoft was heaping upon it. That Vista is now based on the Windows Server 2003 code based and not that of Windows XP is meaningless. When the project started, back in 2001, it was based on Windows XP.

After the reset, Microsoft scaled back the Vista feature-set dramatically and ensured that features were added in a more logical fashion. The two year development time that Microsoft refers to in this case is the most recent two years, the period of time during which Vista got back on track. This is a period of time that Microsoft should be justifiably proud of. The previous three years? Trust me, we'd all like to forget that."

Cambios en Linux 2.6.19

Como mantenedor de LinuxChanges, estoy en posición de conocer antes que nadie la lista de cambios relevantes que incluirá esta version. Asi que aquí va la de 2.6.19:

  • Ecryptfs. Una maravilla, un sistema de archivos pero no uno tradicional (no implementa su propio formato de disco); este se "apila" encima de otro: Puede utilizarse con ext3, reiser, NFS.... El caso es que a diferencia del cryptoloop/dmcrypt, que encriptan un volumen completo, ecryptfs encripta archivo por archivo: A bajo nivel en los primeros 4 KB del archivo almacena la información del cifrado, en el espacio restante es donde va el archivo. Ecryptfs se encarga de cifrar/descifrar (si tienes las claves apropiadas para descifrarlo, claro) el archivo de manera transparente para el usuario. Es como una especie de gpgfs, y es muchísimo más amigable para entornos de escritorio que cifrar todo un volumen.

  • GFS2, el sistema de archivos de clustering de Red Hat. Aunque es el más famoso, no es el primero: OCFS2 ya entró en 2.6.16

  • EXT4. La versión que se incluye es experimental, y ni tan siquiera tiene muchas de las cosas interesantes...por el momento no tiene ningún interés para los usuarios la verdad.

  • Drivers PATA basados en libata. Alan Cox ha implementado buena parte de los drivers IDE antiguos encima de libata, la base de la implementación SATA. ¿Ventajas? La base IDE antigua es una mierda (gestión de errores caótica, deadlocks en SMP). No es que a día de hoy se utilize IDE demasiado....el futuro es SATA, pero....en fin, es Alan Cox

  • 1.79 MB de drivers OSS han sido eliminados. ¿Razón? Había drivers ALSA para el mismo hardware.

  • AVR32, una nueva arquitectura (no, NetBSD no la soporta)

  • Variante de RCU "interrumpible": Hasta ahora la sección crítica de RCU no se podía interrumpir. Pero la gente, y especialmente la gente que quiere convertir a Linux en un SO de tiempo real, necesitaba que las secciones críticas de cosas como spinlocks y RCU fueran interrumpibles.

  • Se puede desactivar la capa de "bloques" (block layer, para entendernos). Con NFS, JFFS2, ramfs, no es necesaria. Genial para cosas embebidas.

  • Soporte para IO Asíncrono vectorizado

  • Aumento de velocidad a la hora de suspender al disco

  • Mejoras internas destinadas a hacer la implementación de características de virtualización mucho más limpia. Quien dijo que era bueno mantener la API interna estable....

  • Soporte para hotplug físico de CPUs y memoria en x86-64

  • Soporte para compilar el kernel contra la protección de GCC de fallos de seguridad de desborde de pila

  • Una opción de montaje "-o flush" para FAT, destinada a mp3 y demás cacharros portátiles. No es ni un "-o sync" ni un "-o async", es algo intermedio: Las operaciones no son síncronas (como con -o async) pero se intenta sincronizar los datos con el dispositivo lo antes posible (como -o sync) en vez de dejarlos en memoria durante demasiado tiempo

  • Detección asíncrona de dispositivos

  • Una cosa llamada Netlabel, mejoras a SELinux, Mobile IPv6, unos cuantos drivers nuevos y muchas cosas más. En LinuxChanges está la lista completa, en inglés.

7 de noviembre de 2006

Adobe dona a mozilla el código de su motor Javascript

He aquí el anuncio, he aquí el proyecto, y he aquí el FAQ del proyecto.

¿Que ha donado Adobe exactamente? El motor de ActionScript, el lenguaje de script que utilizan en Flash, y que está basado en Javascript. Aparentemente, ActionScript no es más que Javascript, solo que sus librerias en lugar de manejar elementos de una página web manejan los elementos de la animación Flash.

El motor que ha donado implementa o implementará pronto el estándar ECMAScript 4th edition, llamado tambien "Javascript 2". Tiene incluso un compilador JIT, para acelerar la ejecución del código. la versión que Adobe libera es la "ActionScript VM 2": Una reescritura de su anterior VM, optimizada para mayor rendimiento.

Como puede comprobarse, las cosas le van bien a Mozilla.

3 de noviembre de 2006

Bomba: Alianza de Novell y Microsoft

Se acaba de producir hoy algo que el mundo del software libre creiamos imposible: Microsoft y Novell han llegado a un acuerdo para colaborar en interoperabilidad y soporte. He aqui el anuncio oficial de Microsoft, y aquí el de Novell. Van a colaborar en temas de virtualización, servicios web, gestión de servidores y compatibilidad office <-> openoffice, un acuerdo mutuo de proteccion contra ataques de patentes, etc. Aquí han publicado una carta abierta conjunta dirigida a la comunidad del software libre.

Pero en principio, se hace absurdo. ¿Por qué iba a Microsoft a llegar a un acuerdo que claramente le daña? No nos llamemos a engaños, Microsoft tiene un monopolio y lo que menos le conviene es precisamente la interoperabilidad con otros sistemas. Al estar en monopolio, lo que le beneficia es precisamente que los demás no sean interoperables con él. Y repito, no nos engañemos: Microsoft siempre ha hecho todo lo posible para garantizar esa falta de interoperabilidad. Sin embargo, a Novell (y a linux en general) le viene de perlas. Cuanto más interoperable sea Linux, más fácil será poner Linux en entornos Windows (es decir, en el mundo real).

Pero Microsoft no es idiota y de negocios sabe un rato, más que Novell y Red Hat juntas. ¿Que hay oculto detrás de este acuerdo? Ramón me comenta que MS necesita este acuerdo sobre todo en tema de virtualización, que MS necesita que Linux funcione junto con Windows. Estoy de acuerdo con eso, pero tambien creo que hay un aspecto muy importante: Microsoft quiere ganarse la confianza de la Unión Europea y similares. La UE y Corea está dando unos varapalos tremendos a Microsoft y el monopolio se le esta haciendo algo dificil de llevar a MS. Se empieza por Europa...¿y dónde se termina? ¿Qué otras medidas podría tomar la UE, que otros paises podrían sumarse a multar y prohibir Windows? Hasta ahora han aguantado, pero no vayan a pensar ustedes que Microsoft puede aguantar cualquier ataque sin caerse o al menos sufrir graves heridas. En mi opinión, además de los factores estratégicos de la virtualizacion y la intercompatibilidad, tambien desean aligerar un poquito la presión sobre su monopolio, y a la vez esperan poder controlar las ventas de Novell. Jamás se ha firmado un acuerdo en el que una parte ceda algo a la otra: siempre ambas partes esperan salir ganando y estafar al compañero, y aquí además estamos hablando de Microsoft.

JPEG "liberado", un gran victoria para internet

La patente del JPEG se va a hacer gargaras.