El software libre me arruinó la cabeza
By cesar | agosto 28, 2014
Desde 1993 uso software libre. Mi cabeza no es la misma desde entonces. Te cuento cómo fue.
Mi vida antes y durante mi encuentro con el software libre
En 1990 trabajaba en una importante empresa de mi provincia, la Empresa Provincial de la Energía. Mi primer trabajo fue preparar pliegos para adquirir las licencias de software para los escritorios: procesadores de texto, planillas de cálculo, programas de comunicaciones por puerto serie y emuladores de terminales alfanuméricas. El siguiente fue decidir un motor de base de datos relacional, con SQL y un 4GL para acelerar el desarrollo de las aplicaciones administrativas. Los sistemas de bases de datos podían correr sus programas clientes en los escritorios de los usuarios, y el motor de la base en un equipo que hacía las veces de servidor de base de datos.
Desde que solicitaba un programa hasta que lo tenía en mis manos podían pasar en 6 y 14 meses. Muchas veces recibíamos programas varias versiones más nuevos que el solicitado por este motivo. Imagina lo que puede ser que quieras hacer una prueba de concepto. Una cosa rapidita, una evaluación. Con esos tiempos de adquisición es imposible.
Lo que era usual entonces, es que uno buscaba proveedores, conseguía los manuales prestados, los estudiaba, y luego convocaba al proveedor para que haga una demostración de su producto. Durante la demo teníamos acceso al personal técnico que venía a asegurarse que todo funcionara. Hacíamos preguntas y sondeábamos, tanto nuestra comprensión de lo que estudiamos, como la solvencia del personal del proveedor, como los límites y bordes ásperos del producto, para tener una mejor idea de sus capacidades. O sea, meses.
La alternativa era comprar cualquier cosa brillante que el proveedor te ponga delante de los ojos. Esta alternativa nunca nos pareció razonable y nunca la usamos.
De hecho, unos cuantos productos nunca pasaron de estos estudios y demostraciones. El tiempo nos dio la razón en la mayoría de estos rechazos, y mucho más en las aceptaciones.
El software privativo es muy difícil de evaluar en empresas con estos tiempos de compra.
La vida continúa
En 1991 me casé y me dí cuenta que los ascensos en una empresa pública iban a tomar mucho tiempo. La única manera de conseguir más dinero para mi nidito de amor era trabajando por mi cuenta de manera independiente.
Me gusta programar. En los años anteriores me he llevado muy bien con C y variantes compilados de la familia xBase, como Clipper, fundamentalmente. Mi sistema operativo MS DOS personalizado se parece a uno de esos autos de carrera de «Rápido y Furioso», aceitado y brillante, poderoso. Una pc XT Turbo con todo lo que un programador puede requerir. Incluso un mouse RS232, inútil para todos los programas, excepto para un entorno extraño, que me maravillaba: Smalltalk. Pero mi relación con Smalltalk y la orientación a objetos es tema para otra entrada en el blog.
Quiero hacer las cosas decentemente
Esto de las copias ilegales no me gusta: si a mí no me va a gustar que copien ilegalmente mis programas, ¿porqué voy a usar un entorno de desarrollo que sea una copia ilegal? Así que en 1993 junto los 400 USD (yo cobraba 800 USD por mes) que cuesta la licencia del Borland C++ 3.1 y me compro el paquete. Son como 6 kg de manuales y libros en una caja de cartón que contiene también un CD-ROM con el software. Una maravilla. Lástima que no tengo unidad de CD-ROM en mi PC XT Turbo. No importa, me hago las copias en casa de un amigo y empiezo a disfrutar de mi legalidad a estrenar.
Tengo C, Assembler, C++, una biblioteca para hacer interfaces de texto (TurboVision) y otra para interfaces gráficas (Object Windows Library). ¡Están los fuentes de las bibliotecas! ¿Nunca quisiste saber cómo funciona el printf()? ¡Ahí estaba el fuente de printf()! No se cuántas horas le puse a leer ese código que estaba tan bien escrito.
¿Qué más puede uno necesitar?
Bueno, yo necesitaba los placares para mi dormitorio, así que lo que necesitaba era ¡un cliente!
Un día se acerca un cliente con un problema de tipo combinatorio. No hay muchos programadores a los que le guste la matemática, así que el pobre cliente fue rebotando de uno a otro hasta que varios le dieron mi nombre.
No es que yo sea un matemático, pero estudiar hasta aprender, y aprender para hacer son cosas que no me asustan.
El problema
El problema que me trae es hacer un bingo televisivo. Entonces habrá unos 400 mil cartones diferentes vendidos. Un programa de televisión tiene un segmento donde se hace el sorteo con un bolillero especial neumático. A medida que las bolas salen automáticamente y sin ningún humano cerca, en los hogares cada apostador marca en su cartón si la tiene. Cuando en algún lugar uno de estos apostadores marca todos los números de su cartón, en TV el sistema de cómputo también detiene la máquina de sortear, y declara el ganador (o ganadores).
Cada cartón tiene un número de cada decena, entre el 1 y el 90, y otro número más que obviamente será de alguna de las decenas ya representadas, con la condición que ningún cartón es exactamente igual a otro, y que dentro de cada cartón todos los números son diferentes.
Por ejemplo: 3 12 26 31 49 55 67 78 84 25, donde los primeros son uno de cada decena, y el último es de una decena repetida, en este caso a del 2.
Si pensaste en poner esta información en un archivo, o en una base de datos, y hacer búsquedas, por cada bola que salga luego de la de orden N, con N > 9, tendrás que hacer una cantidad de búsquedas en la base igual a la combinación de N tomadas de a 10. Este número es rápidamente creciente. Digamos que no hay manera de hacerlo en una base de datos, al menos en 1993 que fue la última vez que lo estuve pensando seriamente.
Sin embargo se me ocurrió una manera de linealizar el problema, de manera que por cada bola nueva, sólo hubiera que hacer un único recorrido por todos los cartones. Cada cartón ocupa 11 bytes —uno para cada dígito de las primeras 9 decenas, uno para la decena y otro para las unidades de la decena repetida— o sea un total de 4300 kbytes.
El ejemplo anterior quedaba expresado como 32619578425.
Entonces con una pc con poco más de 4Mbytes de RAM, para acomodar también al sistema operativo y a los programas, estoy hecho. Bueno, es 1993 y las pcs de avanzada tienen 2Mbytes, las muy costosas 4Mbytes, y las de 8Mbytes hay que pedirlas especialmente, soy muy muy costosas. Ni hablar de tener una para hacer el desarrollo, arreglate con la XT con 764Mbytes totales y 30 Mbytes de disco rígido.
Comencé a pensar que necesitaba un sistema de memoria virtual o algo similar que me permita escribir mi programa como si estuvieran todos los datos en ram, pero usar el disco para almacenarlos. Además tenía que hacer dos versiones: una con datos suficientes para que quepan en ram, y la versión completa. La primera me iba a permitir hacer un poco de benchmarking usando sólo la ram, la segunda me permitiría saber que mi algoritmo se comportaba bien con todos los datos.
¿Porqué esta disgresión sobre pcs antiguas y cantidad de ram que ahora tiene la licuadora? Porque quiero que comprendas cómo estaba mi cabeza, hirviendo de ideas, saltando las limitaciones, usando el software para luchar contra el hardware.
Se ha dicho que Bill Gates dijo «640k deberían ser suficientes para todo el mundo», pero es una cita apócrifa, él nunca lo dijo (Se veía venir la cantidad de memoria que requeriría el MS Windows 8 
)
A no desesperar, tengo todo legalmente licenciado
Inmediatamente me acordé de mi inversión en el Borland C++ de 32 bits. ¡Con 32 bits puedo direccionar hasta 4 GIGA bytes! 5 megabytes no es nada para mi compilador. Además tengo los fuentes. (Escucho a Yoda que me dice al oído: «Use the Source, Luke!»)
¡Uh oh! En los kilogramos de manual encuentro que no tiene manera de trabajar con la CPU en modo protegido, que es donde encuentro las direcciones lineales, y hasta paginación. O sea, que no se puede. Si lo quiero, tengo que aprender a hacerlo en assembler y luego a generar el código, demasiado por encima de mis habilidades.
El sistema de protección
En aquellas épocas, ciertos modelos de negocio se basaban en el oscurantismo. Lo escribo en conjugación pasado, porque imagino que al ser leído en el futuro, esta frase puede sonar extraña y ajena. Las empresas de software desarrollaban una guerra contra las copias ilegales de su software y utilizaban toda herramienta disponible para lograr sus egoistas fines. Por ejemplo: educación a nivel de los niños que compartir un sandwich es bueno, pero compartir software es malo; a nivel de los estudiantes de sistemas implementaban sistemas de pago reducido para reclutar minions, pero no se los entregaban gratis porque eso sería contra la filosofía de «si lo quiere, pague»; el uso de la policía, y de los docentes como vigilantes de los estudiantes. Un perverso sistema que gasta ingentes recursos en impedir la copia de programas. Es claro quién paga todo este despliegue: el cliente de esas empresas. Parte de lo que abonan en concepto de licencias se destina para estas campañas. En algunos casos una parte del precio de la licencia se usa para un dispositivo de hardware que viene con el software y está destinado a impedir copias ilegales. Es interesante que sólo los clientes legales tienen esos aparatitos, con lo cual uno puede suponer que el proveedor los considera deshonestos a-priori, y por eso los obliga a usar mecanismos que garanticen la honestidad. Una especie de cinturón de castidad informático.
Mi programa después de muchos esfuerzos y no pocas cavilaciones ya estaba tomando forma. Todas las partes importantes estaban funcionando. Era hora de ir pensando en esos critters copiadores ilegales que se apoderarían de mi tan preciado trabajo. Yo no los iba a dejar que les sea tan fácil.
Una llave de hardware —como se llamaban esos aparatitos que se enchufaban en el puerto paralelo de la pc— no estaba al alcance de mi presupuesto. Comprar las llaves a una empresa para proteger mi software no me pareció muy ético desde lo geek. ¿Cómo comprar algo que yo podía soñar en hacer en el futuro? Empecemos por algo de hardware que tengo a mano.
Algunos programas basaban su protección en un disquete de instalación especial que era incopiable y que debía estar disponible en algunos casos en la unidad para que el programa funcione. ¿Incopiable? La superficie del disquete tenía un área dañada cuidadosamente con un láser, lo cual impedía que los programas de copia del sistema operativo los pudiesen copiar. ¿Copiarlos a bajo nivel, sector por sector? Se podía, pero cuando el programa de instalación se ejecutaba, buscaba los sectores dañados y si no los encuentra, fracasa la instalación. Una malvada e interesante idea.
Decidí adaptarla a mis necesidades tercermundistas. Tomé un disquete de 51/4″ y una fina aguja de coser y le realicé un minúsculo orificio. Luego lo puse a leer con mi programa en C a bajo nivel, esperando el error para tomar nota del número de sector. con el número de sector podía generar un ejecutable con ese dato, que sería el único funcional en ese disquete. Mua, ja, ja, ja.
Pero no apareció ningún error. Sorpresa. La combinación BIOS y controladora de la disquetera, al parecer dejaban los flags de la CPU con el indicador del problema. El código de la función C biosdisk() que llama a la BIOS descarta las flags, pues usa el valor del registro AH para averiguar si hubo errores (no voy a entrar en más detalles).
¡Tengo los fuentes! Corrijo el código y tema resuelto. No. No se puede. No es legal que yo tome código de Borland, lo modifique y lo distribuya.
Un compilador libre de C
DJ Delorie escribe un compilador de C para MSDOS compatible con GCC llamado djgpp. 1993 es cuando en las BBS de Buenos Aires y en las revistas del ramo aparecen programas shareware y otras formas de comercialización del tipo pruebe antes de pagar. Entre esos CDs encuentro el djgpp. ¡Es gratis! No tiene el IDE de Borland, pero estoy acostumbrado a las interfaces de mandatos, así que no es problema.
Uno de los proyectos relacionados es go32, un DOS EXTENDER. No importa si no sabes que es eso, es una antigüedad. Servía para que tu programa en C o assembler acceda a los 4 gigabytes en una CPU 386. ¡Eureka! Es lo que necesito para mis arrays de más de 640kbytes.
Un momento. djgpp no es gratis; go32 tampoco
Son software libre.
¿Que es eso del software libre?
En el caso del djgpp, si yo escribo mis programas y los compilo con djgpp puedo hacer lo que me plazca con los binarios, por ejemplos entregarlos como software privativo, como todas las empresas que conocía.
En el caso de go32 es diferente. La licencia dice que si yo entrego el binario de go32 con un programa binario que lo usa, debo también entregar los fuentes de mi programa al cliente. ¡Queee! ¡What!
¿Porqué voy a entregar mis fuentes? No se quién los va a recibir, ¿y si no los cuida? ¿y si los regala? ¿y si los vende? (OK, este último caso con los bingos no iba a suceder porque el software era parte de la ventaja competitiva de la empresa).
La verdad de la historia: ¿y si llama a otro para que lo modifique o lo expanda? Entonces no voy a ver un peso más…
Legalmente
Me porté bien, hice las tareas, puse los puntos a las íes y los palitos a las tes. Compré la licencia de un software privativo que no tiene todo lo que necesito, y no me deja corregir lo que no me funciona.
El software libre tiene todo eso resuelto, y además es gratis.
El software privativo me llena de obligaciones orientadas a que yo sea un tipo egoista. Que obligue a mi cliente a ser mi vasallo, a depender de mí. Que vea a mis amigos programadores como enemigos.
El software libre me llena de obligaciones orientadas a que yo sea un tipo altruista. Que convenza a mi cliente de ser mi socio. Que vea a mis amigos programadores como ayudadores.
Tengo que decidir que voy a hacer con mi programa: o mantengo el control completo de una cosa muy pequeñita, o suelto el control y hago las cosas en grande.
Es desagradable cambiar
Cuando uno se equivoca, debe tener el coraje de cambiar. Hacer penitencia es hacer un giro de 180 grados, volver el camino, no es pegarse con un látigo.
La solución para mi cliente
Escribí el software con la mejor herramienta que encontré, para el problema que tenía, y se lo entregué. La licencia fue una de software libre, porque me gusta hacer las cosas por derecha.
Más tarde ese cliente me buscó en varias oportunidades para resolver otros problemas, y para adaptar este. Los otros programadores no le vendían libertad. Sin querer, la libertad de la licencia fue un punto de valor en mi oferta. Un elemento diferenciador de mi competencia.
La idea de compartir te come la cabeza
En el jardín de infantes somos naturalmente egoistas. Sin embargo al crecer nos enseñan a compartir y poner primero a los demás. Cuando pasa más el tiempo, en el mercado laboral volvemos al jardín, abandonamos los logros del crecimiento. Puede sonar simple e ingenuo lo siguiente, y aún así me atrevo a enunciarlo, copiándolo del Maestro por excelencia:
Hay más bendición en dar que en recibir.
–Hechos 20:35
Por la negativa: aprovecharte de los demás, nos hace más pobres a todos.
Así que, todo lo que quieran que la gente haga con ustedes,
eso mismo hagan ustedes con ellos, porque en esto se resumen la ley y los profetas.
–Mateo 7:12
¿Cómo quiero que me trate mi proveedor de software? ¿Quiero que me imponga licencias y llaves de hardware para cuidarse porque supone que soy un tipo deshonesto? ¿Quiero depender de sus caprichos para arreglar o modificar programas? ¿Como compañeros de trabajo en la tarea de atender a mis clientes?
¿Cómo quiero tratar a mis clientes? ¿Como antagonistas? ¿Como socios?
No todos los clientes entienden estos términos la primera vez que los hablamos, y muchos alegan que son secundarios y no les importan. La verdad es que están usando gran cantidad de software libre porque si les importa la diferencia, aunque todavía algunos no entienden la relación de causa efecto entre las libertades del software y la vitalidad y calidad de lo que están utilizando en sus empresas.
Instalo GNU/Linux en mi pc
Es una 386, ya es 1995. El software libre es el nirvana del programador: casi cada lenguaje que te imagines, tiene un entorno de desarrollo que corre sobre GNU/Linux.
1995 es también el año en que conecto mi casa a la Internet.
La Web y GNU/Linux en cierto modo crecieron juntos. GNU/Linux y el software libre (apache, sendmail, bind) proporcionaron módulos esenciales para la infraestructura de la Web. La Web y el correo electrónico proveyeron la infraestructura para el desarrollo colaborativo del núcleo Linux, y de la adopción del sistema GNU (incompleto por la falta del núcleo). Juntos formaron un sistema GNU/Linux.
Linus Torvalds siempre tiene el crédito por Linux, por haber iniciado su desarrollo. Pero ese experimento de un estudiante finlandés hubiera quedado en el olvido a no ser por dos elementos decisivos: el sistema GNU incompleto pero muy avanzado y la Internet. Sobre esos dos fundamentos, Linus creó la «máquina de hacer Linux». Su gran aporte no es la versión inicial de Linux, de la cual deben quedar muy pocas líneas vigentes en la actualidad. El gran aporte de Linus Torvalds fue la creación de un sistema de desarrollo colaborativo que permitió explotar la actividad de varios cientos de personas muy capaces, interesadas en trabajar en algo que pudieran usar y que no sea apropiado por una empresa y luego vedado.
Mientras, en un conocido rincón de ciudad Gótica
En Santa Fe y Paraná, Argentina, algunos geeks se conocían merced a la Universidad Nacional del Litoral, primer centro educativo con Internet en Santa Fe. La subcultura Unix estaba pegando en muchos, el MSDOS no daba para más. Nos conocimos en una lista de correos, nos juntamos a comer pizzas.
Empezamos a salir de Santa Fe y dar charlas en otras ciudades. Conocimos a otros geeks. Guau, conocimos la palabra «geek». Como dice el dicho: «Dios los cría y el viento los amontona».
El viento estaba soplando.
Ese mismo viento acaricia tu mente en este momento.
¿A qué te vas a dedicar en tu vida profesional?
Nos leemos…
Referencias
https://www.biblegateway.com/passage/?search=Hechos%2020:35&version=RVC
https://www.biblegateway.com/passage/?search=mateo+7%3A12&version=RVC
Topics: charlas, GPL, personal, rant, software libre | No Comments »
SCO Unix sobre qemu: bonus
By cesar | julio 2, 2013
Si instalaste SCO Unix como se describe en la entraga anterior, es posible que las siguientes utilidades te sean de ayuda.
Instalación de putty en GNU/Linux
El primer programa será para instalar en nuestra pc. Los programas gráficos konsole y gnome-terminal tienen el defecto que no se ven bien con la terminal típica de los sistemas SCO que es scoansi. Sin embargo putty es un programa libre de emulación de terminales muy cuidado, con u completo soporte para SCO.
Instalamos los paquetes en nuestro Debian GNU/Linux:
| Bash | | copy code | | ? |
| 1 | apt-get install putty putty-tools |
Para configurar la sesión, hay que retocar algunos valores. Supongamos que deseamos acceder a un sistema SCO antiguo, que no tiene SSH y debemos utilizar telnet:
- telnet (puerto 23)
- host name or ip address: IP_SCO
- nombre conexión: srv_produccion
- keyboard:
- Backspace -> Ctrl-H
- Function keys: SCO
- Window
- Display scroll bar: OFF
- Appearance:
- Cursor appearance: Block
- Cursor blinks: ON
- Translation:
- Remote character set: ISO-8859-1
- Handling of line drawing characters: Poor’s man line drawing
- Fonts: Font used for ordinary text: client:FreeMono 16
rsync para SCO Unix
Cuando instalas un servidor a nuevo, lo siguiente es copiarle archivos de datos, programas fuentes, y perfiles de usuarios. rsync es una herramienta ideal para esa tarea, ya que puede continuar una copia interrrumpida, sin necesidad de recomenzarla desde el principio.
Vamos a instalar rsync en el SCO Unix.
Lo descargamos en nuestra pc:
| Bash | | copy code | | ? |
| 1 | wget http://www.aljex.com/bkw/sco/rsync.tar.bz2 |
Lo copiamos al sistema SCO:
| Bash | | copy code | | ? |
| 1 | scp rsync.tar.bz2 root@IP_SCO:/tmp |
Descomprimirlo y desempaquetarlo con:
| Bash | | copy code | | ? |
| 1 | bunzip2 /tmp/rsync.tar.bz2 |
| 2 | cd / |
| 3 | tar xvf /tmp/rsync.tar |
El programa queda instalado en /usr/local/bin/rsync.
Cuando lo queremos usar desde nuestra pc, podemos hacer, por ejemplo:
| Bash | | copy code | | ? |
| 1 | rsync -Pav --rsync-path=/usr/local/bin/rsync root@IP_SCO:/tmp /tmp/ |
Instalación de RM COBOL 85 sobre SCO Unix 3.2 2
El RM COBOL 85 que me tocó instalar venía en disquetes de 3.5 pulgadas. Si, leiste bien, disquetes. Dos disquetes para el compilador, y dos para el runtime. Menos mal que pude conseguir una disquetera externa conectable mediante USB.
Los disquetes están en formato cpio, que son una especie de archivo multiparte.
La secuencia de instalación, será la siguiente: pasamos los disquetes a imágenes binarias, subimos las imágenes al SCO virtualizado, y las desempaquetamos, luego corremos el programa de instalación.
Vamos a crear la imágenes con dd en GNU/Linux. Si no tienen un GNU/Linux y usas MS Windows, pues, lo lamento por tí, pero igual puedes obtener las imágenes mediante rawread[1].
Para no mezclar las imágenes, utilicé nombres descriptivos en los archivos:
rmcobol85-development-v6.06.01-scounix-v3.2.2-disk-1-of-2.imgrmcobol85-development-v6.06.01-scounix-v3.2.2-disk-2-of-2.imgrmcobol85-runtime-v6.06.01-scounix-v3.2.2-disk-1-of-2.imgrmcobol85-runtime-v6.06.01-scounix-v3.2.2-disk-2-of-2.img
Creamos en el SCO un directorio para contener los archivos desempaquetados a partir de los disquetes:
| Bash | | copy code | | ? |
| 1 | mkdir /usr/local/rmcobol |
Copiamos las imágenes de los disquetes a ese directorio, por ejemplo usando SCP o NFS, al directorio /tmp del SCO.
Desempaquetamos los archivos cpio:
| Bash | | copy code | | ? |
| 1 | cd /usr/local/rmcobol |
| 2 | cpio -ivcmB < /tmp/rmcobol85-development-v6.06.01-scounix-v3.2.2-disk-1-of-2.img |
| 3 | cpio -ivcmB < /tmp/rmcobol85-development-v6.06.01-scounix-v3.2.2-disk-2-of-2.img |
Si los disquetes se hubieran insertado en la disquetera física de una máquina física, el mandato hubiera sido:
| sh | | copy code | | ? |
| 1 | cpio -ivcmB < /dev/dsk/f0q18dt |
Y con un 1 en vez de un 0 si es la segunda disquetera.
Corremos el programa de instalación:
| sh | | copy code | | ? |
| 1 | ./rminstall |
Este programa copia archivos en /usr/bin/. Los instaladores de antaño eran así de mal comportados. Ahora se esperaría que use /usr/local/.
Esto muestra en pantalla lo siguiente:
| Text | | copy code | | ? |
| 01 | |
| 02 | Installation of RM/COBOL-85 |
| 03 | |
| 04 | You Must be Super User (root) To install This Product |
| 05 | (press system cancel key to abort) |
| 06 | |
| 07 | Press Return To Continue: |
| 08 | Unzipping compressed files... |
| 09 | Installing compiler into /usr/bin... |
| 10 | Installing runtime into /usr/bin... |
Cuando te haga la siguiente pregunta, responde con terminfo, que es la alternativa moderna de gestión de capacidades para terminales.
Which version of the runtime/recover1 do you want to install, (terminfo or termcap)?
Y por último muestra:
Installation complete!
Conclusión
Hemos instalado ciertos programas que facilitan el trabajo con sistemas SCO Unix heredados.
Sinceramente espero que nunca los tengas que usar, y que aproveches tu vida en cosas más modernas y cool.
Nos leemos…
Referencias
[1] http://iutsa.unice.fr/~frati/_TOOLS/zip+iso+boot/rawrite/Rawrite-Rawread.htm
Topics: SCO Unix, sysadmin | No Comments »
Vino viejo en odres nuevos: SCO Unix sobre qemu
By cesar | julio 2, 2013
SCO Unix
Comentaba en una entrada anterior que mis comienzos sonre sistemas U*ix estuvieron relacionados con los sistemas operativos de la empresa Santa Cruz Operations (SCO) [1]. En particular SCO Xenix y SCO Unix, luego SCO OpenServer y por último SCO Unixware.
En 2002, SCO fue adquirida por una firma de abogados de Utah [2], con el objetivo de usar sus derechos de copia del núcleo Unix para parasitar el éxito de los núcleos Linux y cobrar regalías sobre los sistemas GNU/Linux. En particular, iniciaron un juicio contra IBM por mil millones de dólares y comenzaron a mandar cartas amenazadoras a las empresas más grandes que usaban sistemas GNU/Linux con la propuesta de comprar un sistema de «protección» anti demandas legales. Usted ya conoce como es esto. Cuando uno tiene poder de causar daño y pide que usted pague a cambio de la protección de esos posibles daños. No faltó quien se atemorizara y pagara. Los demás esperábamos sin temblar: o la comunidad organizaba una defensa o IBM iba a oscurecer el cielo con abogados cayendo sobre Utah. Al final fue ambas cosas.
En 2007 SCO Group pidió la protección del Capítulo 11, básicamente declarándose en quiebra. Los detalles se pueden seguir cronológicamente en [2] y en Groklaw[3].
De multiusuario a desparramado
Durante la década de 1990, muchas empresas han tenido a SCO Unix como el sistema operativo multiusuario corporativo de elección. La robusteza del sistema, apoyado en servidores basados en procesadores Intel de gama media y alta, con equipos de calidad empresarial de Hewlett Packard, IBM, Compaq, Everex, y otros, da como resultado que hoy en día muchas aplicaciones corporativas todavía están operativas. O sea, están operativas como cuando se las instaló hace más de 15 años. Mismo hardware, mismo sistema operativo. Tal vez con el tiempo se han abandonado las terminales alfanuméricas por terminales de clientes delgados o pcs con un programa de telnet. Pero los servidores siguen rotando sus discos, y los programas RM COBOL 85 o SCO FoxBase siguen interactuando con el personal de carga de datos.
Era plena época de fama del MS DOS y los centros de cómputo sentían la presión y el embate de las microcomputadoras (como se llamaba a las pc en aquella época). Un contador o abogado, podía entonces aprender a usar una planilla de cálculos y hacer sus propios reportes, gráficos, y análisis de datos, sin necesidad de rogar a los desarrolladores de la «caja de cristal» donde se alojaba el mainframe.
Bastaba una pc con MS DOS, un LOTUS 123 y un programa de terminal serie con captura de datos. El contador se conectaba al sistema Unix con el emulador de terminal, activaba la captura de datos en la pc y ejecutaba los listados en pantalla del Unix, los cuales quedaban disponibles en la pc para convertirlos a la planilla LOTUS. Fue la milicia feudal atacando el castillo del rey. Cada señor feudal tenía una pc, empezó a cercar sus datos, y de esa manera tuvo su coto de caza privado con la información de la empresa, y esa información le otorgó poder. Al menos poder de impedir, sino de hacer. Los sistemas se dividieron y hubo que esperar hasta la ola del data mining para volver a tener una visión global de la organización. Y hasta donde sé, tampoco se logró en todas las organizaciones.
Los sistemas eran multiusuario, luego de esto se transformaron en sistemas desparramados. No uso la expresión «sistemas distribuídos» porque ésta conlleva la idea de un plan, y un propósito unificador. El desparramo de sistemas que provocó la pc fue debido a la lentitud y/o inoperancia de los antiguos centros de cómputo para dar respuesta en los tiempos que las gerencias requerían para su toma de decisiones. Se entronó al dato por sobre el sistema que obtiene el dato.
Sin embargo, las funciones de operación siguieron en el centro de cómputos. La carga de datos, validación, informes periódicos, consultas preprogramadas, todas ellas siguieron en los servidores centrales.
Los bytes no envejecen, los proveedores sí
El problema se da cuando el proveedor discontinúa el software que utilizamos. Si un pintor famoso muere, no habrá nuevas obras, y eso hace que sus obras aumenten de precio en el mercado. En el caso de una empresa de software, si deja de producir nuevas versiones de un programa, el programa abandonado ya no vale nada.
A principios de los 1990 me tocó tomar la decisión de elegir un procesador de textos y una planilla de cálculos para usar en las terminales alfanuméricas, conectadas a los servidores multiusuario corporativos con SCO Unix en una empresa importante de mi ciudad natal. Una docena de servidores daría potencia de trabajo a unos 400 usuarios. La planilla de cálculo era una decisión simple: LOTUS 123. El procesador de textos no era tan fácil, pero bueno, «nunca se ha despedido a nadie por comprar equipos IBM» se puede traducir en el mundo de las pc con MS DOS, a «nunca se ha despedido a nadie por comprar software Microsoft», así que SCO Word 5.0 fue la elección. Microsoft fue uno de los colaboradores del desarrollo de SCO Xenix, así que algo de inversión en esto tiene. El MS Word 5.0 para SCO Unix puede grabar en el formato de MS Word 5.0 para MS DOS. Todos podemos formar una feliz familia corporativa.
Cuando salió la versión de SCO con binarios ELF y bibliotecas compartidas, los binarios de SCO Word en formato a.out no corrían en el nuevo sistema operativo. No importa, es una gran empresa como dije, no hay problemas en gastar nuevamente el precio de la docena de licencias y adquirir los binarios para la nueva versión. Oh, oh. Es mediados de los 1990 y a Microsoft no le interesa más el mercado de los procesadores de texto en terminales alfanuméricas, por ello: no hay más opción.
Jaque.
Bueno, sí la hay. Podemos dejar algunos de los servidores con la vieja versión de SCO que corre el SCO Word y actualizar los otros servidores con los sistemas de bases de datos y aplicaciones. Los servidores son equipos con procesadores 386sx y otros con 386. Andan muy bien.
El tiempo pasa, uno de los equipos con 386 se quema. El dinero no es problema, recuerdan que es una gran empresa. Se compra un servidor al estado del arte. Se buscan los disquetes del viejo SCO con binarios a.out y se instalan. Esteeee, no, no se puede instalar. La motherboard del nuevo equipo tiene un chipset y tarjetas SCSI para los cuales no hay drivers en el viejo SCO.
El SCO Word requiere un sistema operativo que no se puede instalar en los equipos que podés comprar.
Jaque.
Luego Microsoft saca el MS Word 6.0 sobre MS Windows 3.1. El MS Word 6.0 no puede leer el formato de 5.0 para MS DOS, que es el que puede escribir el SCO Word.
La tierra informática se fractura y un abismo separa a los usuarios de procesador de texto de MS Word 6.0 para MS Windows 3.1 y los que todavía usan terminales alfanuméricas.
Jaque mate.
Lo único que se puede hacer es eliminar los procesadores de texto sobre SCO. Claro que eso implica perder años de documentos corporativos, porque no se pueden leer con la versión de MS Windows.
Se podría hacer un proyecto de migración de formato usando la versión 5.0 de MS DOS como puente a la versión 2.0 de MS Windows, y de allí a la versión 6.0 para MS Windows. Pero uno se pregunta, ¿porqué una empresa debe pagar semejante proyecto de migración de datos propios? La respuesta es simple: la información era propia, pero una vez que los datos se guardaron en un formato secreto y privativo, quedaron secuestrados en poder del programa que los puede leer. La importancia de los formatos abiertos es tema para otra entrega, pero aquí se puede vislumbrar lo que sucede cuando renunciamos a nuestra libertad de formato, en pos de un programa bonito y popular, pero que es privativo. Cuando menos lo pensamos, perdemos el programa, y perdemos los datos también.
Sistemas SCO en la actualidad
Los casos populares de utilización de SCO Unix eran aquellos en los cuales los sistemas estaban desarrollados por ejemplo con RM COBOL 85[5], Informix[6,7], PROGRESS 4GL[8,9] o SCO FoxBase, con accesos mediante terminales alfanuméricas o telnet sobre TCP/IP, e impresoras de red.
Muchos de estos sistemas construídos en 1990 o poco después todavía están en funcionamiento. Modificación tras modificación, los desarrolladores han quedado pegados a esos entornos como los insectos en la drosera[10]. La aplicación funciona, hay mucho invertido en ella y no vale la pena rescribirla en un lenguaje o entorno de aplicación moderno.
Mientras conseguimos los binarios para el compilador y el runtime de la aplicación, sea que siguen funcionando los viejos o adquirimos licencias para binarios más modernos, la calesita sigue girando y todos contentos.
Hasta que el hardware moderno no nos permite instalar los binarios de nuestro sistema operativo, o no tiene soporte para discos SATA, o … una larga lista de drivers que no están.
Por supuesto que se pueden adquirir licencias con binarios nuevos de la nueva empresa detrás de esos sistemas operativos, llamada XINUOS[11]. Eso sería seguir gastando dinero en un programa que ha pasado de mano en mano muchas veces. La verdad es que no resulta atrayente.
Una alternativa: migrar a GNU/Linux
Ya nombramos la empresa Micro Focus que vende un compilador de ACU COBOL para GNU/Linux, el cual puede compilar los fuentes de RM COBOL 85, casi sin modificarlos. Informix provee binarios para GNU/Linux, al igual que PROGRESS. SCO FoxBase puede emularse mediante Linux ABI (Application Binary Interface).
Entonces el proyecto de salir de SCO sobre hardware obsoleto puede ser moverse hacia GNU/Linux sobre hardware moderno.
Otra alternativa: virtualizar SCO
Lo cual nos lleva al tema técnico de esta entrega.
Hasta ahora había fracasado en los intentos que hice de virtualizar versiones antiguas de SCO Unix y SCO OpenServer.
Ya no más. Con SCO OpenServer 5.0.7 y qemu 1.1.2 fue un éxito.
La virtualización te da varias posibilidades:
- seguir con el viejo sistema hasta que sea prudente pensar en una rescritura.
- utilizar el viejo sistema para poner en producción el nuevo en paralelo
- crear una copia virtualizada para que los desarrolladores del nuevo sistema tengan un arenero donde jugar sin romper los datos en producción.
Cómo virtualizar con GUI
En otras entregas hemos virtualizado mediante la línea de mandatos. Para variar hoy utilizaremos una interfaz gráfica.
Instalamos los paquetes necesarios:
| Bash | | copy code | | ? |
| 1 | apt-get install virt-manager kvm |
Verificamos si disponemos de soporte para virtualización por hardware:
| Bash | | copy code | | ? |
| 1 | egrep '(vmx|svm)' --color=always /proc/cpuinfo |
Es importante que dispongamos de esta característica en la CPU de nuestro sistema de virtualización, porque eso aumenta la velocidad de los sistemas virtualizados.
Una vez instalados los paquetes, podemos verificar que el soporte de virtualización qemu está disponible, mediante:
| Bash | | copy code | | ? |
| 1 | virsh -c qemu:///system list |
La conexión tendrá éxito, aunque, es obvio, mostrará una lista vacía de máquinas virtuales.
Ahora, configuramos la placa Ethernet en modo bridge, para eso en nuestro Debian editamos /etc/network/interfaces y dejamos:
| interfaces | | copy code | | ? |
| 01 | ## en modo bridge: |
| 02 | auto eth0 |
| 03 | iface eth0 inet manual |
| 04 | |
| 05 | auto br0 |
| 06 | iface br0 inet static |
| 07 | address IP_HOST |
| 08 | netmask 255.255.255.0 |
| 09 | gateway GW_HOST |
| 10 | network NETWORK_HOST |
| 11 | broadcast BROADCAST_HOST |
| 12 | dns-nameservers NAMESERVER_HOST |
| 13 | dns-domain DOMAIN.HOST |
| 14 | dns-search DOMAIN.HOST |
| 15 | bridge_ports eth0 |
| 16 | bridge_fd 9 |
| 17 | bridge_hello 2 |
| 18 | bridge_maxage 12 |
| 19 | bridge_stp off |
Reiniciamos la red para que los cambios tomen efecto:
| Bash | | copy code | | ? |
| 1 | /etc/init.d/networking restart |
La cuenta que vamos a usar para crear las máquinas virtuales, supongamos que es cesarballardini, entonces debemos agregarla al grupo libvirt:
usermod --append --groups libvirt cesarballardini
Sólo nos queda iniciar virt-manager y en la ventana que se abre elegir una nueva máquina virtual, asignarle por ejemplo 20 Gbytes de disco, 128 Mbytes de RAM, conectarle la imagen de instalación de SCO, y una placa de red pcnet. Presta atención de nuevo: la placa de red es pcnet.
El sistema se instala como le es usual, y pide las credenciales de la licencia que has adquirido previamente. Cuando temina lo tienes listo para funcionar.
Conclusiones
Se puede tener corriendo una versión razonablemente moderna de SCO OpenServer en un entorno de virtualización libre como qemu.
Si me pides un consejo, te diría: «no lo hagas». Migra las aplicaciones para que corran nativas sobre GNU/Linux. Más aún, usa lenguajes de programación, y herramientas de trabajo que sean libres.
Como siempre, haz lo que quieras. O lo que puedas.
Nos leemos…
Referencias
[1] https://en.wikipedia.org/wiki/Santa_Cruz_Operation
[2] https://en.wikipedia.org/wiki/SCO_Group
[3] http://www.groklaw.net/staticpages/index.php?page=20061212211835541
[4] http://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt#Definition
[5] http://www.microfocus.com/products/micro-focus-developer/rm-cobol/ RM COBOL 85 era propiedad de Liant Software Corporation, fundada en 1970 como Ryan McFarland Corp.. En 2008 Micro Focus compra Liant. Micro Focus es la proveedora de ACU COBOL, un compilador nativo recomendado para sistemas GNU/Linux.
[6] http://es.wikipedia.org/wiki/Informix
[7] http://en.wikipedia.org/wiki/Informix_Corporation creada en 1980 y vendida a IBM en 2001
[8] http://en.wikipedia.org/wiki/Progress_Software un poco de historia
[9] http://www.progress.com/ homepage; el PROGRESS 4GL de los 1990, se ha remozado y renombrado a OpenEdge.
[10] http://es.wikipedia.org/wiki/Drosera
Topics: KVM, SCO Unix, sysadmin | No Comments »