Disclaimer: This is a personal web page. Contents written here do not represent the position of my employer.

Tuesday, November 14, 2006

 

Diferencias técnicas entre software libre y software privativo

Defender los valores que conllevan el nuevo modelo de negocio del software libre desde un punto de vista filosófico es a veces complicado, e incluso aunque lo logres de una manera decente, tu compañero de charla es posible que se niegue a ver lo evidente o simplemente que no entienda de lo que le estés hablando.

Para estos casos, podemos usar argumentos meramente técnicos, y en mi opinión quizá incluso más contundentes.

Para ello voy a elaborar una entrada de la bitácora que será una lista de ellos. Los primeros los voy a calcar tal cual de un buen artículo que he encontrado y que trata sobre dependencias y paquetes. El resto las iré introduciendo, actualizando la entrada siempre que sea necesario.

Inconvenientes del software privativo de los cuales carece el software libre:
  1. Reinvención de la rueda: Como el software privativo no puede usar componentes libres de licencia GPL, la empresa de software privativo siempre intentará escribir estos componentes desde cero, a no ser que tengan suerte de encontrar el componente bajo licencias LGPL/BSD, o estén dispuestos a sacrificarse con el siguiente inconveniente. [Mayor tiempo de desarrollo]

  2. Uso de herramientas externas de pago. En caso de no encontrar tiempo para escribir los componentes/librerías software desde cero o no encontrarlos bajo licencias más que libres, otra opción es desembolsar dinero en comprar un componente a su vez privativo o de licencia dual. [Mayor coste de desarrollo]

  3. Documentación o comunidad insuficiente. Por supuesto, hay algunas notorias excepciones a esta regla pero en ocasiones cuando se utiliza una librería o componente privativo es difícil encontrarse una comunidad de usuarios grande y activa con la que poder comunicarse e intercambiar conocimiento como ocurre con el software libre. Las librerías y componentes que se publican bajo licencia libre sin embargo suelen tener muchos más usuarios debido a ello (y si además el software es de calidad, claro) y además en caso de que hubiera escasez de documentación se podría mirar directamente el código fuente para comprobar el funcionamiento del componente, cosa que no es posible con la mayoría del software privativo. [Mayor complejidad.]

  4. Baja estabilidad y robustez. Puesto que el producto no está abierto al uso, no suele haber muchos usuarios interesados en probar el software (sólo los clientes que han pasado por caja), por lo que la estabilidad del software en su conjunto es mucho menor. En el software libre sin embargo se obtiene un feedback apabullante (y gratuito) si el proyecto es de verdad de interés.[Peor calidad.]

  5. Mayor tamaño de los programas: Puesto que el software privativo depende de librerías y componentes no libres, normalmente éstos han de ser adjuntados al programa puesto que el sistema operativo carece de ellos. Ejemplo: interfaces gráficas, librerías de propósito general de un lenguaje, máquinas virtuales, middlewares, pilas de comunicaciones, librerías de acceso a bases de datos, etc. En el software libre sin embargo, suele ocurrir que los programas dependen de componentes software muy conocidos y disponibles de serie en la mayoría de los sistemas operativos; es más, si acaso el componente no se hubiera instalado "de serie", los sistemas de gestión de paquetes actuales del software libre (uno de los puntos fuertes del software libre con respecto al propietario en cuanto al deployment) aplicarían automáticamente las dependencias que necesitara nuestro software, de manera recursiva. [Menor eficiencia de los recursos hardware, por tanto mayores requisitos para el usuario/cliente.]

  6. Utilización de mayor tamaño de memoria (volátil o disco): Debido al anterior inconveniente, el hipotético caso en el que usasemos un sistema operativo privativo lleno de aplicaciones propietarias, cada una de ellas requeriría sus propios componentes o librerías que se instalarían en disco y se cargarían en memoria cada vez que se requiera su uso. Además, incluso aunque las aplicaciones usaran componentes comunes, es muy probable que cada aplicación necesitase una versión específica de cada uno de ellos, por lo que nunca existiría uniformidad en el uso de API's, el sistema estaría mucho más congestionado y lleno de distintas versiones de lo mismo, instaladas o funcionando al mismo tiempo. En el software libre sin embargo la mayoría de las distribuciones, en sus versiones estables, incluyen una única versión de cada librería con la que funcionan muchas aplicaciones, por lo que el uso de las cachés, la capacidad requerida de disco y memoria volátil, son mucho más eficientes. [Peor rendimiento del software.]

  7. Menor seguridad: Por culpa los problemas de versionado comentados anteriormente, nos encontramos con que los programas privativos pueden estar usando (por necesidad) versiones distintas de las más actuales, por lo que hay un riesgo de seguridad al no estar usando las versiones más estables y más libres de problemas de seguridad de acceso o pérdida de información. [Menor fiabilidad en el software.]

  8. Mayor gasto de ancho de banda en las actualizaciones: Todo componente software ha de actualizarse y mantenerse, por lo que los programas de software privativo también. Como no existe un modo común para todos los programas de software privativo de actualizarse, se tiene que cada uno de ellos tiene su sistema, por lo que se está derrochando ancho de banda en comunicación por la red al actualizar cada programa sus versiones específicas de las librerías sobre las que dependen. En el software libre todo esto es mucho más centralizado ya que es el propio sistema operativo quien se encarga únicamente de gestionar todas las actualizaciones de todo el software instalado, tanto de las librerías como de los programas. [Mayor gasto de recursos.]

  9. Menor seguridad (frente a código/software malicioso): Esto es un tema que hace correr ríos de "bits" entre tantas opiniones que hay, y como no, yo aquí voy a dar la mía. Por supuesto que es factible la existencia de virus en Linux y otros sistemas operativos libres, y por supuesto que influye en su poca expansión hoy día dos factores importantes: a) Que estos sistemas operativos son minoritarios y por tanto, los programadores de virus prefieren no centrarse en ellos. b) Que estos sistemas operativos normalmente tienen muchos "sabores" (en el caso de Linux, distribuciones), lo que dificultaría a los programadores de virus desenvolverse bien para hacer que sus creaciones afectaran al máximo número de variantes posible (lo cual es una ventaja del software libre en cuanto a seguridad, pero la cual podría verse mermada en un hipotético mundo en el que el número de distribuciones destacadas se redujese drásticamente). Sin embargo, a pesar de todos estos manidos y no falsos argumentos, opino que el modelo de distribución del software libre dificulta también la propagación de virus. En un ejemplo ideal en el que tengamos una distribución que sólo tiene software GPL (que es a lo que tienden todas ellas), se dan las siguientes circunstancias:
    • El conjunto de la distribución no sólo incluye el "sistema operativo" pelado (como ocurre en el mundo del software propietario, en el que posteriormente hay que ir instalando programas de forma no desatendida), sino que incluye montones de programas para el uso diario del usuario, por tanto esta situación tiende a que, cada vez menos, el usuario se encuentre con la necesidad de instalar software externo, de terceros, sea libre o no.
    • El software incluido en la distribución normalmente se instala, en un primer momento, desde un conjunto cerrado e inmodificable de programas (un CD o DVD) en el que es impensable por tanto que ocurra un contagio (ojo que estoy hablando del S.O. + los programas; en el caso de Windows por ejemplo lo único disponible en medios de sólo lectura es el Windows, el Office, y el poco software original que dispongamos, para a partir de ahí empezar a instalar el resto de cosas que normalmente se descargan de internet).
    • Una vez instalado por primera vez el software de una distribución, posteriores instalaciones de programas o actualizaciones (sean de seguridad o no) suelen ocurrir desde los propios sistemas de actualización de la distribución mediante sistemas de repositorios de software remotos. La única forma de contagio que podría existir aquí es la suplantación de los servidores de la distribución, lo que sería bastante improbable pues cada vez tenemos empresas más grandes y, por tanto, responsables ante estas cuestiones de seguridad (¿cuántas veces se ha conseguido hackear la página de Novell?). Luego, esto sumado a que, en la situación de ejemplo ideal en la que nos encontramos, todo software distribuido, aunque precompilado, proviene de unas fuentes libres y abiertas al público, una situación en la que es cuasi-imposible la inclusión de código malicioso (aquí los detractores del software libre soltarían su manido "¡pero si nadie se pone a ver el código luego!", a lo que yo respondería: "el usuario de a pie no, muchos programadores tampoco, pero otros programadores y, sobre todo, los responsables de cada proyecto libre, sí revisan cada modificación").

    Por último, me gustaría mencionar otra ventaja que ocurre hoy día en la práctica (y que no tiene por qué ser una consecuencia del modelo de desarrollo del software libre, sino casi del modelo de desarrollo actual del software propietario, y que podría cambiar): la apuesta por la seguridad frente a la comodidad. Y para explicar esto sólo enunciaré las diferencias que existen entre el sistema de permisos de los sistemas de ficheros en sistemas tipo Unix frente a los de sistemas tipo Windows, para lo cual apuntaré a mis lectores hacía un enlace: Pregunta típica de nuevo usuario de Linux: ¿Qué antivirus?. Podría pensarse que a partir del título del enlace se va a hablar de un modo genérico de la seguridad frente a malware en Linux, pero al final sólo se centra más o menos en este aspecto práctico que yo también quería resaltar (y los comentarios que hay bajo esa entrada se desvían bastante también del tema, aunque sí son buenos puntos de vista, tanto a favor como en contra).

  10. Menor seguridad (frente a defectos software y el tiempo de su actualización): Tener el código fuente disponible permite que la gente lo modifique, y por tanto, permite que la gente lo arregle mucho antes. Con software privativo estás vendido a lo que quiera hacer la empresa con él y cuándo hacerlo.

  11. Mayor complejidad (de mantenimiento): Muchas veces ocurre que si un software puede enlazarse con bibliotecas privativas (a las que no se tiene acceso público para poder cambiarlas) hay que estabilizar API's para que los desarrolladores no tengan que cambiar constantemente su código. Pero esto en ocasiones (por ejemplo a la hora de comparar el kernel Linux con otros) provoca que se tenga que hacer trabajo extra manteniendo API's antiguas, y que el software evolucione más lentamente. [Mayor coste de mantenimiento (recursos humanos).]


Agradecería cualquier corrección o añadido a esta lista, que iré actualizando a medida que vaya recibiendo comentarios o que me vayan surgiendo ideas propias.

Actualización 27-ENE-2007: Como consecuencia de muchas de estas diferencias, aquí ofrezco un enlace a una lista de diferencias entre los dos SO's más populares de cada tipo de software. Ojo, son diferencias prácticas (que ocurren actualmente como consecuencia del tipo de software que son), no teóricas (no que impliquen que son diferencias que siempre se darán entre un sistema operativo libre y otro propietario; aunque algunas sí).

Actualización 05-ABR-2007: Añadido el elemento nº9 de la lista.

Actualización 10-DIC-2007: Después de leer este brillante artículo sobre el kernel de Linux, me veo obligado a añadir los elementos nº10 y 11 de la lista (aunque debería añadir más).

Labels: ,


Thursday, November 09, 2006

 

'beep' no es un programa

Pongámonos en antecedentes: últimamente estoy usando ciertos scripts para compilar programas, que en concreto se encargan de lanzar las invocaciones de las autotools necesarias para cada proceso de compilación (autogen, make, make clean, sudo make install, etc.), algo que en particular me parece un poco engorroso y precario, pero ese tema lo dejaremos para otra entrada.

El caso es que algunos de estos comandos se ejecutan con privilegios de administrador, por tanto les precede un comando "sudo". Este comando para poder ejecutarse con éxito pide por la entrada estándar la introducción de una contraseña, con el inconveniente de que si tardas mucho en introducirla, salta un time-out y el comando se cancela. Claro, entonces lo que me ocurre es que cuando quiero compilar un programa grande, invoco el script y lo dejo ejecutándose en una consola y, mientras, me voy a usar otras ventanas para hacer otras cosas, pero cuando vuelvo a la consola para introducir la contraseña, el comando ha expirado y tengo que volver a lanzar el script, procurando la próxima vez estar más atento.

Entonces aquí es cuando se dice lo de "¡beep al rescate!". Si escribimos en una consola la palabra 'beep', nuestro ordenador pita, y eso es lo que necesitaba poner justo antes de los comandos de sudo en mi script. Sin embargo, ¿qué ocurrió?:

./runsvn: line 15: beep: command not found

No pasa nada, una simple búsqueda en google y encontré la respuesta: beep no es un comando, sino un alias de la expresión 'echo -en "\007"', por tanto dentro de un script no podemos usarlo. La solución es usar la expresión entera, hasta que alguien empaquete en el bin de las distribuciones un programita muy simple que invoque esta llamada.

Labels: ,


This page is powered by Blogger. Isn't yours?

Categories

RSS of the category Gnome
RSS of the category Mono
RSS of the category C#
RSS of the category Programming
RSS of the category Mozilla
RSS of the category Web Development
RSS of the category Security
RSS of the category Open Source
RSS of the category Engineering
RSS of the category Misc
RSS of the category Politics

Contact with me:
aaragonesNOSPAMes@gnNOSPAMome.org

Archive
My Photo
Name:
Location: Hong Kong, Hong Kong
Follow me on Twitter