sábado, 27 de diciembre de 2008

Historia de Unix (parte 1)

Historia de Unix

Linux es, hoy en día, uno de los sistemas operativos para computadoras personales, estaciones de trabajo y otras computadoras, de mayor confiabilidad en el mercado. Puede parecer para muchos, conociendo el origen humilde de este sistema, impresionante como es que a partir de esfuerzos aislados geográficamente de miles de personas en apariencia poco coordinadas, que un sistema así pueda llegar al nivel de calidad que el que Linux y sus aplicaciones tienen hoy en día. Sin embargo, como es común en estas situaciones, es mi opinión que todos somos producto de nuestra historia, y Linux no es la excepción. Tanto la esencia del sistema, basada en el clásico Unix que ha perdurado por décadas, como el método de desarrollo que Linux llevó al éxito son, entre otras cosas, la consecuencia obvia de la historia que llevó a los personajes de la historia de Unix a involucrarse en la historia misma de Linux.

"The Art of UNIX Programming" (TAOUP, 'El arte de programar en UNIX') es un libro publicado por Addison y Wesley en el año 2004, escrito por Eric S. Raymond (sitio de internet: http://www.catb.org/esr), un hacker considerado por muchos como el antropólogo e historiador del movimiento hoy conocido como 'Open Source'. Raymond es autor también de importantísimos ensayos en este aspecto: 'La Catedral y el Bazar' (1997), llevó en el año 1998 a la compañía Netscape a liberar el código de su navegador de internet Mozilla (el ancestro del tan de moda hoy en día Firefox), y con ello vino el éxito comercial y financiero que también ha acompañado al 'código abierto' y al 'software libre' tal como los conocemos hoy (véanse los casos de Linux, GNU, Apache, X, Perl, Python, y un largo etcétera).

Por un lado, la filosofía de programación de Unix, que convoca a métodos sencillos, modulares y reutilizables, entre otras características. Por el otro, la metodología de desarrollo 'abierta', o de 'bazar', característica de proyectos como la Wikipedia (http://wikipedia.org), en donde la 'revisión por pares' se convierte en la esencia del funcionamiento y la calidad de estos proyectos. Y además, la actitud hacker, la de superarse siempre, la de no conformarse con las cosas mal hechas sino mejorarlas, la de, por lo tanto, buscar siempre utilizar y reutilizar sobre plataformas que garanticen esa calidad. Todos estos aspectos, y otros más, se retratan de manera muy concreta en el capítulo 2 del libro TAOUP.

Esta serie de posts son mi traducción personal a este capítulo. Pueden ser vistos en mi blog en Blogger (http://jstitch.blogspot.com/), así como en el de Wordpress (http://jstitch.wordpress.com/). Debo mencionar, que el libro 'The Art of UNIX Programming' está sujeto a los términos de la licencia Creative Commons Attribution-NoDerivs 1.0 (que puede ser leída en http://creativecommons.org/licenses/by-nd/1.0/legalcode), con la estipulación extra de que el derecho a publicar en papel para fines de lucro, se reserva para Pearson Education, Inc. En pláticas vía email con Mark Taub, encargado de los derechos de traducción de Addison-Wesley, obtuve el derecho para traducir el capítulo 2 del libro TAOUP, y de publicarlo únicamente en las direcciones de internet pertenecientes a mis dos blogs antes citados. Mi intención al traducir y publicar en web la traducción del capítulo 2 de TAOUP es difundir también en el habla hispana parte de la sabiduría contenida en este libro, y qué mejor que el capítulo 2, que habla de la historia y los orígenes de Unix para entender mejor el por qué y el cómo es que se ha llegado hasta donde hoy en día (2008) se ha llegado en Linux, el código abierto, el software libre y demás conceptos relacionados. Por ello, hago aviso de estas estipulaciones de licencia, y no me hago responsable por el uso que se haga de la información de los posts relativos a mi traducción, aunque espero que el propósito inicial de servir como medio de difusión se mantenga siempre puro. Nótese, claro está, que estas advertencias mías no están ni deben interpretarse como que están por encima de lo estipulado en la licencia Creative Commons-NoDerivs 1.0, ni en el derecho de Pearson Education, Inc. a publicarlo en papel para fines de lucro, ni en el permiso que Mark Taub tan amablemente me concedió de publicar por medio electrónico la traducción del capítulo 2 de TAOUP únicamente en mis dos blogs que ya mencioné. Con respecto a las imágenes utilizadas a lo largo de la traducción, fueron sacadas del sitio en línea del libro (http://www.catb.org/esr/writings/taoup/), y los créditos y restricciones de las mismas son idénticos a los del sitio antes mencionado.

Por último, he de decir que, aunque la traducción que propongo pretende ser lo más fiel posible al texto original (véase http://www.catb.org/esr/writings/taoup/translation.html para las notas del autor con respecto a lo que el autor mismo requeriría para una buena traducción), siempre he intentado reflejar en lo que hago el proceso mental que me llevó a ello (podrían preguntar a mis colegas por mi afición para comentar y documentar el código que yo escribo ;-). Es por ello que dentro de la traducción incluyo notas propias, referenciadas dentro del texto principal como pies de sección a través de la marca [NT#], donde '#' es un número consecutivo a partir de 1. Mi intención de estas notas es únicamente reflejar el reto que para mí ha implicado la traducción lo más fiel posible del texto, incluyendo sobre todo el sentido de las frases encontradas en la versión original en inglés, más que la traducción literal del texto, que por demás está decirlo, muchas veces produce traducciones de muy pobre calidad. Esta es mi primer traducción 'formal' de un texto, con eso de que se incluye la licencia y todo eso, y por ello la emoción me ganó para incluir dichas notas. Con respecto a las notas a pie de sección, decidí mantener la numeración original del texto, a pesar de que estos posts sólo incluirán el capítulo 2 del libro, por lo que no debe de extrañar que la numeración no comience con '1'.

Ahora sí, dicho todo esto, comencemos pues...

Atte.
Javier Novoa Cataño (jstitch)






Capítulo 2. Historia
Un recuento de dos culturas

Tabla de Contenido
Orígenes e Historia de Unix, 1969 - 1995
Génesis: 1969 - 1971
Éxodo: 1971 - 1980
TCP/IP y las Guerras Unix [NT1]: 1980 - 1990
Nosotros Venceremos [NT2]: 1991 - 1995

Orígenes e Historia de los Hackers, 1961 - 1995
Jugando en el recinto universitario [NT3]: 1961 - 1980
Fusión con Internet y el Movimiento del Software Libre: 1981 - 1991
Linux y la Reacción Pragmática: 1991 - 1998

El movimiento Open-Source (Código Abierto): 1998 y siguientes

Lecciones de la historia de Unix



Aquellos que no pueden recordar el pasado están condenados a repetirlo
-- Jorge Santayana [NT4] - The Life of Reason (1905)

El pasado informa de la práctica. Unix tiene una larga y colorida historia, mucha de la cual aún está viva como folclore, presuposiciones y (muy seguido) cicatrices de guerra en la memoria colectiva de los programadores Unix. En este capítulo, examinaremos la historia de Unix, desde un punto de vista para explicar el porque, en 2003, la cultura Unix se ve de la forma que es.


Orígenes e Historia de Unix, 1969 - 1995

Un notorio 'efecto del segundo sistema' aflige seguido a los sucesores de pequeños prototipos experimentales. La urgencia de incluir todo lo que no se incluyó la primera vez frecuentemente lleva a un diseño gigante y sobre complicado. Menos conocido aún, por lo menos común, es el 'efecto del tercer sistema'; algunas veces, luego de que el segundo sistema se colapsa por su propio peso, hay posibilidades de regresar a la simplicidad y hacerlo todo bien esta vez.

El Unix original era un tercer sistema. Su abuelo era el pequeño y sencillo Sistema de Tiempo Compartido Compatible (CTSS, Compatible Time-Sharing System), el primer o segundo sistema de tiempo compartido de la historia (dependiendo algunas cuestiones de definición que determinadamente ignoraremos). Su padre fue el proyecto pionero Multics, un intento de crear una 'utilidad de información' llena de características que graciosamente soportaría tiempo compartido interactivo de computadoras centrales (mainframes) por parte de grandes comunidades de usuarios. Multics, desafortunadamente, de hecho se colapsó bajo su propio peso. Pero Unix nació de ese colapso.


Génesis: 1969 - 1971

Unix nació en 1969 de la mente de un científico de la computación de los Laboratorios Bell (Bell Labs), Ken Thompson. Thompson fue un investigador en el proyecto Multics, una experiencia que lo desilusionó del primitivo cómputo por lotes que era común prácticamente en todos lados. Pero el concepto de tiempo compartido aún era nuevo a finales de los 60's; las primeras especulaciones apenas fueron formuladas diez años antes por el científico de la computación John McCarthy (el inventor del lenguaje Lisp), la primer implantación de un sistema así fue hecha en 1962, siete años antes, y los sistemas operativos de tiempo compartido aún eran bestias experimentales y temperamentales.

El hardware de las computadoras era en ese tiempo más primitivo de lo que incluso lo que la gente que lo llegó a ver puede recordar fácilmente. Las máquinas más potentes de la época tenían menos potencia computacional y memoria interna que un típico teléfono móvil celular de hoy en día. [13] Las terminales de vídeo estaban en su infancia y no serían ampliamente implementadas hasta luego de otros seis años. El dispositivo de interacción estándar de los primeros sistemas de tiempo compartido era el teletipo ASR-33 - un dispositivo lento y ruidoso que imprimía solamente letras mayúsculas en grandes rollos de hojas amarillas. El ASR-33 fue el padre natural de la tradición en Unix de los comandos escasos y las respuestas concisas.

Cuando Laboratorios Bell se alejaron del consorcio de investigación de Multics, Ken Thompson se quedó con algunas ideas inspiradas en Multics sobre cómo construir un sistema de archivos. Así mismo se quedó sin una máquina en la cual jugar un juego que él había escrito, llamado Space Travel, una simulación de ciencia ficción que involucraba navegar con un cohete a través del sistema solar. Unix comenzó su vida en una minicomputadora PDP-7 limpiada [14], como la mostrada en la figura 2.1, como plataforma para el juego Space Travel y como zona de pruebas para las ideas de Thompson sobre diseño de sistemas operativos.

[Figura 2.1 la PDP-7]

La historia completa del origen se cuenta en [Ritchie79] desde el punto de vista del primer colaborador de Thompson, Dennis Ritchie, el hombre que sería conocido como el co-inventor de Unix y el inventor del lenguaje de programación C. Dennis Ritchie, Doug McIlroy, y unos pocos colegas se habían acostumbrado al cómputo interactivo bajo Multics y no querían perder esa posibilidad. El sistema operativo de Thompson en la PDP-7 les ofrecía una línea de vida [NT5].

Ritchie anota: "Lo que queríamos conservar no era sólo un buen ambiente en el cual programar, sino un sistema alrededor del cual una comunidad se pudiera formar. Sabíamos por experiencia que la esencia del cómputo comunal, tal como lo proveían las máquinas de acceso remoto y tiempo compartido, no estaba solamente en escribir programas en una terminal en vez de una tarjeta perforada, sino en reforzar la comunicación cercana". El tema de las computadoras vistas no solamente como dispositivos lógicos sino como núcleos de comunidades estaba en el aire; 1969 fue también el año en que ARPANET (el ancestro directo del Internet de hoy en día) fue inventada. El tema de "comunidad" resonaría por la historia de Unix de ahí en adelante.

La implementación de Space Travel por Thompson y Ritchie atrajo atención. Al inicio, el software de la PDP-7 tenía que ser pasado por un compilador cruzado en una mainframe GE. Los programas utilitarios que Thompson y Ritchie escribieron para soportar el desarrollo de juegos en la PDP-7 se convirtió en el núcleo de Unix - aunque el nombre no llegó sino hasta 1970. Originalmente, el nombre se deletreaba "UNICS" (UNiplexed Information and Computing Service, Servicio de Información y Cómputo UNiplexado), que posteriormente Ritchie describió como una "especie de broma truculenta sobre Multics", que significaba MULTiplexed Information and Computing Service (Servicio de Información y Cómputo MULTiplexado).

Incluso en sus etapas tempranas, el Unix de la PDP-7 tenía una fuerte semejanza a los Unixes de hoy en día, y proveía un ambiente de programación ligeramente más placentero que el que estaba disponible en cualquier otro lado en esos días de mainframes de proceso por lotes alimentadas por tarjetas perforadas. Unix estaba muy cerca de ser el primer sistema bajo el cual un programador podía sentarse directamente en la máquina y hacer programas al aire, explorando posibilidades y probando mientras componía. A lo largo de toda su vida, Unix se ha caracterizado por poseer un patrón que acrecienta las posibilidades atrayendo los esfuerzos de voluntarios hábiles a partir de programadores impacientes con las limitaciones de otros sistemas operativos. Este patrón se estableció temprano, inclusive dentro de los mismos Laboratorios Bell.

La tradición Unix de desarrollo ligero y métodos informales también comenzó desde sus inicios. En donde Multics fue un proyecto largo con miles de páginas con especificaciones técnicas escritas antes que se tuviera el hardware, el primer código de Unix fue inspirado por tres personas e implementado por Ken Thompson en dos días - en una máquina obsoleta que fue diseñada como terminal gráfica para una computadora 'real'.

El primer trabajo real de Unix, en 1971, fue soportar lo que hoy en día sería llamado procesamiento de palabras para el departamento de patentes de los Laboratorios Bell; la primera aplicación Unix fue el ancestro del formateador de textos nroff(1). Este proyecto permitió la justificación para la compra de una PDP-11, una minicomputadora mucho más capaz. La Administración se mantuvo dichosamente inadvertida del hecho de que el sistema de procesamiento de palabras que Thompson y colegas estaban construyendo estaba incubando un sistema operativo. Los sistemas operativos no estaban en los planes de los Laboratorios Bell - AT&T se unió al consorcio Multics precisamente para evitar desarrollar un sistema operativo por sí mismos. Aún así, el sistema terminado fue un éxito en ascenso. Estableció a Unix como una parte permanente y valorada de la ecología computacional en los Laboratorios Bell, y comenzó otro tema en la historia de Unix - una fuerte asociación con el formateo de documentos, tipografías y herramientas de comunicación. El manual de 1972 presumía de contar con 10 instalaciones.

Posteriormente, Doug McIlroy escribiría sobre este período [McIlroy91]: "La presión de los colegas y un simple orgullo en el trabajo hecho, provocaron que cantidades [NT6] de código fueran reescritas o desechadas conforme emergían ideas mejores o más elementales. La rivalidad profesional y la protección territorial eran prácticamente desconocidas: muchas cosas buenas estaban sucediendo que nadie necesitaba apropiarse las innovaciones". Pero tendría que ocurrir otro cuarto de siglo para que todas las implicaciones de esta observación llegaran a lugar.


Notas al pie de esta sección:
[13] Ken Thompson me recordó que los teléfonos móviles de hoy en día tienen más RAM que la PDP-7 tenía en RAM y espacio en disco juntos; un disco grande, en esos días, consistía en menos de un mega byte.

[14] Hay una FAQ en la Web sobre las computadoras PDP, que explica el papel, de otra forma extremadamente oscuro, en la historia de la PDP-7.


Referencias bibliográficas de esta sección:
[Ritchie79] Dennis M. Ritchie. The Evolution of the Unix Time-Sharing System. 1979. Disponible en la Red.

[McIlroy91] Proc. Virginia Computer Users Conference. Volume 21. M. D. McIlroy. "Unix on My Mind". p.1-6.


Notas de traducción de esta sección:
[NT1] Personalmente, el término 'Unix Wars' siempre se me ha hecho una referencia a 'Star Wars', una famosísima película de ficción en los 70s-80s. Sin embargo, la traducción al español de Star Wars es 'Guerras de las Galaxias', lo que no quedaría muy bien traducido como 'Guerras de Unix', por lo que me tomé la libertad de quitar la preposición 'de' para darle al título un aire más de ficción, al estilo del mismo título 'Unix Wars'. Una forma tal vez más correcta sería 'Guerras de los Unixes', pero al mismo tiempo tal vez esa traducción haría la analogía 'Star Wars' - 'Unix Wars' más evidente, siendo que esta relación es algo que yo personalmente he pensado, hasta estar seguro de la misma no intentaría establecer el término de manera definitiva.

[NT2] Con base en los comentarios de ESR en http://www.catb.org/esr/writings/taoup/translation.html, el nombre de esta sección quedó haciendo referencia a la rebeldía heroica, ya que 'Blows against the Empire', título de un álbum de Paul Kantner, anterior líder de Jefferson Airplane, no tiene (o no encontré una) traducción al español oficial para utilizar. 'Nosotros Venceremos', según Google, hace referencia tanto a una canción gospel del Rvdo. Charles Tindley, ('We shall overcome'), canto de protesta que se convirtió en himno del movimiento de derechos civiles en Estados Unidos. También se encuentran en Google referencias a un canto cristiano que hace referencia al éxito contra el mal, tomado como 'imperio' en el sentido que también se puede interpretar en el título en inglés original de esta sección.

[NT3] El original en inglés 'At Play in the Groves of Academe' (lit. 'Jugando en las arboledas de la universidad'), me da la impresión de ser una expresión local, por lo que busqué la forma de adaptarla a una expresión más genérica, pues en español no ubiqué ninguna expresión que pudiera equipararse a la original en inglés.

[NT4] Jorge Agustín Nicolás Ruiz de Santayana y Borrás, nacido en España, es mundialmente conocido como George Santayana.

[NT5] La 'línea de vida' ('lifeline' en el original), es una cuerda utilizada por los buzos y mineros, entre otros, para guiarse en el camino de regreso de las profundidades en las que se sumergen, a la Teseo en el laberinto del minotauro. No encontré traducción literal para 'lifeline', por lo que traduzco libremente aquí.

[NT6] El original en inglés dice 'gobs', que yo sustituyo de forma genérica por 'cantidades', al no encontrar una traducción más adecuada. Los 'gobs' son una forma en que se conoce comúnmente a los restos desechables del carbón en una mina.




--
Eru kaluva tielyanna (Dios iluminará tu camino)
Visita la página de la Casa de la Juventud, TOR: www.torcasajuv.com
"Ama y haz lo que quieras. Si callas, callarás con amor; si gritas, gritarás con amor; si corriges, corregirás con amor; si perdonas, perdonarás con amor. Si tienes el amor arraigado en ti, ninguna otra cosa sino amor serán tus frutos." (San Agustín) Solamente asegúrate que en realidad sea AMOR...

Respuesta del congresista Villanueva Nuñez a Microsoft Perú

Fuentes: Referencias:




Lima, 08 de Abril del 2002.

Señor

JUAN ALBERTO GONZÁLEZ

Gerente General de Microsoft del Perú

Presente.-

Estimado Señor.

Ante todo, agradezco su carta del 25 de Marzo del 2002 donde manifiesta la posición oficial de Microsoft respecto al Proyecto de Ley Nº 1609, Software Libre en la Administración Pública, que sin duda se halla inspirada en el deseo de que el Perú logre situarse adecuadamente en el contexto tecnológico global. Animado de ese mismo espíritu y convencido de que a través del intercambio de ideas claras y abiertas hemos de encontrar las mejores soluciones, me permito contestar mediante la presente los comentarios incluidos en su carta.

Sin dejar de reconocer que opiniones como la suya constituyen un aporte significativo, me hubiese resultado aun mas valioso si, además de formular objeciones de índole general (que luego analizaremos en detalle) hubiera agregado argumentos sólidos sobre las ventajas que el software propietario puede reportar al Estado Peruano y a sus ciudadanos en general, pues ello habría permitido un intercambio a todas luces más esclarecedor respecto de cada una nuestras posiciones.

Con el objetivo de ordenar el debate, asumiremos que lo que Ud. llama "software de código abierto" es lo que el Proyecto define como "software libre", puesto que existe software cuyo código es distribuido junto con los programas, pero no encaja en la definición establecida en el Proyecto; y lo que Ud. llama "software comercial" es lo que el Proyecto define como "propietario" o "no libre", puesto que existe software libre que se comercializa en el mercado por un precio como cualquier otro bien o servicio.

También es preciso dejar en claro que el propósito del Proyecto al que nos referimos no está directamente relacionado con la cantidad de ahorro directo que pueda obtenerse por el empleo de software libre en las instituciones estatales. Este es en todo caso, un valor agregado marginal, pero de ninguna manera el foco del objetivo del Proyecto. Los principios elementales que animan al Proyecto se vinculan a las garantías básicas de un Estado democrático de derecho, como:

  • Libre acceso del ciudadano a la información pública.

  • Perennidad de los datos públicos.

  • Seguridad del Estado y de los ciudadanos.

Para garantizar el libre acceso de los ciudadanos a la información pública, resulta indispensable que la codificación de los datos no esté ligada a un único proveedor. El uso de formatos estándar y abiertos permite garantizar este libre acceso, logrando si fuera necesario la creación de software libre compatible.

Para garantizar la perennidad de los datos públicos, es indispensable que la utilización y el mantenimiento del software no dependan de la buena voluntad de los proveedores, ni de las condiciones monopólicas impuestas por éstos. Por ello el Estado necesita sistemas cuya evolución pueda ser garantizada gracias a la disponibilidad del código fuente.

Para garantizar la seguridad del Estado o seguridad nacional, resulta indispensable contar con sistemas desprovistos de elementos que permitan el control a distancia o la transmisión no deseada de información a terceros. Por lo tanto, se requieren sistemas cuyo código fuente sea libremente accesible al público para permitir su examen por el propio Estado, los ciudadanos, y un gran número de expertos independientes en el mundo. Nuestra propuesta aporta mayor seguridad, pues el conocimiento del código fuente eliminará el creciente número de programas con *código espía*.

Asimismo, nuestra propuesta refuerza la seguridad de los ciudadanos, tanto en su condición de titulares legítimos de la información manejada por el estado, cuanto en su condición de consumidores. En este ultimo caso, al permitir el surgimiento de una oferta extensa de software libre desprovisto de potencial *código espía* susceptible de poner en riesgo la vida privada y las libertades individuales.

En este sentido, el Proyecto de Ley se limita a establecer las condiciones en que los organismos estatales adquirirán software en el futuro, es decir, de un modo compatible con la garantía de esos principios básicos.

De la lectura del Proyecto quedará claro que una vez aprobada:

  • la ley no prohibe la producción de software propietario

  • la ley no prohibe el comercio de software propietario

  • la ley no dicta cuál software concreto usar

  • la ley no dicta a que proveedor se compra el software

  • la ley no limita los términos en que se puede licenciar un producto de software.

Lo que el proyecto expresa claramente es que, el software para ser aceptable para el Estado, no basta con que sea técnicamente suficiente para llevar a cabo una tarea, sino que además las condiciones de contratación deben satisfacer una serie de requisitos en materia de licencia, sin los cuales el Estado no puede garantizar al ciudadano el procesamiento adecuado de sus datos, velando por su integridad, confidencialidad y accesibilidad a lo largo del tiempo, porque son aspectos muy críticos para su normal desempeño.

Estamos de acuerdo Sr. González, en el hecho de que la tecnología de información y comunicaciones tiene un impacto en la calidad de vida de los ciudadanos significativo (sin que por ello sea siempre positivo o de efecto neutro). También coincidiremos seguramente, en que los valores básicos que he señalado arriba son fundamentales en una nación democrática como el Perú. Desde luego estamos muy interesados en conocer cualquier forma alternativa de garantizar estos principios, que no sea la de recurrir al empleo de software libre en los términos definidos en el Proyecto de Ley.

En cuanto a las observaciones que Ud. formula, pasaremos ahora a analizarlas en detalle:

En primer lugar, señala que: "1. El proyecto establece la obligatoriedad de que todo organismo público debe emplear exclusivamente software libre, es decir de código abierto, lo cual transgrede los principios de la igualdad ante la ley, el de no discriminación y los derechos a la libre iniciativa privada, libertad de industria y contratación protegidos en la constitución.".

Esta apreciación constituye un error. De ningún modo el proyecto afecta los derechos que Ud. enumera; sólo se limita a establecer condiciones para el empleo del software por parte de las instituciones estatales, sin inmiscuirse en modo alguno en las transacciones del sector privado. Es un principio bien establecido que el Estado no tiene el amplio espectro de libertad contractual del sector privado, pues precisamente esta limitado en su accionar por el deber de transparencia de los actos públicos; y en ese sentido, la preservación del mejor interés común debe prevalecer cuando se legisla sobre la materia.

El Proyecto protege la igualdad ante la Ley, pues ninguna persona natural o jurídica esta excluida del derecho de ofrecer estos bienes al Estado en las condiciones fijadas en el Proyecto y sin más limitaciones que las establecidas en la Ley de Contrataciones y Adquisiciones del Estado (T.U.O. por Decreto Supremo No. 012-2001-PCM).

El Proyecto no introduce discriminación alguna, pues sólo establece *como* han de proveerse estos bienes (lo cual es una potestad estatal) y no *quien* ha de proveerlos (lo que en efecto resultaría discriminatorio si se impusieran restricciones basadas en origen nacional, raza, religión, ideología, preferencia sexual, etc.) Por el contrario, el Proyecto es decididamente antidiscriminatorio. Es así porque al determinar sin lugar a dudas las condiciones de provisión del software, impide a los organismos estatales el uso de programas cuyo licenciamiento incluya condiciones discriminatorias.

Resulta obvio por lo expuesto en los dos párrafos previos, que el Proyecto no atenta contra la libre iniciativa privada, pues esta puede elegir siempre bajo que condiciones producirá el software; algunas de estas serán aceptables para el Estado, y otras no lo serán porque contrarían la garantía de los principios básicos enumerados arriba. Esta libre iniciativa es desde luego, compatible con la libertad de industria y con la libertad de contratación (en los términos acotados en que el Estado puede ejercer esta última). Cualquier sujeto privado puede producir software en las condiciones que el Estado lo requiere, o puede abstenerse de hacerlo. Nadie esta forzado a adoptar un modelo de producción, pero si desea proveer software al Estado, deberá proporcionar los mecanismos que garantizan los principios básicos, y que son los manifestados en el Proyecto.

A manera de ejemplo: nada en el texto del Proyecto impediría a su empresa ofrecer a los organismos del Estado su "suite" de oficina, en las condiciones definidas en el Proyecto y fijando el precio que ustedes consideren conveniente. Si no lo hiciera, no se deberá a restricciones impuestas por la ley, sino a decisiones empresariales respecto al modo de comercializar sus productos, decisiones, en que el Estado no tiene participación.

A continuación señala Ud. que: "2. El proyecto, al hacer obligatorio el uso de software de código abierto, establecería un tratamiento discriminatorio y no competitivo en la contratación y adquisición de los organismos públicos..."

Esta afirmación no es sino una reiteración de la anterior, y por ende se encuentra contestada lineas arriba. Pero detengámonos un instante en su apreciación sobre el "tratamiento ... no competitivo."

Por cierto, al definir cualquier tipo de adquisición, el comprador fija condiciones que se relacionan con el uso propuesto del bien o servicio. Desde luego ello excluye a ciertos fabricantes de la posibilidad de competir, pero no los excluye "a priori", sino en base a una serie de principios decididos por la voluntad autónoma del comprador, en tanto el proceso se lleve a cabo conforme a la ley. Y en el Proyecto se estable que *nadie* esta excluido de competir en tanto garantice el cumplimiento de los principios básicos.

Además el Proyecto *estimula* la competencia, pues alienta a generar oferta de software con mejores condiciones de usabilidad, y a optimizar trabajos ya establecidos, en un modelo de mejora constante.

De otro lado, el aspecto central de la competitividad es la oportunidad de proporcionar al consumidor mejores opciones. Ahora bien, es imposible desconocer que el marketing no juega un papel neutral a la hora de presentar la oferta al mercado (pues admitir lo contrario habilitaría a suponer que las inversiones que las empresas realizan en marketing carecen de sentido), y por consiguiente un gasto significativo en este rubro puede influir las decisiones del comprador. Esta influencia del marketing queda en buena medida mitigada por el proyecto que propulsamos, pues la elección dentro del marco propuesto recae en el *mérito técnico* del producto y no en el esfuerzo de comercialización del productor; en este sentido, la competitividad se acentúa, pues el más pequeño productor de software puede competir en un pie de igualdad con la más poderosa de las corporaciones.

Es necesario recalcar que no hay posición más anti-competitiva que la de los grandes productores de software propietario, que frecuentemente abusan de su posición dominante, porque en innumerables casos proponen como soluciones a problemas planteados por los usuarios: "actualice su software a la nueva versión" (con cargo para el usuario, por supuesto); además, son comunes las interrupciones arbitrarias de asistencia técnica para productos que al sólo juicio del proveedor, son "antiguos"; luego para recibir algún grado de asistencia técnica, el usuario se ve obligado a migrar (con costo no trivial, especialmente porque suele involucrar cambios de la plataforma de hardware) a nuevas versiones. Y como toda la infraestructura esta consolidada en formatos de datos propietarios, el usuario queda "atrapado" en la necesidad de continuar empleando los productos del mismo proveedor, o realizar el enorme esfuerzo de cambiar a otro ambiente (también probablemente propietario).

Agrega Ud.: "3. Así, al obligar al Estado a favorecer un modelo de negocios que apoyaría exclusivamente el software de código abierto, el proyecto sólo estaría desalentando a las compañías fabricantes locales e internacionales que son las que verdaderamente realizan importantes inversiones, crean un significativo número de puestos de empleos directos e indirectos, además de contribuir al PBI vs. Un modelo de software de código abierto que tiende a tener un impacto económico cada vez menor debido a que crea principalmente empleos en servicio."

No estoy de acuerdo con lo que Ud. afirma. En parte por lo que Ud. mismo señala en el párrafo 6 de su carta, respecto del peso relativo de los servicios en el contexto del uso de software. Esta contradicción, de por sí, invalidaría su postura. El modelo de servicios, adoptado por gran número de corporaciones en la industria informática, es mucho más significativo, en términos económicos y con tendencia creciente, que el licenciamiento de programas.

Por otra parte, el sector privado de la economía tiene la más amplia libertad para elegir el modelo económico que mas convenga a sus intereses, aunque esta libertad de elección quede muchas veces oscurecida de manera subliminal por las desproporcionadas inversiones en marketing de los productores de software propietario.

Adicionalmente, de la lectura de su opinión se desprendería que el mercado Estatal es crucial e imprescindible para la industria del software propietario, a tal punto que la opción que el Estado establece en este proyecto, eliminaría completamente del mercado a estas empresas. Si es así, deducimos que el Estado estaría subsidiando a la industria del software propietario. En el supuesto negado que esto fuese cierto, entonces el Estado tendría el derecho en aplicar los subsidios al área que considere de mayor valor social; resultaría innegable, en esta improbable hipótesis, que si el Estado decide subsidiar software debería hacerlo escogiendo el libre por encima del propietario, atendiendo a su efecto social y al uso racional de los dineros de los contribuyentes.

Respecto de los puestos de trabajo generados por el software propietario en países como el nuestro, estos tratan mayoritariamente tareas técnicas de poco valor agregado; a nivel local, los técnicos que prestan soporte a software propietario producido por empresas transnacionales no están en condiciones de solucionar un bug, no necesariamente por falta capacidad técnica o talento, sino porque no disponen del código fuente a reparar. Con software libre se crea empleo técnicamente más calificado y se genera un marco de libre competencia donde el éxito esta sólo vinculado a la capacidad de brindar buen soporte técnico y calidad de servicio, se estimula el mercado y se incrementa el patrimonio común del conocimiento, abriendo alternativas para generar servicios de mayor valor agregado y mejor perfil de calidad beneficiando a todos los actores: productores, prestadores de servicios y consumidores.

Es un fenómeno común en los países en vías de desarrollo que las industrias locales de software obtienen la mayoría de sus ingresos en el área de servicios, o en la construcción de software "ad hoc". Por lo tanto, cualquier impacto negativo que la aplicación del Proyecto pueda tener en este sector se verá compensado con creces por un aumento de la demanda de servicios (a condición de que estos sean prestados conforme a altos estándares de calidad). Desde luego, es probable que las empresas transnacionales de software si deciden no competir conforme a estas reglas de juego, sufran alguna disminución de ingresos en términos de facturación por licenciamiento; pero considerando, que estas empresas alegan sostenidamente que mucho del software empleado por el Estado fueron copiados ilegalmente, se verá que el impacto no ha de ser extremadamente serio. Ciertamente, en todo caso su fortuna estará determinada por leyes del mercado, cuyos cambios no es posible evitar; muchas empresas tradicionalmente asociadas con el software propietario ya han emprendido un camino firme (apoyado por cuantiosas inversiones) para prestar servicios asociados con el software libre, lo cual demuestra que los modelos no son mutuamente excluyentes.

Con este Proyecto el Estado está decidiendo que requiere preservar ciertos valores fundamentales. Y lo decide en base a sus potestades soberanas, sin afectar con ello ninguna de las garantías constitucionales. Si estos valores pueden ser garantizados sin tener que escoger un modelo económico dado, los efectos de la ley serían aun más beneficiosos. En todo caso debe quedar claro que el Estado no elige un modelo económico; si sucediera que existe un sólo modelo económico capaz de proveer software tal que satisfaga la garantía básicas de estos principios, se trataría de una circunstancia histórica y no de una decisión arbitraria en favor de un modelo dado.

Prosigue su carta: "4. El proyecto de ley impone el uso de software de código abierto sin considerar los peligros que esto pueda conllevar desde el punto de vista de seguridad, garantía y posible violación de los derechos de propiedad intelectual de terceros."

Aludir de forma abstracta "los peligros que pueda conllevar", sin especificar siquiera una sola instancia de esos supuestos peligros, denota cuando menos un desconocimiento del tema. Así, pues, permítame ilustrarlo sobre estos puntos.

Sobre seguridad:

En términos generales respecto la seguridad nacional, ya se mencionó inicialmente en los principios básicos del Proyecto. En términos más puntuales respecto de la seguridad del software en sí, es bien sabido que el software (propietario o libre) contiene errores de programación o "bugs" (en la jerga informática) en sus lineas de código. Pero también es público y notorio que los bugs en el software libre son menos, y se reparan mucho mas rápidamente, que en el software propietario. No en vano numerosas organismos públicos responsables por la seguridad informática de los sistemas estatales en países desarrollados prescriben el uso de software libre a iguales condiciones de seguridad y eficiencia.

Lo que resulta imposible probar es que el software propietario sea más seguro que el libre, salvo mediante el escrutinio publico y abierto de la comunidad científica y los usuarios en general. Esta demostración es imposible porque el propio modelo del software propietario impide este análisis, con lo que la garantía de seguridad se basa en la palabra bienintencionada (pero a todas luces parcial) del propio productor o sus contratistas.

Corresponde recordar que, en numerosos casos, las condiciones de licenciamiento incluyen cláusulas de Non-Disclosure que impiden a los usuarios revelar abiertamente las fallas de seguridad halladas en el producto propietario licenciado.

Respecto a garantía:

Como Ud. sabe perfectamente, o podrá determinar leyendo el "End User License Agreement" de los productos que licencia, en la amplísima mayoría de los casos, las garantías están limitadas a la reposición del medio de almacenamiento si este fuera defectuoso, pero en ningún caso se prevén compensaciones por daños directos o indirectos, lucro cesante, etc.. Si como consecuencia de un bug de seguridad en alguno de sus productos, no oportunamente reparado por Uds., un atacante comprometiera sistemas cruciales para el Estado: ¿que garantías, reparaciones y compensaciones proporcionaría su empresa de acuerdo con sus condiciones de licenciamiento? Las garantías del software propietario, en tanto los programas se entregan ``AS IS'', es decir, en el estado en que se encuentran, sin ninguna responsabilidad adicional para el proveedor respecto a su funcionalidad, no difieren en modo alguno de las habituales en el software libre.

Sobre la propiedad intelectual:

Las cuestiones de propiedad intelectual están fuera del ámbito en este proyecto, pues se encuentran amparadas por otras leyes específicas. El modelo de software libre no implica en modo alguno desconocer estas leyes y de hecho, la amplísima mayoría del software libre está amparado por el copyright. En realidad, la sola inclusión de esta cuestión en sus observaciones demuestra su confusión respecto del marco legal en que se desenvuelve el software libre. La incorporación de propiedad intelectual ajena en obras que luego se atribuyen como propias no es una práctica de la que se tenga registro en la comunidad del software libre; si lo es, lamentablemente, en el terreno del software propietario. Valga a titulo de ejemplo la condena de la Corte Comercial de Nanterre, Francia, del pasado 27 de septiembre de 2001 a Microsoft Corp., por 3 millones de francos en concepto de daños e intereses, por violación de la propiedad intelectual (piratería, según el desafortunado término que su empresa suele usar en su publicidad).

Prosigue diciendo que: "5. El proyecto maneja de manera errónea los conceptos de software de código abierto, que no necesariamente implica que sea software libre o de costo cero, llegando a realizar conclusiones equívocas sobre ahorros para el Estado, sin ningún sustento costo beneficio que valide la posición."

Esta observación no es así, en principio la gratuidad y la libertad son conceptos ortogonales: hay software propietario y oneroso (por ejemplo, MS Office), software propietario y gratuito (MS Internet Explorer), software libre y oneroso (distribuciones RedHat, SuSE, etc. del sistema GNU/Linux), software libre y gratuito (Apache, OpenOffice, Mozilla), y aun software que se licencia bajo diferentes modalidades (MySQL).

Ciertamente que el software libre no es necesariamente gratuito. Y tampoco se desprende del texto del Proyecto que deba serlo como bien habrá notado después de leer la norma propuesta. Las definiciones incluidas en el Proyecto determinan claramente *que* debe considerarse software libre, en ningún momento se refieren a la gratuidad. Si bien se mencionan las posibilidades de ahorro en términos de lo pagado por licencias de software propietario, los fundamentos del proyecto hacen clara mención a las garantías fundamentales que se pretende preservar y al estimulo del desarrollo tecnológico local. Puesto que un Estado democrático debe sostener estos principios, no le queda otra solución que emplear software cuyo código fuente está públicamente disponible e intercambiar información sólo en formatos standares.

Si el Estado no empleara software con esas características, estaría vulnerando principios republicanos básicos. Por fortuna, además, el software libre implica menores costos totales; pero aun en la hipótesis (fácilmente negada) de que costara más que el propietario, la sola existencia de una herramienta de software libre eficaz para una determinada función informática obligaría al Estado a usarla; no por imperio de este Proyecto de Ley, sino por los principios elementales que enumeramos al comienzo y que surgen de la esencia misma del Estado democrático de derecho.

Sigue Ud.: "6. Es equivocado pensar que el Software de Código Abierto es gratuito. Investigaciones realizadas por Gartner Group (importante investigadora del mercado tecnológico reconocida a nivel mundial) han señalado que el costo de adquisición del software (sistema operativo y aplicaciones) se reduce a sólo 8% del total de costos que las empresas e instituciones deben asumir como consecuencia del uso racional y realmente provechoso de la tecnología. El otro 92% lo constituyen: costos de implantación, capacitación, soporte, mantenimiento, administración e inoperatividad."

Este argumento repite lo ya señalado en el párrafo 5 y en parte se contradice con el párrafo 3. Por lo tanto nos remitiremos a lo allí dicho en homenaje a la brevedad. No obstante, permítame señalarle que incurre en una conclusión falsa en el plano lógico: que el costo de software según Gartner Group sea sólo el 8% en promedio del costo total de utilización, no invalida en forma alguna la existencia de software gratuito, esto es, aquel cuyo costo de licenciamiento es cero.

Además en este párrafo Ud. indica acertadamente que los componentes de servicio y las pérdidas por indisponibilidad conforman la parte sustancial del costo total de utilización de software; lo que, advertirá, entra en contradicción con su afirmación del valor mínimo de los servicios sugerido en el párrafo 3. Ahora bien, el empleo de software libre contribuye significativamente a disminuir los restantes costos del ciclo de vida. Esta reducción del impacto económico de despliegue, soporte, etc. se registra en varios campos; por un lado, el modelo competitivo de servicios del software libre, cuyo soporte y mantenimiento es posible contratar libremente entre una oferta variada que compite en función de la calidad y el menor costo. Esto es válido para la implantación, la capacitación y el soporte, y en buena medida para el mantenimiento. En segundo lugar, por la característica reproductiva del modelo, hace que el mantenimiento que se realizó en una aplicación sea replicable muy fácilmente, sin incurrir en mayores costos (es decir, sin pagar más de una vez por lo mismo) pues las modificaciones, si así se desea, quedan incorporadas al patrimonio común del conocimiento. En tercero, porque el enorme costo causado por la inoperatividad ("pantallas azules de la muerte", código malicioso como virus, worms y troyanos, excepciones, fallas generales de protección y otros tantos males conocidos) se reduce significativamente al emplear software mas estable; y es bien sabido que una de las virtudes mas destacables del software libre es su estabilidad.

Afirma luego que: "7. Uno de los argumentos que sustentan el proyecto de ley es la supuesta gratuidad del software de código abierto, comparado con los costos del software comercial, sin tener en cuenta que existen modalidades de licenciamiento por volumen que pueden ser sumamente ventajosas para el Estado, tal como se ha logrado en otros países."

He puntualizado ya que lo que está en cuestión no es el costo del software, sino los principios de libertad de información, accesibilidad y seguridad. Estos argumentos se han tratado de manera extensa en párrafos anteriores, por lo que estimaré remitirse a ellos.

Por otra parte, ciertamente existen modalidades de licenciamiento por volumen (aunque infortunadamente, el software propietario no satisface los principios básicos). Pero, como Ud. acaba de señalarlo acertadamente en el párrafo inmediatamente anterior de su carta, sólo apuntan a reducir el impacto de un componente que importa no más del 8% del costo total.

Prosigue: "8. Adicionalmente, la alternativa adoptada por el proyecto (i) es claramente más costosa por los altos costos que supone una migración y (ii) pone en riesgo la compatibilidad y posibilidad de interoperabilidad de las plataformas informáticas dentro del Estado, y entre el Estado y el sector privado, dada la centena de versiones que existen de software de código abierto en el mercado."

Analicemos su afirmación en dos partes. Su primer argumento, el de que la migración supone altos costos es en realidad un argumento en favor del Proyecto. Porque cuanto más tiempo transcurra la migración a otra tecnología esta se tornará mas onerosa; y al mismo tiempo se irán incrementando los riesgos de seguridad asociados con el software propietario. De esta manera, el uso de sistemas y formatos propietarios va haciendo que el Estado se vuelva cada vez más dependiente de proveedores determinados. Por el contrario, una vez implantada la política de uso de software libre (implantación que, es cierto, implica un costo), la migración de un sistema a otro se hace muy sencilla, ya que todos los datos están almacenados en formatos abiertos. Por otra parte, la migración a un entorno de software abierto no implica más costos que la misma entre entornos distintos de software propietario, con lo que su argumento se invalida totalmente.

El segundo argumento refiere a "dificultades de interoperabilidad de las plataformas informáticas dentro del Estado, y entre el Estado y el sector privado". Esta afirmación implica un cierto desconocimiento de los mecanismos de construcción de software libre, en el que no se maximiza la dependencia del usuario respecto de una plataforma determinada, como sucede habitualmente en el campo del software propietario. Aun cuando existen múltiples distribuciones de software libre, y numerosos programas susceptibles de ser empleados para una misma función, la interoperabilidad queda garantizada tanto por el empleo de formatos estándar, exigido en el proyecto, como por la posibilidad de construir software interoperable a partir de la disponibilidad del código fuente.

Dice luego que: "9. El software de código abierto en su mayoría no ofrece los niveles de servicio adecuados ni la garantía de fabricantes reconocidos para lograr mayor productividad por parte de los usuarios, lo cual ha motivado que diferentes entidades públicas hayan retrocedido en su decisión de ir por una solución de software de código abierto y se encuentren utilizando software comercial en su lugar."

Esta observación es infundada. Respecto de la garantía su argumento ha sido rebatido respondiendo el párrafo 4. Respecto de los servicios de soporte, es posible usar software libre sin ellos (así como sucede también con el software propietario) pero quienes los requieran pueden adquirir soporte por separado, tanto de empresas locales cuanto de corporaciones internacionales, también como en el caso de software propietario.

Por otra parte, contribuiría en mucho a nuestro análisis que nos informase acerca de proyectos de software libre *implantados* en entidades públicas, que a la fecha hayan sido abandonados en favor del software propietario. Conocemos un buen número de casos en el sentido inverso, pero carecemos de información respecto de casos en el sentido que Ud. expone.

Continua observando que: "10. El proyecto desincentiva la creatividad de la industria peruana de software, que factura US$ 40 millones/año, exporta US$ 4 millones (10mo. en ranking productos de exportación no tradicional, más que artesanías) y es una fuente de empleo altamente calificado. Con una Ley que incentive el uso de software de código abierto, los programadores de software pierden sus derechos de propiedad intelectual y su principal fuente de retribución."

Esta claro por demás que nadie esta obligado a comercializar su código como software libre. Tan sólo deberá tener en cuenta que, si no lo hace, no podrá venderle al sector público. Este, por otra parte, no constituye el principal mercado para la industria nacional de software. Lineas arriba hemos abordado algunas cuestiones referidas a la influencia del Proyecto en la generación de empleo técnico altamente calificado y en mejores condiciones de competitividad, por lo que parece innecesario insistir aquí en el punto.

Lo que sigue en su afirmación es erróneo. Por un lado, ningún autor de software libre pierde sus derechos de propiedad intelectual, a menos que por su expresa voluntad desee colocar su obra en el dominio público. El movimiento del software libre siempre ha sido extremadamente respetuoso de la propiedad intelectual, y ha generado reconocimiento público extenso a los autores. Nombres como el de Richard Stallman, Linus Torvalds, Guido van Rossum, Larry Wall, Miguel de Icaza, Andrew Tridgell, Theo de Raadt, Andrea Arcangeli, Bruce Perens, Darren Reed, Alan Cox, Eric Raymond, y muchos otros, son mundialmente reconocidos por sus contribuciones en el desarrollo de software que hoy es utilizado por millones de personas en todo el mundo, en tanto los nombres de los autores materiales de excelentes piezas de software propietario, permanecen en el anonimato. Por otra parte, afirmar que las regalías por derechos de autor constituyen la principal fuente de retribución de los programadores Peruanos es en todo caso aventurado, en particular porque no se ha aportado ninguna prueba al efecto ni una demostración de como el empleo de software libre por el Estado influiría en esta retribuciones.

Prosigue Ud. diciendo que: "11. El software de código abierto, al poder ser distribuido gratuitamente, tampoco permite generar ingresos para sus desarrolladores por medio de la exportación. De esta forma, se debilita el efecto multiplicador de la venta de software a otros países y por lo tanto el crecimiento de esta industria, cuando contrariamente las normas de un Gobierno deben estimular la industria local."

Esta afirmación demuestra nuevamente un desconocimiento total de los mecanismos y el mercado del software libre. Intenta aseverar que el mercado de cesión de derechos no exclusivos de uso a titulo oneroso (venta de licencias) es el único posible para la industria informática cuando, como Ud. mismo lo ha señalado párrafos arriba, ni siquiera es el más importante. El incentivo que el proyecto presenta al surgimiento de una oferta de profesionales más calificados, en conjunto con el incremento de experiencia que resultará para los técnicos nacionales el trabajar a gran escala con software libre en el Estado, los colocan en una posición altamente competitiva para brindar sus servicios al extranjero.

Señala luego que "12. En el Foro se discutió sobre la importancia del uso de software de código abierto en la educación, sin comentar el rotundo fracaso de esta iniciativa en un país como México, en donde precisamente los funcionarios del Estado que fundamentaron el proyecto, hoy expresan que el software de código abierto no permitió brindar una experiencia de aprendizaje a alumnos en la escuela, no se contó con los niveles de capacitación a nivel nacional para dar soporte adecuado a la plataforma, y el software no contó y no cuenta con los niveles de integración para la plataforma que existen en las escuelas."

Efectivamente, en México se dio marcha atrás con el proyecto Red Escolar. Eso se debió, precisamente a que los impulsores del proyecto mexicano tuvieron al costo de las licencias como principal argumento, en vez de las otras razones estipuladas en nuestro proyecto y que son mucho más esenciales. Debido a este error conceptual, y como consecuencia de la falta de apoyo efectivo por parte de la SEP (Secretaria de Educación Publica) se asumió que para implementar software libre en las escuelas, bastaba con quitarle a éstas el presupuesto para software y en cambio enviarles un CD ROM con GNU/Linux. Por cierto, esto falló y no podía ser de otro modo, tal como fallan los laboratorios escolares en los que se usa software propietario si no hay presupuesto para implementación y mantenimiento. Es precisamente por eso que nuestro proyecto de ley no se limita a indicar la mandatoriedad del uso de software libre, sino que reconoce la necesidad y ordena la creación de un plan de migración viable, en el que el Estado encamine ordenadamente la transición técnica para lograr disfrutar de las ventajas del software libre.

Finaliza Ud. con una pregunta retórica: "13. Si el software de código abierto satisface todos lo requerimientos de las entidades del Estado ¿por que se requiere de una Ley para adoptarlo? ¿No debería ser el mercado el que decida libremente cuáles son los productos que le dan más beneficios o valor?".

Estamos de acuerdo que en el sector privado de la economía, es el mercado quien debe decidir que productos usar y allí no sería admisible ninguna intromisión estatal. Pero en el caso del sector público, el razonamiento no es el mismo: Como ya establecimos el Estado almacena, manipula y transforma información que no le pertenece, sino que la ha sido confiada por los ciudadanos que, por imperio de la ley, no tienen más alternativa que hacerlo. Como contraparte a esa imposición legal, el Estado debe extremar las medidas para salvaguardar la integridad, confidencialidad y accesibilidad de esa informaciones. El empleo de software propietario arroja serias dudas sobre el cumplimiento de estos atributos, a falta de evidencia concluyente al respecto y por lo tanto no es apto para ser usado en el sector público.

La necesidad de una ley estriba, por un lado, en la materialización de los principios fundamentales antes enunciados en el campo específico del software. Por otro, en el hecho de que el Estado no es una entidad ideal homogénea, sino que esta compuesto de múltiples organismos con diversos grados de autonomía de decisiones. Dado que el software propietario es inapropiado para ser empleado, el hecho de establecer estas reglas en la ley impediría que la decisión discrecional de cualquier funcionario ponga en riesgo la información que pertenece a los ciudadanos. Y, sobre todo, porque constituye una reafirmación actualizada en relación con los medios de tratamiento y comunicación de información empleados hoy en día, sobre el principio republicano de publicidad.

Conforme a este principio universalmente aceptado, el ciudadano tiene derecho a conocer toda información en poder del Estado que no esté amparada en una declaración fundada de secreto conforme a la ley. Ahora bien, el software trata información y es en sí mismo información. Información en formato especial, susceptible de ser interpretada por una máquina para ejecutar acciones, pero sin duda información crucial porque el ciudadano tiene legítimo derecho a saber, por ejemplo, como se computa su voto o se calculan sus impuestos. Y para ello, debe poder acceder libremente al código fuente y probar a su satisfacción los programas que se utilizan para el cómputo electoral o para el cálculo de sus impuestos.

Saludo a Ud. con las expresiones de mi mayor consideración, reiterando que mi despacho siempre estará abierto a que expongan sus puntos de vista al detalle que Ud. crea conveniente.

Atentamente,

DR. EDGAR DAVID VILLANUEVA NUÑEZ

Congresista de la República del Perú.



--
Eru kaluva tielyanna (Dios iluminará tu camino)
Visita la página de la Casa de la Juventud, TOR: www.torcasajuv.com
"Ama y haz lo que quieras. Si callas, callarás con amor; si gritas, gritarás con amor; si corriges, corregirás con amor; si perdonas, perdonarás con amor. Si tienes el amor arraigado en ti, ninguna otra cosa sino amor serán tus frutos." (San Agustín) Solamente asegúrate que en realidad sea AMOR...

jueves, 27 de marzo de 2008

3d en OpenSuse 10.3, Linux en mi laptop Toshiba Satellite A215

Como lo comenté en este post, instalé Linux en mi laptop recientemente, pero el problema que me quedó pendiente fue el 3D. Casi inmediatamente, Carlos Rocha contestó en este otro blog con lo siguiente:

Que tal como estas, solo para comentarte que acabo de instalar el opensuse hoy en el mismo modelo de laptop, yo instale el driver que viene el la pagina de amd, y me funciono y aunque cuando echo a andar el panel de control de ati me dice que no tiene soporte para aceleracion 3d por hardware, le instale el xgl y el compiz y funciono de maravilla, todavia estoy en proceso de instalacion de drivers y afinacion de ciertos detallitos, que espero que queden en el transcurso de la semana…
Los drivers los puedes descargar de la pagina http://ati.amd.com/support/driver.html ,
en el sistema operativo seleccionas linux_64 >> Integrated/Motherboard >> RAdeon Xpress 1250..
este es un archivo .run, lo instalas desde el suse, y ejecutas el comando aticonfig –initial, reinicias y listo..
Espero te haya sido de ayuda.
saludos.

Pues bien, hice esto, desinstalé previamente el controlador fgl que ya tenía antes que nada, y siguiendo las instrucciones de la página Wiki de OpenSuSE para instalar este controlador, conseguí mi 3D!!!! Pueden ver la captura de pantalla en http://invernalia.homelinux.net/~jstitch/jstitch/linux/snapshot1.png.

Muchísimas gracias!


--
Eru kaluva tielyanna (Dios iluminará tu camino)
Visita la página de la Casa de la Juventud, TOR: www.torcasajuv.com
"Ama y haz lo que quieras. Si callas, callarás con amor; si gritas, gritarás con amor; si corriges, corregirás con amor; si perdonas, perdonarás con amor. Si tienes el amor arraigado en ti, ninguna otra cosa sino amor serán tus frutos." (San Agustín) Solamente asegúrate que en realidad sea AMOR...

Memorias de la Casa de la Juventud - Encuentro con la Pascua - Marzo 20 - 23 2008

Por fin sucedió, el encuentro de la Pascua Juvenil 2008 había sido muy esperado por nosotros en el equipo de trabajo. Por muchas razones, la emoción de prepararlo, la consciencia de que los tiempos cambian, incluso para la Casa de la Juventud (que tiene ya 26 años de vida), y según mi opinión, la madurez que como equipo hemos ya alcanzado.

Como bien lo hace notar Celso varias veces, las preparaciones de los encuentros ya no son como se hacían antaño. A mi incluso todavía me llegó a tocar de refilón los últimos días en que una persona preparaba todo y había que llegar el sábado del encuentro temprano a estudiar el tema y entenderlo. Hoy, las cosas las hacemos diferentes, y cada año vamos puliendo nuestra técnica. Esto aplica tanto para encuentros ordinarios como para los grandes, y en el caso de esta Pascua no fue la excepción: divididos en grupos, nos asignamos tareas, preparamos temas, actividades, dinámicas, celebraciones, juegos, etc. Y así con unas dos semanas de antelación, ya teníamos listo y por escrito aquello que queríamos ilustrar en estos cuatro días de semana santa.

Lo primero fue la Pascuita, el fin de semana anterior, al menos ya para ir comenzando a experimentar esa vivencia de Resurrección que, para mi, sólo he podido vivir tan a ese nivel en la Casa de la Juventud. Además en la Pascuita hacemos todo en general: la celebración de la Vigilia, el Via Crucis, y aunque por equipos, tambíén se vive la cena del Señor, y el lavatorio de pies! Una de las cosas que me encantan es el Domingo de Ramos, aunque la Eucaristía del domingo es para nosotros ya de Pascua, iniciamos siempre con una mini-procesión, desde el patio de arcos al auditorio, todos con una palma en la mano, cantando 'Canta Jerusalén'...

En fin, que para no hacerla más cansada, llegó el gran día. Entre el domingo de ramos y el miércoles en la noche en que debíamos presentarnos a la Casa, Lore y yo estuvimos preparando la comida de esos días, las cosas que nos llevaríamos, compras y demás cosas que necesitaríamos (ah! porque esta Pascua tuve el honor de que mi bella amada estuviera en el equipo de trabajo ;) ) La verdad estaba muy emocionado con esta Pascua, y aunque la noche del miércoles pasó sin incidencias, ya esperaba impaciente al siguiente día... solo tomé un baño en el cuarto que utilizamos los pilotos y me fui a descansar...

El jueves por la mañana amaneció nublado, pero con el clima rico. Empezamos bien, nos regalaron una playera con el logotipo de esta Pascua impreso: el rostro de Jesús, sacado de la película de Zefirelli. Y comenzó entonces nuestra Pascua juvenil 2008... La verdad, la tristeza también tuvo su lugar, pues llegaron muy pocos participantes, en total sumamos sesenta y pico, cuando el año pasado llegamos a ochenta. Pero fuera de eso, los cuatro equipos que formamos estuvieron siempre dispuestos a participar, a gritar, a bailar, a celebrar, a aprender, en fin... que la cantidad fue poca pero la calidad hasta de sobra!

Para el equipo piloto, el jueves fue bastante movido, actividades a todas horas, preparaciones de cosas a cada rato, entre audiovisuales, trabajos, celebraciones, ensayos de cantos... Y la ventaja fue que, con el coordinador de lujo que tienen :P :P :P pues se pudo ir administrando la actividad a lo largo del dia, adelantando ciertas cosas en ciertos momentos para no estar a las carreras y perder tiempo, o estar fuera del mismo, más tarde...

Los equipos celebraron por separado el lavatorio, y luego de cenar celebramos la Cena, como ya es tradición en el patio de los arcos. Y luego más noche, el momento de oración que llamamos Getsemaní, esta vez en la cueva de Encuentros. Wow! un lugar de lujo para ello... En la tarde habíamos ido a comprar gasolina, que olvidamos antes, para echar a andar nuestra planta de luz, pues ocuparíamos un reflector para un teatro de sombras, y sonido y computadora y cañón para un audiovisual, que hizo en esta ocasión el Wiki, con música de La Lupita nada más y nada menos ;) Y gracias a la gran idea de Celso, los mismos participantes nos ayudaron a alzar todo desde la Cueva hasta la Casa, cada quien se llevó algo: una mesa, un cubo (armamos el monumento del Santísimo con unos cubos de madera grandes), la mampara donde proyectamos el audiovisual, la planta de luz, etc....

Y ya para el jueves, fue suficiente, ni recreación hubo, pero no habían muchas ganas de parte de nadie para tener una jeje. El viernes llegó con mucho sueño pero con ánimo para el piloto: sería el día de la salida de día de campo de los equipos, en otras palabras sería un día bastante más relajado para nosotros. Luego de desayunar y jugar y competir un rato, los equipos se fueron: dos a la cañada, y dos pasando la loma de enfrente. Eso sí, también como ya es tradición, me fui con dos pilotos (Abraham y Alí) a visitar a los equipos, para tomarles fotos y aprovechar para sacar a pasear a los perros de Celso, que durante 4 días tienen que estar encerrados los pobres. Mientras tanto, Mauricio y el Oso se quedaron haciendo el hoyo en donde 'plantaríamos' la cruz que ibamos a utilizar al dia siguiente... Por cierto, ese día también disfruté de mi primer ensayo de cantos de la Pascua, el jueves de bienvenida como siempre se lo llevó Celso, y el de más tarde le tocó a Reyna, la coordinadora general del encuentro. Otra cosa que hicimos, fue irnos de excursión, todos los pilotos y coordinadores, a visitar la cueva del Buen Pastor, que utilizaríamos esa noche al final...

Más tarde, Iván llegó a apoyarnos y con eso completamos al equipo piloto de esta Pascua, y comenzamos a preparar la celebración de la Muerte del Señor. Todo comenzaría en la huerta, bueno, lo cambiamos a un lado, arriba del basurero, en donde aprovechamos el montón de cascajo que hay ahora ahí para plantar la crucesota que cargamos y tenerla expuesta así durante la primer mitad de la celebración. Ahí pasamos dos audiovisuales: uno de la Pasión, hecho de nuevo por el Kalimba (aunque yo conservo uno inédito que hizo el Wiki y que no se utilizó esta vez), y otro que hizo nuestra líder del equipo de música, Eli, con la canción 'Otra vez en la cruz' de René González como tema.

De ahí, en silencio (se supone) se fueron todos de regreso al auditorio, y mientras tanto el equipo piloto bajamos la cruz y la llevamos a la cancha de basquetbol, desde donde comenzaría la procesión. Para esto, cuando lo hacemos de la manera tradicional en la Casa, preparamos algunos participantes de los más altos, los encapuchamos estilo Sevilla y con unos cirios los mandamos al frente. Esto se hace cuando en el auditorio comenzará la adoración, cantando todos el tema 'Viva Dios' (sacado de la obra musical Godspell, que dicho sea de paso, pondremos en escena este 28 de junio!!!), pero en versión de la Casa: solo con batería como fondo, haciendo un pum! pum-pum! lentos, muy lentos, en los que vamos caminando, encapuchados y pilotos hasta el centro del auditorio.

A ese paso, pues, entra hasta atrás la Cruz, cargada a cuestas de los hombros del equipo piloto que, por única vez en todo el año, tiene su único momento de ser visibles... La verdad narrar el momento queda fuera de las palabras: la emoción que da previamente, el saber lo que estás cargando en tus hombros, el paso lento, en fin... hasta Mauricio que es el baterista le dejó su lugar a mi hermano Víctor para que por esta vez entrara con nosotros, los demás pilotos :) Y luego que entramos, es ponernos al centro del auditorio, y utilizando el estrado como base, plantar la cruz en el piso, levantada en todo lo alto, sostenida con mucho esfuerzo... Ahí entonces se canta 'Jesucristo' de Roberto Carlos (también al estilo Casa de la Juventud, claro) y se hace la adoración de la Cruz, como signo de reconocer en la muerte de Jesús el comienzo del triunfo por la salvación, la entrega total al proyecto que le da sentido a la vida de toda la humanidad, en fin... por eso adoramos, no por considerar magia o algo extraño en la madera...

Y terminando, salen los encapuchados seguidos de la cruz, otra vez a cuesta nuestra, primero hay que bajarla y luego caminar al mismo paso lento hasta llegar a la cancha otra vez. Ahí la acomodamos y bueno... por la misma consciencia de los tiempos, adoramos la Cruz (que no nos había tocado porque estábamos sosteniéndola, por si se lo preguntan ;) ) y luego ya me iba yo a seguirle cuando me di cuenta que estaban dándose abrazo en el pilto, así que me regreso, y no me pude aguantar, ni ninguno de ellos, la verdad es que nos pusimos a llorar...

Bueno, se nos hizo un poco tarde para lo que sigue jeje, pero corrimos a terminar la celebración, que necesitaba del pan consagrado del día anterior para la sagrada comunión, y a preparar la cena también... Ya más tarde, nos relajamos, mientras unos pilotos se fueron a la cueva del Buen Pastor a afinar detalles, los demás nos quedamos a disfrutar de la recreación: un mini festival cultural servantino :P, le asignamos a cada equipo 3 actividades culturales que debían preparar: baile regional mexicano, canto, poesía, obra musical, etc. Al final los pilotos (ya todos reunidos) declaramos ganadores: en 3er lugar a la representación cómica cantada de la Pasión de Cristo, del equipo 3, en 2do lugar al equipo 2 con una pieza de danza polinesia (que puso mi esposa, quien mas?!!!) y en 1er lugar al equipo 1 con un baile con la canción Thriller de Michael Jackson, con música y pasitos de muerto y toda la cosa ;)

Asi, al final del día, sólo quedó el momento de oración para ir a descansar, que para hacerlo especial, lo hicimos como si fuéramos a visitar el Sepulcro. Todos en procesión, con unas lámparas de velas que hicieron durante el día, nos fuimos a la cueva del Buen Pastor, donde colocamos una cruz hecha de cirios encendidos, y un letrero con la cita esa que dice simplemente 'y lo pusieron en una tumba nueva, excavada en la roca', del evangelio de Mateo. Ahí hicimos cada quien oración, de manera personal y en silencio...

Fue así como llegamos al día sábado. La verdad muy cansados, pero sacamos energía de quién sabe donde, como buenos pilotos, y empezó otro día lleno de actividades. Luego del desayuno, y más deportes y diversión ;) pasamos a los participantes a ver una película que nos serviría de apoyo: 'La esperanza vive en mi', con Adam Sandler (que para ser actor de cómicas, le salió excelente el drama!) Mientras yo veía a gusto la peli ;) los pilotos estuvieron chambeando todo el tiempo: terminando el hoyo de la cruz, plantándola y juntando lo demás que lleva en la base...
El día continuó con lo de la cruz y al terminar (y luego de que me pude echar un segundo ensayo de cantos!) nos fuimos a bañar y descansar un ratito para agarrar fuerzas para lo más importante de todo el día y todo el encuentro (mmm y todo el ciclo! y toda la historia de la Iglesia! jeje) Luego de un ensayo que se llevó Reyna, comenzó ahora sí la recta final. Recibí instrucciones de Celso y comencé entonces a hacer aquello que me sale tan bien (mmm aunque sigo insisitiendo que me gusta más ser monitor!), por algo me tienen donde me tienen :P : organizar al piloto para que todo quedara a punto para la celebración de la Vigilia de Pasuca...

Mientras los equipos preparaban lo que les tocaba de participación en la celebración, nosotros preparamos el auditorio y la cancha de fútbol, en donde estaba la cruz. Colgamos una mampara, conectamos, puse el cañón con la laptop, movimos el equipo de música, preparamos un signo que se haría al final de todo... en fin, piloto en escencia pura :)

La celebración comenzó con la clásica ambientación en el auditorio (un poco rara esta vez por un error de logística, pero fuera de eso todo bien), para recibir a los que venían de fuera a celebrar la Pascua con nosotros (participantes y equipo de trabajo), y de ahí subimos a la cancha, con todo a oscuras... En la cancha pasamos un audiovisual: 'Después de la caída' de René González, que alguna vez hizo el Kalimba también, y luego de la oscuridad, entró uno de los momentos claves de la noche: la LUZ. He de decir aquí que es labor del coordinador elegir a quién del piloto le tocará este signo, pero bueno, por lo mismo de los tiempos en la Casa, quise hacerlo yo, y dejarle el cirio a Celso Abraham (nuestro más reciente y exitoso piloto, a quien normalmente, diría yo, le corresponde el honor de la antorcha, pero llevar el Cirio también es un honor!) En fin, que encendí una antorcha y me dirigí a la cruz, que ya teníamos preparada, y simplemente me acerqué como había visto que lo hacían los pilotos en tantas Pascuas que he vivido, y la encendí... (la cruz está obviamente embadurnada de combustible, y rodeada de leña para que encienda más fácil). El punto es que el calor es horrible una vez que ya enciende todo, y además la cosa no acaba aún! Primero los participantes lanzan al fuego unos papeles en donde escribieron aquello de lo que quieren deshacerse de sus personas en la Pascua, para pedir la luz en sus vidas pues, pero luego se acerca Celso, con el cirio a un lado, y se bendice la luz, y entonces hay que encender el cirio, así que ahí voy yo de nuevo a acercarme a la cruz, a recoger una madera encendida para encender con ella el cirio... (y lo tuve que hacer dos veces, el viento nos jugó una broma esta vez! :P )

Fuera de eso, lo que sigue es encender las velas de todos los demás, a partir de la luz del Cirio, y mientras se hace eso yo aprovecho para desconectar mi equipo: laptop y cañón, pues de prisa se tiene que proyectar un audiovisual más en el auditorio, luego luego llegando allá! Envío el equipo con Iván y el Oso, y al llegar sólo termino de conectar y alistar todo :) Ese es el piloto... Se proyecta el audiovisual (la lectura 'Mar adentro' con imágenes, música instrumental y voz puestas por el Wiki, hermoso audiovisual por cierto...)

Y bueno, lo que sigue es, después del pregón de Pascua, recibir al Cirio, colocarlo en su lugar, con toda la fiesta de la Resurrección ya en pleno, luego bendecir el agua para comenzar otra de las partes que, desde que soy coordinador, me encantan y divierten más :) Puesto que Celso se dirige a los participantes, a mi me toca la muchachada de los invitados ;) y me voy con una palangana con la misma agua, un aspersor hecho de ramas del Pino de la Casa, y un piloto sosteniéndome el agua, mientras a ritmo de 'El agua del Señor', renovamos el bautismo de los presentes, salpicando a todos a diestra y sieniestra :D (nada más me faltaba ponerme a cantar, como me toca hacer en Godspell ;) )

La celebración continua con la Eucaristía y sigue así en ese ambiente de fiesta hasta el final, cuando luego de la comunión, pusimos todo a oscuras... ocultos así, los pilotos colocan al centro el material del último signo, y a una señal de Celso, acompañado de las palabras 'la respuesta en esta Pascua la das tú', encienden esto: un par de alambres con forma, envueltos en vendas sumergidas en combustible. Fue así como 'tatuamos' de nuevo el piso del auditorio, esta vez con la palabra 'SI' (la vez anterior fue en Pentecostés pasado, cuando hicimos la figura de una paloma).

Y así termina todo, queda solo la fiesta de Pascua: baile, concursos de baile también, premios... (aproveché que en la semana me regalaron unos boletos para ir a la Feria de Chapultepec (un parque de diversiones), y le dimos de premio a los ganadores del baile unos cuantos, lo mismo que al equipo más animado y con la mejor porra de todo el encuentro (el 3), al que puso la coreografía de Thriller un día antes, y al participante que nos entregó su gafete con el que se inscribió desde el jueves en la mañana en el mejor estado posible :D )

El piloto se fue a dormir... como a las 5 de la mañana! luego de limpiar y barrer y alzar lo mejor posible, y dar un palazo honorario (el palazo es la 'bienvenida oficial al equipo piloto', consiste, por si quedan dudas, en utilizar una pala de cocina de esas que parecen remos, para impactar a distintos niveles de intensidad en las posaderas del piloto objetivo de dicho rito :P y por si quedan más dudas, TODOS hemos pasado por ella y seguimos considerándolo un honor eh?) que le dimos al Oso, pero sólo es un niño así que fue honorario nada mas :). A la mañana siguiente sólo quedó desayunar, tomarnos la foto del piloto (que esta vez hicimos con la cruz del viernes :) la que cargamos, no la que se quemó el sábado) y bueno, organizar los aseos (que se hicieron a diario) con los participantes, pero esta vez aprovechando para... mover la grada que se utilizó el día anterior, alzar unos floreros, guardar la cruz, asear el cuarto donde proyectamos audiovisuales y la película, y así dejar la Casa bien limpiesita ;) Y por cierto! disfruté de un ensayo de cantos más! aunque de 15 minutos, lo valió todo...

Y así terminó la Pascua 2008 también, luego de haber tomado más fotos de los equipos en su última reunión, despedirnos, anunciar por primera vez la obra de teatro que pondremos, y hacer nuestra última oración del encuentro, los del equipo de trabajo... ah! y revelar el amigo secreto que hicimos entre nosotros durante esos 4 días :) Sólo quedó la foto del equipo, y ahora sí, cada quien a su casa a descansar...

Hasta el próximo encuentro! nos vemos en la Casa...

PD y a modo de agradecimiento, este fue el equipo de trabajo en esta Pascua juvenil 2008 en la Casa de la Juventud, T.O.R. Gracias!!! :)
Jesús resucitado como fuerza, inspiración, motivo, sentido y todo sin lo que no podría haber habido Pascua ni ahora ni nunca...
Encargado - Celso
Coordinador general - Reyna
Pilotos - Mauricio, Alí, Iván (Muerta), Celso Abraham, y como apoyo invaluable, el hijo del Tanque, Omar (el Oso)
Monitores - Equipo 1: Yesika (Yeka) y Eli; Equipo 2: Orlando (Wiki) y Lore (mi esposa); Equipo 3 (equipo de adultos): Ana Laura y Víctor Ortiz (Kalimba); Equipo 4: Víctor (la Compadreja, mi hermano) y Yatziri
Música - Eli (encargada, guitarra (eléctrica o acústica, dependiendo) y voz), Mau (batería, o pandero JAJAJA), Compadreja (voz y guitarra acústica, cuando se llegó a usar, y batería algunas veces), Kalimba (bajo y voz/guitarra acústica si se daba el caso)
Cocina - Norma (Brothy), Ricardo (Tanque), Jaqueline
Coordinador del piloto - un servidor, Javier (el Stitch) :)



--
Eru kaluva tielyanna (Dios iluminará tu camino)
Visita la página de la Casa de la Juventud, TOR: www.torcasajuv.com
"Ama y haz lo que quieras. Si callas, callarás con amor; si gritas, gritarás con amor; si corriges, corregirás con amor; si perdonas, perdonarás con amor. Si tienes el amor arraigado en ti, ninguna otra cosa sino amor serán tus frutos." (San Agustín) Solamente asegúrate que en realidad sea AMOR...

martes, 25 de marzo de 2008

Servidor en una máquina Linux

Se me ocurrió que era hora ya de entrarle a la configuración de servidores en Linux. Hasta ahora, sólo había conseguido echar a andar un servidor HTTP en linux, para uso local solamente, de forma que pudiera hacer pruebas en desarrollos web con PHP que a veces hago. Sin embargo, no había conseguido, y no me había interesado, en lograr esto mismo pero hacia el exterior. Puesto que tengo configurada una red local (LAN) en mi casa a través de un router (un 2Wire), utilizando la dirección IP local que el router le asigna a mi máquina, alguna vez ya había podido acceder a los servicios HTTP de mi máquina desde otra máquina en la LAN.

Pero sucedió que en mi trabajo comencé a utilizar un cliente SSH para Windows para acceder a una máquina Unix, y se me ocurrió hacer la prueba en mi casa... me llevé dicho cliente, y desde el Windows de la PC de mi esposa, accedí con éxito a mi máquina! como si estuviera trabajando directamente en ella... todo comenzaba a sonar muy interesante...

Sin embargo, la dirección IP de mi máquina era local, y acceder a ella desde afuera tenía que implicar algo con el router, como efectivamente descubrí: hay que configurar dicho aparato para que las solicitudes externas por medio de su dirección IP se redirijan a una máquina de la LAN en particular (o en otras palabras, asignarle la dirección IP del router a la máquina en cuestión).

En el router 2Wire se consigue en las configuraciones avanzadas del Firewall, en donde se elige el nombre de la máquina a servir como entrada a la LAN. (Si se desea también acceder a las otras máquinas de la red, debe, si no me equivoco, configurarse el etc/hosts de la máquina que quedó como entrada, para redirigir las peticiones correctamente, esto no lo he hecho aún, pero ya lo probaré a su tiempo :) Cabe hacer notar que en la configuración del router aparece el nombre de la máquina N veces, dependiendo el número de accesos al router que se tengan: conmigo aparece dos veces, una para la conexión alámbrica y la otra para la inalámbrica. Toda esta configuración la di de alta para mi conexión alámbrica únicamente, que para mi es más confiable y rápida que la inalámbrica, con la cual, si estoy trabajando sin cables, no tendré disponible el servidor. A lo mejor es un tabú mío, pero siento que de forma inalámbrica tengo menos seguridad, además de menos velocidad y confiabilidad de mi conexión.

Una vez configurado esto, también en el router hay que establecer el nivel de seguridad que se quiere tener: se puede establecer que ninguna petición externa pase a la máquina seleccionada (lo que no sirve para nada en realidad), o que ciertas aplicaciones entren directamente a la máquina, o que todas las peticiones pasen a ella, ya es cuestión de gustos en aspecto de seguridad. Por otra parte, es muy recomendable a pesar de la opción elegida, configurar el firewall de la máquina que quedó como entrada, para que también filtre ahora sí de manera particular las peticiones de ciertas aplicaciones / puertos abiertos para permitir la entrada desde el exterior.

Obviamente, para que todo funcione, la computadora debe tener levantados ciertos servicios, dependiendo lo que se desee: SSH para sesiones remotas, HTTP para páginas web, FTP para archivos, SMB para compartir archivos como en Windows, etc. De lo contrario, ni de manera local se conseguiría levantar todo esto.

Y así, teniendo el router configurado para asignarle su dirección IP a la máquina elegida, la máquina reiniciada para adquirir la nueva IP, y el firewall configurado también, todo queda listo para tener la computadora abierta al exterior. Lo único que queda es probar :)
Si se dejó abierto el puerto de HTTP (teniendo también instalado un servidor, como Apache por ejemplo), se puede probar localmente, o mejor, desde una máquina externa en algún otro lugar del mundo (con ayuda de un amigo por ejemplo ;), para que en un navegador de internet cualquiera teclee http://direccion_ip/, lo cual debe llevar a mostrar la página de inicio que tenga configurado el servidor HTTP en la computadora en ese momento. Se pueden hacer otras pruebas, teniendo todo bien configurado, para iniciar sesión en la computadora de manera remota, vía SSH, y muchas otras pruebas más, que en mi caso resultaron satisfactorias y que ahora utilizo para trabajar de manera remota en mi computadora ;)

Otro paso no necesario pero sí muy útil es el DNS de la máquina. Hasta ahora todo quedó configurado con la dirección IP del router, pero ¿qué pasa si el servicio de internet que tengo contratado no me asigna una IP fija, sino dinámica, que se puede reasignar en cualquier momento una vez que se desconecte el router? (por cualquier razón: caídas de voltaje, acciones voluntarias o involuntarias, hasta simplemente mover los cables de corriente a donde está conectado!) Esto provocaría que cada que suceda esta situación, debería tomarse nota de la nueva dirección IP de la máquina, para poder trabajar de forma remota en ella, y no solo eso, si otras personas hacen uso de los recursos de la máquina, habría que notificarles apropiadamente de la nueva dirección IP para que la utilicen.

Esto es engorroso, poco práctico y bueno, en pocas palabras por eso y más desde hace años existe el DNS. Con este servicio, se mapea un nombre común (por ejemplo http://www.google.com/) con una dirección IP dada. Si esta dirección cambia, los servidores DNS se encargan de actualizar esta información, y así los clientes web solo deben consultar estos servicios si acaso se topan con que las cosas ya no funcionan como antes...

Sin embargo, este tipo de servicios tiene un precio, a menos claro que se sepa buscar bien :) y que se sienta uno satisfecho con lo que los servicios gratuitos pueden proporcionar. Yo en particular, lo hice en dynDns.org, en donde saqué una cuenta gratuita y después di de alta mi servidor, asignando la dirección IP que en ese momento tenía mi máquina con el nombre invernalia.homelinux.net. De esta manera, en vez de aprenderse la dir. IP, basta con teclear estas palabras para lograr el mismo efecto. Al ser un servicio gratuito, tuve que quedarme con el 'homelinux.net' (que tampoco se me hizo mala opción), y además dynDns proporciona otros nombres posibles para el dominio. Un servicio pagado a este mismo sitio permitiría elegir el dominio, y registrarlo, pero con esto me basta por ahora ;)

Además, debe hacerse algo respecto al problema mencionado sobre los cambios de direcciones IP. Lo que debe hacerse aquí es tener algún programa que pueda comunicarse con dynDns.org, y que al detectar el cambio de dirección IP registrado respecto al que ahora tenga la máquina, le avise al sitio de la actualización que debe hacerse. Esto lo logré en mi caso utilizando ddclient, un programita que hace precisamente esto cada vez que se arranca la computadora (y existen un montón de estos programas, para diversos sistemas, dynDns.org da una amplia lista).

Por mientras, mi máquina está normalmente dando servicio de lunes a viernes durante las horas del día (en la ciudad de México), que son las horas en que me encuentro ausente de mi casa por mi trabajo, y dejo mi máquina haciendo algo de provecho :P De noche es menos probable que lo tenga, aunque se da el caso. Y definitivamente en fines de semana es muy poco probable que suceda, primero porque suelo llevarme mi laptop a la Casa de la Juventud, en donde o no me conecto a internet, o si lo hago es solamente para dedicarlo a la labor que hago allá (además de que tendría que configurar mi conexión inalámbrica y el router que tienen allá, y todo un rollo más...) Por otro lado cuando no estoy en la Casa de la Juventud, si estoy utilizando mi máquina, lo suelo hacer en cualquier lugar de mi casa, por lo que uso la conexión inalámbrica, y por lo tanto no da servicio ;) Tal vez, el día que me consiga una computadora de escritorio, deje las cosas conectadas de manera más definitiva...

Apéndice, aplicaciones gráficas y no gráficas vía SSH
Bueno, falta comentar un punto más. Vía SSH puedo iniciar sesión en mi máquina de manera remota, y trabajar en ella como si estuviera frente a la misma. Sin embargo, lo más utilizado normalmente es iniciar sesión en modo texto y hacer uso de los programas en modo texto de Linux. Sin embargo, si se desea, también se pueden correr aplicaciones gráficas, y aquí está el como le hago yo:

Antes que nada, recordar que en Linux las aplicaciones gráficas funcionan vía un protocolo llamado XWindow, o X simplemente. Este protocolo funciona aproximadamente de la siguiente manera: se tiene un servidor X en la máquina que desplegará la aplicacion, y todas las aplicaciones que quieran desplegar gráficos hacen uso de los servicios de este servidor. Ahora bien, el servidor puede estar localmente en la misma máquina que las aplicaciones gráficas, o podría estar de forma remota en una máquina donde quieren ejecutarse las aplicaciones provenientes de otro lugar. Esto es lo que yo hago justamente.

Lo que se necesita es, primero que nada, un servidor X en la máquina que se conectará a mi computadora. Por ahora, puesto que utilizo Windows en mi trabajo (desde donde, secretamente, me conecto a mi compu :P), necesito entonces un servidor X para Windows. El que yo utilizo es el de Cygwin (http://www.cygwin.com/, hay que bajarse la utilidad de instalación del Cygwin, instalarlo y elegir entre muchas otras cosas que se deseen, el servidor X11, ya instalado se ejecuta Cygwin, modo texto y de ahí correr los scripts para iniciar el servidor en /usr/X11R6/bin, o directamente modo gráfico con los .bat de ese mismo directorio, no importan las aplicaciones gráficas de Cygwin en este caso, son para usar las cosas de manera local, lo que importa ahorita es el servidor X, que se queda ejecutando en Windows en la barra inferior de aplicaciones en segundo plano).

Una vez con el servidor X, el cliente SSH con el que uno se conecte a la máquina remota (yo utilizo PuTTY, pero podría usarse otro, como el mismo de Cygwin para una conexión entre dos versiones diferentes de Linux, aunque entre comillas una de ellas ;) en fin, este cliente debe configurarse también para que las solicitudes X hechas a la máquina remota sean canalizadas vía SSH, en lugar de quedarse allá en mi computadora. Si no se hace esto, al querer ejecutar una aplicación gráfica, simplemente mi computadora intentará ejecutarla allá, y como estoy en modo texto no me va a dejar hacerlo :) por ello la canalización hará que la aplicación gráfica envíe las solicitudes a servidor X también vía SSH y acá el servidor X instalado se encargará del resto ;) Así es como ejecuto aplicaciones gráficas sencillas. Si lo que se quiere es tener un entorno de escritorio y toda la cosa, el rollo es más complicado, aún no lo he hecho yo (tanto por falta de tiempo, como por falta de conocimientos, como porque mi conexión a internet desde donde me conecto es lenta, y creo que saturaría la red si mando llamar el KDE vía remota :P)


--
Eru kaluva tielyanna (Dios iluminará tu camino)
Visita la página de la Casa de la Juventud, TOR: http://www.torcasajuv.com/
"Ama y haz lo que quieras. Si callas, callarás con amor; si gritas, gritarás con amor; si corriges, corregirás con amor; si perdonas, perdonarás con amor. Si tienes el amor arraigado en ti, ninguna otra cosa sino amor serán tus frutos." (San Agustín) Solamente asegúrate que en realidad sea AMOR...

Instalar Linux (openSuSE 10.3) en una Toshiba Satellite A215

Introducción (lo que me llevó a escribir este post)

En febrero pasado adquirí una nueva computadora, debido a que la anterior sufrió un percance, y como no puedo estar sin computadora por mucho tiempo (por mi trabajo, por afición y por la Casa de la Juventud), adquirí algo que me siriviera por un buen rato, me agradara y me permitiera además tener un buen sistema operativo en ella para trabajar.

De entrada, la computadora venía cargada con Windows Vista, que sí es muy bonito para muchos, pero que no deja de tener graves defectos: primero que nada es software no libre, con lo que el precio es altísimo y la calidad malísima, tanto del sistema en sí como de la suite de oficina (Office 2007) y demás software acompañante... Además está lleno de problemas de memoria, es lento en muchas ocasiones, en fin... no es del todo de mi agrado. Fue por eso que, así como con mi computadora anterior, decidí instalarle alguna distribución Linux.

Pero como aún así lo necesito (para la Casa de la Juventud, y también para jugar :P) comencé por particionar el disco duro (160Gb), quedándome con 35 para Vista (partición a la que llamé 'Videogames' ;) y el resto lo preparé para Linux. Dicho sea de paso, en esos 35Gb le instalé software libre para Windows: aMSN, the Gimp, OpenOffice, etc. y me olvidé de las versiones piratas o legales pero privadas (carísimas o baratas pero en demo o con poco que aportar) de software como Photoshop, Corel, liveMSN, etc.

La partición la hice con el LiveCD para KDE (mi desktop manager favorito) que me bajé del sitio de openSuSE (http://www.opensuse.org/), pues con el particionador de Windows Vista (chafa para no variar) no me dejaba particionarle menos del 50% para ese tonto S.O. (en principio pensaba dejarle unos 45Gb a Windows, pero en vista de la jalada del particionador de este sistema, mejor lo castigue con 10Gb menos ;) Por otro lado dejé una partición de 75 Gb con formato FAT32, para permitirme compartir información entre ambos sistemas, cosa que me resulta útil en gran extremo. De nuevo, hice uso del LiveCD de SuSE, pues el format de Vista no me dejó formatear tanto espacio, mientras que el particionador de SuSE sí.

Así pues, me quedé con aproximadamente 50 Gb reservados para Linux. Mi plan era particionarlo para los distintos directorios del sistema como hice posteriormente... Aunque podía bajarmelo de internet como ya lo he hecho varias veces antes, esta vez decidí en vez de bajarlo de internet, cooperar con la causa y pedí me enviaran a casa el DVD de openSuSE 10.3, pagando a Novell la módica cantidad de $80 USD (que mas gastos de envío, me terminó saliendo en unos $1000 pesos mexicanos ¿caro? ¡para nada! Aunque Windows Vista cueste solo un poco más, en realidad solo incluye el sistema operativo, la suite de oficina más común cuesta una millonada más, ni que decir del obligado antivirus para Windows, y demás software que si se comprara legalmente sería un precio muchísimo muy prohibitivo, mientras tanto esta distribución de Linux, lo mismo que muchas otras, incluye el sistema, suites de oficina (nótese el plural), juegos, software de utilidad variado, software para trabajar en múltiples campos, utilidades de internet que permiten bajar muchísimo más software sin pagar un quinto más (excepto por la electricidad y la conexión a internet claro :), y todo por nada de precio, con mucha mayor calidad y la posibilidad de actualizar los programas gratuitamente).

Instalé pues el SuSE en mi máquina y en menos de un día ya lo tenía en el disco, prácticamente todo funcionando. Respecto a las particiones, haciendo un poco de caso del Linux Documentation Project, dejé una partición root (/) con 2Gb, /var con 4Gb, /usr con 15Gb y /home con 25Gb, el resto se lo dejé a la partición swap.

Problemas a los que me enfrenté y el reto de investigar cómo resolverlos

Solamente me atasqué en tres puntos:

  • el video,
  • la tarjeta de red inalámbrica (wireless) y
  • el sonido
Respecto al video, el sistema no me reconoció la tarjeta de video incluida en la lap: una ATI Radeon X1200, y todo se veía a 800x600 pixeles (muy feo para mis gustos actuales), además de no reconocer el 3D que tanto deseaba ;)

Respecto al wireless la tarjeta no era reconocida, y ni utilizando el ndiswrapper pude echarla a andar.

Respecto al sonido, la máquina simplemente no emitía nada de nada.

Así pues, me embarqué en la aventura (satisfactoria, divertida, llena de retos) de buscar vía la conexión alámbrica a internet con la que sí contaba, los medios para resolver estos problemas.

Wireless
Comencé por el wireless. Y como me resultó lógico, comencé a investigar en el sitio de openSuSE. Ahí encontré que efectivamente mi tarjeta wireless (una Realtek 8187B) debía ser instalada por medio de ndiswrapper, pero el driver proporcionado por Realtek no servía en mi caso, así que el consejo de opensuse.org no me sirvió tampoco :( Busqué en varios foros y la verdad me di por vencido, así que decidí enfocarme en el video y hacer lo del wireless después.

Video
Para el video, de nuevo consultando opensuse.org, comencé por seguir los pasos para instalar tarjetas ATI en SuSE. Con ello ya pude conseguir la detección de mi tarjeta, y un modo de video de al menos 1024x768 :) Pero resulta que mi tarjeta (Radeon X1200) no está ni siquiera, al menos explícitamente, listada en las tarjetas ATI en el sitio de AMD!!! Por lo tanto, los tips de opensuse.org para conseguir el 3D tampoco funcionaron :(

Audio
Decidí dejar el 3D para luego, y me fui por el sonido. La tarjeta es una Realtek AC97 (recuerdo que en otra máquina donde instalé Linux, el sonido también era de una Realtek y también me dio mucha lata), y de nuevo los consejos del wiki de openSuSE no me sirvieron de mucho (sin embargo para muchas otras cosas si que ha servido, por ejemplo para la webcam y los controladores propietarios para algunos formatos multimedia que necesitaba ;) El caso es que para no rendirme, me puse a buscar en foros y blogs, ¡y me topé con esto!: http://www.jambitz.com/comunidad/linux/2008/02/22/instalacion-de-ubuntu-710-en-toshiba-a215-sp4057 un post de un usuario de Ubuntu 7.1, con el mismo hardware que yo!!! Y para él ya funcionaba el wireless, el video y el sonido, justamente los mismos problemas que yo tenía!

Wireless!!! (ahora sí, como lo conseguí)
Por ello, dejé el audio a un lado y regresé al wireless. Básicamente lo conseguí de la siguiente forma: el autor de aquel post se topó a su vez con http://www.datanorth.net/~cuervo/rtl8187b/, el post de otra persona que modificó el driver de Realtek (el que no me sirvió en un inicio) para echarlo a andar correctamente (en este caso, hay que bajar la versión modificada por el autor del post, la versión original no me sirvió, y la otra versión modificada por otra persona ni siquiera la probé). Lo que se hace simplemente es bajar la versión modificada, descomprimirla, compilarla como root (con ./makedrv) y listo! Cada vez que se requiera detectar la tarjeta wireless, se ejecuta (como root también) el script ./wlan0up. Se pueden seguir los consejos del README para echarlo a andar automaticamente al encender la computadora, o hacer como yo hice :P Modifique /etc/rc.d/boot.local y agregué path/a/wlan0up. Además en halt.local agregué path/a/wlan0down, el script que da de baja el driver cada vez que se requiere (en este caso, al apagar la computadora).

Audio
En el mismo post que encontré de jambitz, hallé la solución al audio:Se trata de un package encontrado en un sitio FTP (hasta ahora no se bien a quien pertenece, como para mencionarlo y de esa forma agradecerle :S ) El caso es que en ftp://209.216.61.149/pc/audio/realtek-linux-audiopack-4.07b.tar.bz2 se consigue el código fuente, que se compila y ejecuta con ./install (como root) (para esto, hay que asegurarse de tener instaladas las librerías libc6-dev, libncurses5-dev y gettext o similares, yo utilicé YAST para verificar esto, mientras que el autor del post en jambitz utiliza las utilidades de Ubuntu para lo mismo).

El package ejecuta una aplicación modo texto con Curses, a color y toda la cosa, y esta permite instalar la tarjeta de audio detectada. En mi caso es la ATI Technologies Inc SBX00 Azalia, la cual seleccioné.

Por último, debe modificarse también el archivo /etc/modprobe.d/sound, como root obviamente, y agregar la siguiente linea al mismo:
options snd-hda-intel model=toshiba
y al reiniciar la computadora, el audio queda listo!

Video (revisited y con un continuará...)
Y bueno, hasta aquí, ya había resuelto los problemas más graves, pero aún me quedaba el 3D. Mi problema consiste en que el 3D no es detectado, y SaX2 no me permite entonces configurar nada respecto al 3D. Conforme intenté resolver este problema, como describo más abajo, mi problema terminó con que el 3D era detectado, pero aún así el 3D no funciona, pues provoca que la pantalla se distorsione de un modo que no permite hacer nada :(
Ni los consejos del post en jambitz, ni los del wiki de opensuse.org, ni nada que leí aquí y allá me estaba sirviendo. Decidí suscribirme a los foros de opensuse que encontré: http://www.suseforums.net/, http://forums.suselinuxsupport.de/ y http://www.forosuse.org/forosuse/ (este último en español ;) Estuve leyendo bastantes entradas en los tres, y varios consejos a otros foreros que probablemente me servirían. Toda la semana llegaba a mi casa para probar mis ideas, pero en vano. Terminé por escribir para pedir ayuda y describir mi problema, el de la distorsión en aplicaciones 3D en el mejor de los casos (o el de que mi máquina se cuelga completamente con ciertos juegos 3D también). La captura de pantalla del problema, ilustrado cuando intento ejecutar fgl_glxgears, la conservo en: http://invernalia.homelinux.net/~jstitch/jstitch/linux/fgl_glxgears.png (el programa fgl_glxgears es como el glxgears, que debe desplegar unos engranes giratorios en 3D, pero es la versión del controlador de ATI).

Y sucede que, si quito el controlador ATI, no tengo ni tarjeta ni 3D por lo que quedarme con los controladores por default, los libres, no me sirve. Instalar los de ATI para mi tarjeta gráfica (que son propietarios), me deja con este problema. Una vez intenté instalar una versión anterior de los controladores pero me dejó sin video, pero olvidé correr el SaX2 -r para ver si así sí jalaba (es una prueba que tengo pendiente por hacer) y en fin... en cuanto al 3D aún estoy en espera de resolver este problema para poder conseguirlo, y jugar con estos efectos y demás cosas en mi linux :) CUALQUIER SUGERENCIA AL RESPECTO ES, POR SUPUESTO, BIENVENIDA

Video (revisited2 pero para otra laptop)
Lo que si pude echar a andar fue esta misma versión de openSuSE en otra laptop un año más vieja que la Toshiba, una Dell (no recuerdo el modelo), de mi esposa. Ahí los problemas del wireless y del audio no se presentaron. Mientras tanto en el video sí se detectó la tarjeta NVidia pero no el 3D, pero siguiendo los pasos del wiki de openSuSE todo quedó resuelto, y al menos ella ya puede gozar de esa ventaja :D (Lo que me lleva a concluir que en cuestión de instalación, las tarjetas NVidia son mucho más fáciles que las ATI :( lástima que se trate de una laptop en mi caso...)

Apéndice
Esta noche logré instalar el 3D exitosamente, coloco un post nuevo para comentarlo, gracias Carlos Rocha!

--
Eru kaluva tielyanna (Dios iluminará tu camino)
Visita la página de la Casa de la Juventud, TOR: http://www.torcasajuv.com/
"Ama y haz lo que quieras. Si callas, callarás con amor; si gritas, gritarás con amor; si corriges, corregirás con amor; si perdonas, perdonarás con amor. Si tienes el amor arraigado en ti, ninguna otra cosa sino amor serán tus frutos." (San Agustín) Solamente asegúrate que en realidad sea AMOR...