Tag Torvalds

Lo que inició como el proyecto personal de un estudiante se ha convertido en uno de los sistemas operativos más influyentes de la historia

En el folclor del mundo de la Computación hay un episodio memorable protagonizado por el Dr. Andrew Tanenbaum, experto en sistemas operativos, y Linus Torvalds, en ese entonces estudiante de Licenciatura en Ciencias de la Computación. Lo que se debatía era la manera en que deberían construirse los sistemas operativos de las computadoras.

Un simple pasatiempo 

El 29 de agosto de 1991, en el foro de discusión comp.os.minix, el estudiante de la Universidad de Helsinki, Linus Torvalds, publicó un mensaje que decía algo como: «Hola a todos por ahí usando minix – Estoy haciendo un sistema operativo (libre) (sólo un pasatiempo, no será grande y profesional como gnu) para clones 386(486). Esto está en funcionamiento desde abril y está comenzando a quedar listo. Me gustaría algún comentario sobre cosas que ames/odies en minix, ya que mi sistema operativo se parece un poco (el mismo diseño de la capa física del sistema de archivos (por razones prácticas) entre otras cosas). Actualmente he portado bash (1.08) y gcc (1.40), y las cosas parecen funcionar. Esto implica que llegaré a algo práctico dentro de unos pocos meses, y quisiera saber qué características desearía la mayoría de la gente. Cualquier sugerencia es bienvenida, pero no prometo que pueda aplicarlas 🙂

Linus (torvalds@kruuna.helsinki.fi) PS. sí – está libre de cualquier código de minix, y tiene un fs multihilo. NO es portable (usa 386 task switching, etc.) y probablemente nunca soportará nada distinto de discos duros AT, pues es lo único que tengo 🙁 ”.

Con este mensaje (críptico para los no iniciados), el joven Torvalds iniciaría sin querer uno de los proyectos más influyentes en la computación, pues hoy en día sabemos que su sistema operativo Linux hace funcionar no solo a computadoras personales, sino también a supercomputadoras, teléfonos celulares, relojes, estaciones espaciales, televisores y prácticamente cualquier dispositivo que posea un microprocesador. Pero esa es una historia que debe contarse por separado.

El foro al que envió ese mensaje era para discusiones sobre el sistema operativo Minix, creado por el profesor Tanenbaum y su grupo. A inicios de 1992, cuando vio que las discusiones sobre Linux habían sobrepasado las relativas a Minix, Tanenbaum decidió intervenir. Fue así que el 29 de enero envió al foro un mensaje con el título «Linux es obsoleto”. Con un título como ése, Linus no podía quedarse callado…

El debate 

Lo que siguió fue una avalancha de mensajes, algunos no muy amigables e incluso con argumentos ad-hominem: Linus acusaba a Tanenbaum de pretender hacer Minix como un pasatiempo, con recursos de la universidad, para luego beneficiarse económicamente con su venta; por su parte Tanenbaum le dijo a Torvalds que agradeciera que no era su alumno, pues con el diseño de Linux no habría sacado muy buenas calificaciones. Pero dejando a un lado las cuestiones personales, el aspecto fundamental del debate tenía que ver con lo que cada uno consideraba la manera más apropiada de diseñar sistemas operativos. Tanenbaum defendía la posición de que los sistemas operativos micronúcleo (como Minix) resultaban superiores a los sistemas monolíticos (como Linux); por supuesto, Linus argumentaba lo contrario. De forma muy simplificada, la diferencia es que los sistemas micronúcleo son más modulares y se encargan de menos funciones que los monolíticos. En el enfoque monolítico el sistema operativo asume más responsabilidades, con lo que su tamaño crece.

Al debate se unieron varios programadores, cada quien defendiendo alguna de las dos posiciones. Finalmente se decidió crear el foro comp.os.linux para discutir lo relativo a Linux y dejar en paz el foro de Minix.

El ganador 

En todo debate, los debatientes buscan defender su posición y resultar ganadores. En el caso del debate de Tanenbaum y Torvalds, depende del punto de vista se puede encontrar un ganador. Se puede decir que en realidad ambos estaban equivocados pues consideraban que el enfoque del otro era inapropiado y que resultarían imprácticos cuando los sistemas se volvieran más complejos. A la fecha existen sistemas representativos de cada enfoque que funcionan muy bien y que son exitosos. Sin embargo, hay quienes indican que desde el punto de vista de los sistemas operativos que estaban en el centro de la discusión, Torvalds resultó el ganador del debate. Minix todavía existe y tiene un compacto, aunque fiel, grupo de seguidores. Linux, tal como Tanenbaum lo había previsto, creció hasta ser un sistema operativo muy grande y complejo, pero goza de una popularidad incomparable. Lo que inició como el proyecto personal de un estudiante se ha convertido en uno de los sistemas operativos más influyentes de la historia.

Fuente: elvigia.net

Descubrí la Ley de Linus en el primer curso que tomé sobre cómo editar Wikipedia. Alguien hizo la tradicional pregunta sobre por qué cualquiera podía editar la enciclopedia – incluso, sin necesidad de registrarse como usuario, sino de forma anónima. La respuesta fue maravillosa: porque a mayor cantidad de ojos, mucho más obvios son los errores.

Lo que mi interlocutor quería explicar es que las entradas de la enciclopedia, a pesar de los vandalismos o ediciones bajo propósito, tienden a mantener un cierto estándar gracias a que la comunidad está atenta a los cambios y a que cualquier persona puede corregirlos. Claro, en la práctica, no cualquier persona se anima a editar, pero eso es otro tema – y un desafío grande para el proyecto de conocimiento libre.

Pero, ¿puede la Ley de Linus aplicarse a otros ámbitos? Sí. Una enseñanza básica del código abierto puede tener implicaciones positivas importantes si se aplica como filosofía de trabajo. No importa en qué te desempeñes: te aseguro que este precepto te será muy útil si lo empleas en tu vida cotidiana.

Entendiendo la Ley de Linus

En realidad (y según la misma Wikipedia), la frase que dijo Linus Torvalds fue:

Dado un número suficientemente elevado de ojos, todos los errores se convierten en obvios

Básicamente, el enunciado de Torvald refleja la esencia misma detrás del código abierto: la colaboración para la resolución de problemas. Esa es la explicación detrás de la supervivencia de muchos proyectos de código abierto y/o software libre, en los que una comunidad está en escrutinio constante de modo que los errores «saltan» a la vista.

A mí me gusta explicarlo con un salón de clases. Imagina un aula con 5 estudiantes; el profesor escribe en la pizarra: Moisés metió a los animales en el harca. Digamos que en el aula hay 5 alumnos; quizá alguno se percate que «arca» se escribe sin hache y corrija al profesor. Ahora imaginemos que en el aula hay 10, 20, 50 estudiantes. Entre más ojos, mayor la probabilidad de que ese error no pase desapercibido.

Por supuesto, aquí estoy simplificando mucho. Esto no quiere decir que si el aula tiene 500 alumnos, la clase se vaya sin errores. Quiere decir que si hay más alumnos atentos, es más probable que la equivocación se note. Cada uno tiene un bagaje de conocimientos diferente, así que cada uno puede notar cosas diferentes. Por ejemplo, ¿alguno de ustedes notó a la primera que la frase está equivocada? No fue Moisés quien metió a los animales al arca: fue Noé.

En el desarrollo de proyectos de código abierto y/o software libre, se asume que los errores serán evidentes entre más personas estén mirando. Es la razón para liberar el código en repositorios abiertos: permite que más gente, con diferentes herramientas y preparación, no sólo detecte problemas, sino que también sea capaz de corregirlos.

¿Cómo lo puedo adoptar en tres pasos?

1. Abre

Sin la transparencia, es imposible trabajar bajo este paradigma. Así como se libera el código de un proyecto, abre tu trabajo en la medida de tus posibilidades. Por ejemplo, si estás escribiendo un documento, compártelo con gente afin a tu área de trabajo o personas en cuya capacidad confíes. Permite que miren lo que estás haciendo y que lo retroalimenten.

Yo sé que a muchos nos les atrae la atención de un trabajo abierto a cierto público, pero es una forma de mejorar las cosas. Puedes ser un profesor que abra el diseño de su syllabus a otros colegas (o incluso, alumnos) o un escritor que comparta los avances de su novela. Incluso puedes abrir el flujo de trabajo: aquí en Betazeta usamos Trello y cada persona que forma parte de los sitios puede ver de qué va a escribir su colega y dejarle comentarios.

La opacidad es enemiga de la eficiencia. Piensa en un gobierno opaco en el que no tienes acceso a información pública básica (como saber en qué se gasta el presupuesto). Piensa en una empresa donde nadie sabe qué hace el otro departamento; piensa –y acá me pongo un poquito stallmaniano, nada más tantito– en un software o hardware que no sabes cómo funciona, cómo se repara o cómo se modifica. La apertura es positiva.

2. Revisa

Si alguien se ha animado a compartir su trabajo contigo, tómate un poco de tiempo en revisarlo y darle retroalimentación. No es algo difícil: aquí lo vemos todos los días, con cientos de comentarios que nos ponen en nuestros artículos (y de nuevo, hablemos de Linus, ustedes son los ojos que notan nuestros errores).

Notar la equivocación ya es la mitad del camino. Es más, hasta suena como algo divertido: cazar errores, hallar puntos débiles, encontrar fallos. Pero lo importante no es decir ¡hey, tú, tu trabajo apesta!, sino de verdad ser puntual y explícito: ¡hey, tú, tu artículo apesta porque encontré 3 faltas de ortografía y 8 errores de sintaxis acá, acá y acá!

Para eso, hay que estar abierto a recibir críticas; pero si logras convertir esas observaciones en soluciones, habrás hallado una metodología de trabajo que te ayudará a ser más productivo en tus labores. Pero, como siempre, el último escalón es el más alto.

3. Optimiza

¿Recuerdan la anécdota inicial sobre Wikipedia? Bueno, supongamos que encontramos un error grave en un artículo, ¿qué hacemos? Un buen porcentaje va a reírse del error en redes sociales; otro porcentaje (más pequeño) le dirá a algún wikipedista que edite y una porción diminuta hará clic en Editar y solucionará el problema.

Pregunta: ¿cuál de los tres quieres ser para hacer óptimo tu trabajo?

La razón del éxito de muchos proyectos de código abierto es que alguien se arremangó y decidió hacer algo. Las primeras dos condiciones que te he contado son de mucha ayuda, pero ésta es vital. Puedes tener un proyecto abierto a colaboración, recibir mucha retroalimentación, pero si al final no modificas, todo se queda ahí. Es como si el niño del aula le grita al maestro que la falta de ortografía está ahí, evidente, y el profesor se encoge de hombros. ¿Creen que ese chico volverá a marcarle un error? Probablemente no.

La Ley de Linus es una lección interesante como filosofía de trabajo porque enseña que no debemos temerle a los ambientes de colaboración; que podemos convertirlos en algo constructivo y que descentralizar es positivo para todos. A mí parecer, es una enseñanza del desarrollo abierto que puede incrementar tu calidad mediante el trabajo colectivo en vez del mero esfuerzo individual.

Fuente: fayerwayer.com