Archive for junio 2009

La anecdota del ms-sys. Codigo binario de Microsoft en Debian.

junio 26, 2009

Alrededor de agosto del 2006 añadí a Super Grub Disk la opción de «Arregla Arranque de Partición de Windows».
Pero, antes de nada, veamos que es eso de arrancar Windows. Mucha gente lo hace todos los días pero ignora como funciona en detalle.

Cómo arranca Windows

Al arrancar el ordenador se ejecuta la BIOS que es como un chip que tiene entre otras la función de poder arrancar nuestro sistema. Para ello normalmente comprueba el cdrom o disquete en busca de código arrancable y si no lo encuentra prueba con el disco duro.
Bien. Antes de seguir veamos qué tiene el disco duro.
El disco duro empieza con el MBR, sigue con unos sectores a veces usados y a veces no y finalmente empieza la primera partición.
Justo al principio de cualquier partición y por tanto de la primera partición antes de que comience el sistema de ficheros propiamente dicho hay un pequeño trozo para poner código de arranque.
Volvamos al hilo anterior. La BIOS al final carga el disco duro. En realidad carga una parte del MBR. El MBR estandar busca la primera partición activa (que suele ser la primera partición) y le cede a ello la carga.
En este punto llegamos a la parte del arranque que ya es propia de Microsoft. Un código escueto hace lo posible por encontrar ntldr o algún fichero esencial del kernel de Windows según las versiones.
Ntldr carga y poco a poco se carga el resto del sistema Windows.

Problemática al restaurar copias de seguridad

Bien. Ahora imaginaros que copias todos los archivos de Windows en un archivo .zip o equivalente. En otra máquina particionais y metéis ahí el Windows. Intentáis arrancar y no os va. Esto es porque el arranque llega hasta el inicio de la partición de Windows. Pero en la partición de Windows no hay código arrancable.
¿Como se soluciona esto? Pues poniendo el código mágico en el sitio correcto.

Soluciones al arranque de partición de Windows

Para ello teníamos fixboot del disco de Windows, la utilidad ms-sys y Super Grub Disk con su opción Arregla Arranque de Partición de Windows. Más adelante veremos qué queda de estas opciones.

Arregla Arranque de Partición de Windows de Super Grub Disk

Veamos como funcionaba la opción Arregla Arranque de Partición de Windows de Super Grub Disk.
Por un lado desarrollé una versión de dd para Super Grub Disk. No es gran cosa. Tiene una sintaxis que se ha de seguir a la letra y sólo tiene un sentido. Desde archivo a dispositivo. (Más adelante desarrollé dddd que permite copiar de dispositivo a dispositivo pero no acabo de estar de convencido de que funcione del todo bien).
Por otro lado se necesitaba ese código mágico que buscase el ntldr o algo equivalente. ¿De dónde sacarlo? Pues del mundo del software libre. Pues parece ser que existía ms-sys que hacía esto mismo.
Recuerdo que aplique ms-sys a un fichero o directamente a una partición con sus opciones de windows. Los primeros 512 bytes de la partición los podía volcar a un fichero. Y ese fichero sería el que leyese mi recién desarrollado dd para poderlo grabar al inicio de una partición.
Comentaros que el sistema funcionaba. Recuerdo haber ayudado a un amigo que actualizaba 🙂 de Windows Vista a XP. Restauraba el XP (no recuerdo como lo tenía guardado) y con Arreglar Arranque de Windows (Esta opción toca el MBR y también la tuve que sustituir por el cargador syslinux que viene a hacer lo mismo: Cargar la primera partición).
y después con Arreglar Arranque de Partición de Windows listo.
¿Por qué se alegró tanto mi amigo? Por el SATA. El arreglo de windows mediante el disco de xp suponía insertarle un disquete (ya sabéis hay que hacer el disquete y luego el disquete es lento) y luego, bueno, saberse lo del fixboot.

Cómo funciona ms-sys

Veamos por encima como funciona ms-sys. El código de ms-sys es muy tonto en realidad. Es abrir un fichero para leer-y-escribir y meterle en determinadas posiciones el código que se quiere. El programa está bien estructurado y cada opción tiene sus código de arranque asociado en un fichero diferente. Además queda muy claro en el código en qué posición el código ha de escribirse.
El código que ms-sys está escrito en unos arrays de chars (o eran unos structs) cuyos valores en vez de estar escritos entre comillas están escritos en hexadecimal separados por comas. Esos son los códigos mágicos.

Los códigos mágicos

Ahora demonos un paseo por la web de ms-sys . En ella podemos ver la documentación. Entre los links tenemos a: Boot records revelead. En esa página se nos desvela cómo funciona (con mayor detalle y exactitud) el arranque de Windows. Ahí podéis ver código binario de Microsoft. Y os explican qué hace cada parte del código. Si no entiendes de ensamblador puede que te pierdas. Esa página es como el código fuente de Windows 2000 que se ve habían extraído de Microsoft sin permiso. Vamos que mejor no leerla.
Pues bueno, el autor de ms-sys sólo tuvo que copiar y pegar (y también entenderlo y programarlo no quitemos merito) los caracteres que ahí se muestran para cada una de las versiones de windows.

Problemática Copyright Microsoft

La verdad es que fui consciente de la problemática temprano pero de alguna manera no quería verlo. Me podía más el Torvalds que todos llevamos dentro (el ingeniero) que el Stallman (el filosofo). Al autor de ms-sys le pregunté y el me respondió que era una información libre disponible en Internet y que cómo Microsoft no había cerrado esa web entendía que no había ningún problema. Su argumentario puede leerse en este hilo de sourceforge.

En Debian se reporta el error

Antes de que yo dijese nada en Debian ya se daban cuenta. El bug se abrió en mayo del 2007. Yo interviné en el mismo en enero de 2008 pero no fue hasta que me moví por la lista de legal de Debian en Febrero de 2008 que el bug se movió de normal a serio. Finalmente en marzo de 2008 se cerró el bug ya que ms-sys había sido retirado de los repositorios de Debian. Poco después fue también retirado de Ubuntu.
Para los entusiastas de la legalidad no perderse la explicación de Debian sobre debian/copyright no explicando el tema o la no inclusión del código en ensamblador equivalente:
ms-sys contains verbatim copies of the master boot records of windows

2000 and windows 95B et al. While it would be valid to reimplement an
MBR in such a way that it was functionally similar to an MBR that
boots these MS operating systems, the length and expressive content of
the MBR makes it rather likely that it is copyrightable, and that we
have not been granted the right to distribute, nor is the assembly in
question licensed in accordance with the DFSG (nor is the assembly
even actually present, which falls afoul of DFSG §2).


Finally, debian/copyright does not properly discuss this problem at
all, nor does it mention the copyrights on syslinux's mbr or any of
the other mbrs which are present.

¿Y como se arregla ahora el arranque de partición de Windows?

Se puede usar fixboot del disco de Windows 2000/XP si tienes una copia legal.
Se puede usar ms-sys desde su página pero no estarías haciendo algo legal.
Se puede usar el Super Grub Disk antiguo si lo sabes encontrar por la redes p2p pero no estarías haciendo algo legal. (Como os podéis imaginar quite la opción conflictiva del Super Grub Disk).
Comentaros también que el Super Grub Disk tiene una opción pre-pre-alpha (vamos que está muy verde) para restaurar el último sector (en principio es una copia de seguridad del primer sector) de una partición ntfs al primero. Esto es sólo es útil si sólo se ha sobreescrito el primer sector del ntfs y no al restaurar desde una copia de seguridad.

Conclusiones

Vaya con el artículo. Si no fuera por la informalidad del mismo podría venderselo a alguna revista.
Sólo comentar que aquí lo importante es ver lo que no pasó. Desde mayo del 2007 hasta Febrero de 2008 ese bug pasó inadvertido. Diréis que ese bug es como cualquier otro pero no.
Si el sistema de reporte de bugs fuera lo suficientemente avanzado hubiera detectado la palabra copyright y hubiera enviado una copia del mismo a la lista debian-legal. Quizás no todos los reportes de bugs con copyright deberían mandarse a debian-legal, quizás un resumen semanal, pero algo se debería hacer.
Por último aquí se ve la importancia de instituciones como la FSF o Debian que certifican, a veces más tarde que pronto, si un programa es verdaderamente libre.

Aprendiendo los sistemas de control de versiones: Introducción

junio 25, 2009

A ver si sé explicar lo que es un sistema de control de versiones.
Pongamos en primer caso el ejemplo sencillo de controlar las versiones de un archivo de… pongamos un archivo de texto (no tiene porque ser siempre de código) que hago yo mismo.

Y sigamos suponiendo que trabajamos con él como siempre: Modificando un sólo fichero.
Ahora dejamos de lado el fichero durante un tiempo. Volvemos a él y nos fijamos en un parrafo que hay en medio del fichero del texto acerca de unas helices que tienen una forma en ese.
Y yo me pregunto… ¿Por qué puse ese texto? ¿Acaso hubiera puesto en alguna versión algo más apropiado que «forma en ese» o quizás era algo peor?
Si suponemos que hacemos copias de seguridad regulares de nuestros ficheros es posible que veamos el cambio en alguna de ellas.
No obstante esto tiene algunos inconvenientes: Por un lado hay que leerse todo el fichero completo de la copia de seguridad (aunque alguno sabrá que la utilidad diff ayuda a ello).

Por otro lado es harto posible que junto al cambio del texto no nos aparezca la razón o la descripción del cambio en cuestión.
Todos estos pequeños problemas los gestiona el sistema de control de versiones. Qué cambios haces, en qué lineas del texto y qué razón o descripción le das al cambio son guardadas.
Ahora que lo hemos entendido hagamos un ejercicio de abstracción. Esto es mi documento pero ¿qué pasa si es un documento compartido, qué pasa si es editado por varias personas?
Si la descripción que le pone una de las personas es insuficiente habrá que preguntarle pero ¿Como sabemos quien hizo el cambio?
Pues, claro que sí, el sistema de control de ver

siones también lleva el registro no sólo de qué se modifica y qué descripción se le da sino de también de qué usuario del sistema lo ha modificado.

Esto es un gran avance pero aún hay más. Ahora en vez de abstraernos en cuánto a los usuarios nos vamos a abstraer con respecto al código fuente de un programa.
Es el tema de las ramas. Casi seguro que conoceréis el navegador libre Firefox. Y seguro que habréis notado las notables diferencias entre las versiones 1.x, 2.x y 3.x.
Pues bien, Firefox no tiene un sistema de control de versiones por cada rama sino que tiene un solo sistema de control de versiones que, ojo al dato, soporta ramas.
Es decir, cuándo hacemos una modificación del código podemos escoger en qué rama hacemos la modificación. (Aunque la mayoría de los usuarios trabajamos en una rama u otra del código sin llegar a escoger rama conscientemente)
Resumiendo:
– Modificar un fichero de la manera clásica es muy complicado con respecto a los cambios que se han hecho
– Los sistemas de control de versiones llevan un registro de los cambios en las lineas y ficheros dónde se han producido
– Los SCV también gestionan la autoría de los cambios.
– Los SCV también soportan varias ramas de desarrollo en paralelo.
Seguiremos con el tema.

Aprendiendo los sistemas de control de versiones: Presentación

junio 25, 2009

Bien. Tengo un lío en la cabeza con los sistemas de control de versiones que no veáis.
Sé lo que es cvs, sé más o menos como funciona svn, sé las mil y una maravillas de git. También sé algunos de los comandos claves de cada una de las herramientas.
Pero me encuentro en un mar de dudas. No sé, a priori, con qué problemas me voy a encontrar y cuándo es mejor uno que otro.
Además que me corre prisa porque ahora voy a desarrollar el Super Grub Disk con más gente, en grupo, como tiene que ser y tengo que saberme manejar.

En esta serie de artículos intentaré haceros entender lo que yo voy aprendiendo mientras experimento con estas herramientas y diferentes situaciones.
A ver si hacemos una guía para tontos o algo parecido.
Venga, nos leemos.

Escribiendo el blog offline

junio 24, 2009

Antes de nada comentaros que este es mi primer post con Kblogger.
Eso espero que redunde en una mayor prolijidad en mis posts. De momento la única pega que le veo es que no puedo elegir etiquetas aunque sí categorías.
El blogGtk! no me arranca si quiera y el otro que queda el gnome-blog o algo parecido es muy simplista.

Pues nada, nos leemos.

Por qué TCOS es tan bueno

junio 2, 2009

Hoy me ha dado por mirarme el blog de mariodebian. Mariodebian desarrolla entre otras cosas: Thin Client Operating System más conocido como TCOS.

La verdad es que cuándo alguien me dice que está montando unos terminales ligeros con ltsp le digo algo así como que está usando una anticualla, que es mucho mejor el TCOS.

De vez en cuándo he llegado a decir que el ltsp usaba nfs y que seguramente como ya hicieron el pxes y el tcos ya no lo usa. Pues no. El ltsp sigue con el puñetero NFS.

A raíz de la creación de un manual por parte de TCOS Brasil (que envidia tener comunidades) Mariodebian enumera las razones por las que TCOS es mejor que LTSP.

Me quedo con estas razones:

  • LTSP5 usa NFS como root filesystem (opcionalmente SQUASHFS sobre NBD), TCOS descarga (tftp,http,nfs) la imagen squashfs y no necesita NFS cuando el terminal tiene más de $TCOS_MIN_RAM Mb (por defecto 38) de memoria. Si el servidor se cuelga o pierde la conectividad en LTSP5 todos los terminales sufren un kernel panic, con TCOS sólo hay que esperar a que el servidor se recupere.

(Lo del kernel panic no lo sabía).

  • El sistema de acceso a dispositivos, aunque los dos usan LTSPFS (filesystem sobre Xorg + FUSE) en TCOS se ha mejorado con una aplicación gráfica llamada TcosDevicesNG , en LTSP5 los dispositivos se montan de manera automática y el desmontaje es complicado con TCOS es muy sencillo.
  • LTSP5 usa como punto de montaje «/media» mientras en TCOS se usa el Escritorio del usuario, así nadie puede acceder al contenido del dispositivo (ni siquiera root)
  • LTSP5 sólo soporta disquetes, memorias USB y CDROM datos, TCOS además de esos, soporta particiones de disco duro (incluido NTFS), CDROM-USB, discos Firewire, CDAUDIO, etc…

También hay otros detalles como que cualquier novedad tecnologica como pudiera ser el pulseaudio se adopta antes por TCOS.

Ahora, cuándo tenga que recomendar TCOS enlazaré a este post. 😉

Auto Super Grub Disk 1.7 disponible

junio 2, 2009

La novedad de la versión tiene soporte para Ubuntu 9.04 y ext4.

Para quien no sólo sepa Auto Super Grub Disk que funciona en Windows. Está muy recortada para que sólo haga un par de cosas:  Arreglar el arranque de Linux (lo que es lo mismo restaurar el grub en el mbr) e intentar arrancar linux.

Disfrutadla.