Y bueno, otro fin semana, otro momento para seguir la telaraña .

• Sobre la calidad de las notebooks nacionales.
• Conociendo un poco más la licencia BSD.
• TeXstudio, otro editor para LaTeX.
• Por qué amamos los bordes curvos.
• Instalar todas las aplicaciones de tu Ubuntu en otro Ubuntu.

Linux es diabólico, muy malo.

Quienes hemos tenido la oportunidad de conocer el entorno LINUX, sabemos que este es un sórdido mundo, donde lo malo, demoníaco y bizarro se presenta en la más diabólica y cruel de sus expresiones.

Linux es la más reciente mutación de un ancestral sistema operativo llamado UNIX, y heredó de este la mayoría de sus genes maléficos. Peor aún, hoy en día cualquiera puede verse inmerso, gratuitamente y por descuido, en un submundo absorbente lleno de extrañas criaturas, malignos conjuros y oscuros comandos.

En el centro de cada servidor Linux, vive un gran monolito al que todos llaman kernel. Alrededor de él, habita un gran número de perversas entidades, llamados procesos. Nadie parece conocer, a ciencia cierta, para qué sirven. Tras 20 años de experiencia en Linux/Unix, uno puede llegar a conocer algunos, y hasta saber lo que otros hacen. Sin embargo, la gran mayoría vive incógnita, actuando a sus anchas, obedeciendo las instrucciones del kernel y succionando la vida de nuestro computador.

Es en este punto donde se vuelve inquietante… Muchos de estos procesos llegan a convertirse en demonios (daemons). Por increíble y sobrenatural que parezca, los demonios no utilizan conjuros ni hechizos para rep

roducirse. Ellos utilizan un tenedor (fork) para crear otros demonios llamados hijos o niños (childs), que a su vez, imitan a su creador y siguen ciegamente sus pasos.

Este infernal purgatorio puede crecer y expandirse por sí mismo. Siendo Linux un sistema operativo multiusuario y multitarea, cientos de estos pequeños demonios pueden ser creados para abastecer a cuantas ingenuas víctimas humanas accedan al sistema; convirtiendo al servidor en un verdadero infierno, plagado de demonios, cada uno con vida y voluntad propia.

En la medida en la que el número de usuarios se reduce, sucede algo espeluznante. Los demonios padres comienzan a matar (kill) a sus hijos (child), sin piedad ni compasión alguna. Más aún, existen terribles comandos para matarlos a todos (killall) que asustan por la magnitud de la masacre que pueden ocasionar. Para una muerte compasiva existe el soft kill, y para las mas crueles el hard kill. El infame comando total kill, no requiere explicación. Como ven, es abundante el tipo de muertes que pueden darse.

¿ Le suena escalofriante ? Espere a leer esto:

En algunas ocasiones, un proceso niño (child) termina o “muere” (die) sin que su padre o creador se entere. Se dice que el proceso niño entra en estado difunto (defunct) o mejor conocido como zombie. Santo cielo! … Zombies ??? … El desafortunado proceso hijo, ya como zombie, no tiene memoria propia, y divaga errante, inútil, sin ser notado, por ninguno de los otros procesos activos del sistema.

A diferencia de los procesos y demonios “normales”, los temidos procesos zombies son inmunes al comando kill. Cruelemente, únicamente su padre tiene el poder de eliminarlo, cuando se le instruya con el comando wait, y lo liberará de su penuria removiendo su ID de la tabla de procesos vivos; enviándolo finalmente al lugar especial donde van los procesos cuando termina su existencia. Si el proceso padre se resiste, el administrador del sistema se verá obligado a matar (kill) al proceso padre (parent), lo que causará también la muerte de toda su descendencia,  procesos normales y zombies por igual….. Una masacre ciertamente  inmisericorde.

Por otro lado, existen también procesos huérfanos (orphans), cuyo padre y creador ha terminado su existencia. En este caso, el proceso huérfano es adoptado (adopted) por una maldita entidad suprema, el gran demonio creador de todos los demonios, llamado init. En lo sucesivo, será él quien controlará los actos de los huérfanos por el resto de su existencia. Para asegurar la incuestionable obediencia que init exige, la mayoría de los demonios en un sistema Linux/Unix tienen que ser huérfanos!. Solo así el malvado init podrá tener el control total de su maléfico infierno.

El Satán o Lucifer de este averno, llamado superusuario (su), es quien desde lo más reservado de una oscura  consola (console) dirige los destinos de este fantasmal inframundo. Es él quien al alcance de sus dedos, ostenta el poder de crear y administrar múltiples infiernos; y procurando la creación de demonios, solo para exterminarlos posteriormente.

Toda una historia de terror….

Ciertamente, la maligna imaginación de los desarrolladores de UNIX, al final de la década del 60,  trajo un velo demoníaco que 40 años después, aún persiste en  el sistema operativo y en todas sus variaciones. Como muestra, les indico que FreeBSD, otro sistema operativo similar a UNIX, adoptó un diablillo como logotipo; la imagen que apareciarán a la derecha de estas lineas.

Quienes sucumbimos al atrayente mal de esta tecnología, estamos condenados a vivir bajo su tenebrosa influencia, atrapados y errantes, sin ánimos de conocer ni explorar otros mundos.

Vivimos cautivados por la atracción de lo maligno.

Fabio Bettiol

Recientemente me entero gracias a Ext4, que ha sido publicada la versión 2.0 de GhostBSD. Para los que no la conozcan, este sistema operativo está basado en FreeBSD y viene con un escritorio GNOME. Es decir que es a GNOME, lo que PC-BSD es a KDE . Buscando lograr un sistema BSD apuntado al escritorio y sencillo de usar.

Entre las mejoras, de esta versión 2.0 se ofrecen:

• LiveCD con instalador propio en python (aunque todavía es por consola y no gráfico).
• Montaje automático de dispositivos.
• Nuevo logo.
• Varias mejoras en el GDM.
• Está basado en FreeBSD 8.2.
• GNOME 2.32.
• Rhythmbox 0.12.8_3.
• Pidgin 2.7.7.
• Firefox 3.6.
• Thunderbird 3.0.11.
• Se han corregido varios bugs de la versión anterior

Para todos aquellos interesados, pueden descargar las imágenes de GhostBSD desde su página oficial.

Esta semana va cortito el listado, pero bastante interesante en temáticas:

• Licencia BSD, el verdadero software libre.
• Eliminar Kernel Antiguos en Gnu/Linux (Debian y derivadas).
• Cuando el disco rígido falla.

Veo en Tux Files esta lista en donde nos hacen en recuento de 10 diferencias que existen entre los sistemas BSD y los GNU/Linux, ya que aunque ambos tienen similitudes, las diferencias existen . Y en sí, ambos son derivados de UNIX, el padre de todos.

Acá les dejo el texto original:

1. Licencias

Linux está licenciado bajo la GPL, qu etrata de evitar la distribución de binarios sin código fuente, dando mucha relevancia a la disponibilidad de ese código fuente. La licencia BSD es mucho menos restrictiva y permite la distribución basada en binarios, algo que es más permisivo puesto que permite que la siguiente persona que use (o modifique el código pueda no hacer que ese código esté disponible.

2. Control

El código BSD no está controlado por un único usuario, algo que muchos ven como una gran ventaja frente a Linux, cuyo código base (el kernel) está controlado por Linus Torvalds. En BSD no existe una persona que dicte lo que se puede y no se puede integrar en el código. Para este tipo de proceso hay un “equipo base” que dirige más o menos el proyecto, y que tiene más influencia en la evolución del código que los no miembros de ese equipo base.

3. Kernel vs Sistema Operativo

El proyecto BSD mantiene todo el sistema operativo, mientras que en el proyecto Linux se enfocan esencialmente en el kernel. Esto no es tan importante, no obstante, ya que muchas de las aplicaciones que se usan se están usando en ambos sistemas operativos.

4. UNIX-Like

Hay un viejo dicho en esa “batalla” BSD vs Linux:

“BSD es lo que obtienes cuando un puñado de hackers de UNIX se sientan para tratar de trasladar un sistema UNIX para llevarlo al PC. Linux es lo que consigues cuando un pulado de hackers del PC se sientan para tratar de trasladar un sistema UNIX para llevarlo al PC“.

O lo que es lo mismo: BSD es mucho más parecido a los UNIX originales, mientras que Linux es un sistema operativo nuevo basado, más o menos, en un derivado de UNIX (Minix, para ser más concretos).

5. Sistemas base

El sistema base para Linux no existe realmente, ya que Linux es un conglomerado de pequeños sistemas que hacen que al final obtengamos “un todo”. Muchos dirán además que el sistema base de Linux es el kernel, pero lo que es cierto es que el kernel no tiene mucho sentido sin las aplicaciones útiles que saquen partido de él.

Por contra, BSD es un sistema base que engloba un buen montón de componentes, como por ejemplo la librería libc. Muchos creen que esto genera un sistema base más coherente.

6. Más instalaciones desde el código

Debido a la forma en que BSD está desarrollando (usando el sistema Ports), más y más usuarios tienden a instalar aplicaciones a partir del código fuente y no a través de paquetes binarios. Esto puede ser un obstáculo para los usuarios noveles, aunque otros lo ven como una ventaja, ya que es posible compilar paquetes específicos que teóricamente sacan más partido de nuestra configuración hardware y software.

En Linux hay usuarios que instalan a base de compilar, pero confiamos cada vez más en paquetes binarios DEB como los que se usan en Debian o Ubuntu y RPM como en Fedora u openSUSE, por ejemplo.

7. Actualizaciones

En los sistemas BSD podemos actualizar todo el sistema base con un solo comando gracias a la concepción del sistema base (ver punto 5), pero además podemos descargar los fuentes que queremos compilar, y luego compilarlas para actualizar cualquier aplicación.

En Linux las actualizaciones se basan en los sistemas de gestión de paquetes, que no solo actualizan el sistema base (en este caso, el kernel), sino también toda la instalación, de modo que todos los paquetes instalados se benefician de la actualización.

Eso puede ser mejor ya que actualizamos todo, pero también puede tener sus desventajas, como que algo vaya mal en alguno de los componentes actualizados, algo que es mucho menos probable que pase en una actualización en BSD.

8. Tecnología punta

Es poco probable que en los sistemas BSD podamos disfrutar de tecnología punta en cualquiera de sus áreas. En Linux, por el contrario, hay multitud de distribuciones que permiten disfrutar de paquetes y tecnologías de última hornada que permiten a los fans de lo último de lo último poder probar dichos componentes.

9. Soporte hardware

En general Linux soporta nuevo hardware mucho antes que la plataforma BSD. Eso no significa que BSD no soporte tanto hardware como Linux, sino que Linux lo soporta antes que BSD (y en algunos casos, mucho antes).

Así que si quieres los mejores y más potentes gráficos, mejor que te olvides de BSD, y lo mismo si te compras un portátil con un nuevo chipset WiFi: si vas a instalar algo, quizá sea mejor optar por Linux.

10. Base de usuarios

Aquí el autor prefiere no entrar en demasiadas polémicas y advierte que hay excepciones a cualquier regla, pero en su opinión los usuarios con más conocimientos y menos conocimientos irían en una progresión que sería (según él), de menos a más, Mac -> Windows -> Linux -> BSD -> UNIX.

Realmente me ha parecido una buena idea la de abrir el debate sobre el tema. Y es por eso, que para empezar, acá les transcribo su texto entero. Al final, entre los comentarios, dejaré mi opinión.

La idea es que, tanto él, como ustedes y yo vallamos dando las opiniones de cada uno y al final, ver de sacar algo en claro. ¡Así que los invito a todos a comentar!

Sheridan dijo:

Para empezar, me gustaría no llamar al software propietario o de código cerrado como privativo, porque ya de por sí esto significa privar o restringir derechos o libertades y sería un término muy parcial, ya que el término surge además de conferencias sobre software libre.

******

Si estamos hablando de un artículo sobre si el software libre te hace realmente libre y se lo compara con el software privativo, esto ya de por sí está influyendo un poco sobre la opinión que las personas (sobre todo las que no saben del tema) puedan formar.

******

Básicamente, el software libre no te hace más libre, simplemante te da la oportunidad de ver y editar el código, agregar funcionalidades, etc. que en un soft cerrado se hace imposible por derechos de autor.

El software propietario es como un libro, tiene derechos de autor y su contenido no puede reproducirse sin la autorización de su dueño. Comprar un libro no te da el derecho de fotocopiarlo para un amigo. Tampoco te autoriza a escanearlo y subirlo a internet. Y mucho menos te permite modificarlo y redistribuírlo.

Como dije antes, es un tema de derechos de autor… Una empresa hace un soft y decide venderlo como producto enlatado. Es importante el concepto de venta, porque la venta se produce por expresa voluntad de ambas partes y establece un contrato entre las mismas en el cual se entrega un producto a cambio de dinero. Si hay voluntad en ambas partes es porque no hay nada de privativo en la operación… En otras palabras, no hay más misterios… yo se lo que compro y lo que podré realizar con el producto adquirido.

En cuanto a las libertades de las que se hablan en otros posts… esos no son derechos que un soft propietario está coartando… son simplemente beneficios extras que tiene el soft “libre” open source que permite a los desarrolladores modificar funcionalidades sin costo adicional pero también tendrá sus desventajas. Y esto no quiere decir que no tenga costo… porque no se olviden que el costo de adaptar una solución y de hacerle mantenimiento son costos de los que este tipo de soft no está excento. De hecho, hay casos donde por intentar adaptar uno de estos softs a las necesidades de una empresa se incurren en costos mayores a los que se hubieran tenido de comprar una solución enlatada con los costos de licencia y todo incluído…. pero bueno, eso ya escapa a este tema y daría mucho más para hablar.

Pero volviendo a este tema en particular, me gustaría decir lo siguiente para ir cerrando…

1) Uno siempre es libre de elegir.
2) Se puede elegir pagar un producto cerrado con alta compatibilidad o uno libre con baja compatibilidad (según el mercado).
3) Como dije antes, las “libertades” que brinda el software libre no son en realidad “libertades” que se pierden de adquierir soft propietario. Son a lo sumo ventajas que hay que evaluar.
4) Esas ventajas a evaluar tienen que ser ponderadas también contra las posibles desventajas que tenga el soft libre contra el propietario (por ej. el soporte al usuario).
5) Usar soft libre en este momento no es para todos… por ejemplo, a veces poder instalarlo implica revisar blogs y foros por todos lados para entender la manera de hacer que funcione correctamente.
6) No hay que olvidarse que el SP tiene propiedad intelectual al igual que el SL. El autor está en su derecho de decir como quiere distribuir su producto y, sin importar si estamos de acuerdo o no, nosotros no lo hicimos y no tenemos autoridad para criticar.

Faltaría recordar que la falta de compatibilidad es también una resticción a nuestras libertades si las consideramos de esa forma. Pero siendo que cada uno realiza la elección, en realidad se vuelve todo más bien una discusión filosófica que no lleva a ninguna parte… porque esta falta de compatibilidad quién la produce? el soft enlatado? pero si esa es la elección de otra persona entonces no podemos decir nada al respecto.

Para terminar, la libertad de cada uno está justamente en la posibilidad de elegir, teniendo en cuentas las ventajas y desventajas que acarrea cada caso, cuál es el producto que mejor se adapta a nuestras necesidades… Soft libre o “Privativo” son lo mismo en este caso.

Saludos!

PD: Perdonen errores de ortografía pero escribí todo acá y no hay corrector

PD: A todos los que deseen comentar, les recuerdo que las etiquetas blockquote, em, strong, etc de xhtml funcionan en los comentarios y pueden usarlas

El padre de Todos

Ken Thompson y Dennis Ritchie, trabajando en el DEC PDP-7

A pesar de que muchos usuarios han descubierto las bondades de Unix gracias a las más recientes distribuciones de Linux, como Ubuntu, lo cierto es que este sistema operativo tiene casi cuatro décadas de desarrollo. La historia de Unix comienza a finales de los años 1960, cuando el Instituto Tecnológico de Massachusetts (MIT), los Laboratorios Bell de AT&T y la General Electric trabajaban en la creación de un sistema operativo de carácter experimental llamado Multics (por Multiplexed Information and Computing Service). Multics corría en un “mainframe” (una clase de ordenadores muy comunes en la época que constaba de una unidad central que “atendía” a varias terminales “bobas”) de General Electric modelo GE-645.

Estas empresas buscaban desarrollar “un gran sistema operativo interactivo” que incorporase sólidas políticas de seguridad. Hasta ese momento, la seguridad de los datos la proporcionaba la escasa disponibilidad de los ordenadores, de los que había una pequeña cantidad y solo personal autorizado podía tener acceso a ellos. Pero la baja de precios y la popularización de los sistemas informáticos hacían indispensable integrar en el mismo corazón del SO las herramientas destinadas a proteger la información. El proyecto fue relativamente exitoso, e incluso existieron algunas “versiones para producción” de Multics, pero su pobre rendimiento hizo que AT&T decidiera desvincularse del proyecto.

Ken Thompson, uno de los programadores del equipo de los laboratorios Bell de AT&T, siguió escribiendo software para el ordenador GE-635. Entre otros programas, escribió un juego llamado Space Travel (Viaje espacial). Sin embargo, descubrió que el juego era lento en la máquina de General Electric y resultaba realmente caro, algo así como 75 dólares de EE.UU. por cada partida.  Así fue como, junto a su amigo Dennis Ritchie, escribió nuevamente el programa, pero esta vez utilizando el lenguaje ensamblador de un ordenador más popular (y barato) llamado DEC PDP-7.

Thompson  y Ritchie descubrieron que trabajar juntos era divertido. En 1969, y siempre dentro de los laboratorios Bell, armaron un equipo programadores -entre los que se encontraba Rudd Canaday- con la idea de desarrollar un sistema operativos que cumpliese con las premisas originales del proyecto Multics, pero que corriese en un DEC PDP-7. Comenzaron a trabajar en el sistema de archivos y en el núcleo del sistema operativo, que sería capaz de ejecutar procesos en simultáneo (multitarea). Además, crearon un pequeño intérprete de órdenes (o de comandos) y un reducido grupo de programas accesorios. El proyecto fue bautizado UNICS (por Uniplexed Information and Computing System) y, en principio, solo podía “atender” a dos usuarios a la vez. El mismo Kernighan fue el que eligió el nombre del nuevo sistema operativo, pero culpa de un juego de palabras UNICS se convertía un sistema Multics castrado (pues “eunuchs”, en inglés, es un homófono de UNICS). Entonces, se decidió cambiarle el nombre a UNIX, denominación que se mantiene hasta la actualidad.

"Arbol genealógico" de Unix

UNIX rápidamente llamó la atención de los niveles gerenciales de los laboratorios Bell, que de pronto tenían entre sus manos un sólido sistema operativo. La empresa no había gastado un solo dólar en el desarrollo de UNIX, pero cuando el Grupo de Investigación en Ciencias de la Computación decidió utilizarlo en una máquina más potente que el PDP-7, Thompson y Ritchie consiguieron el apoyo económico de AT&T. Comenzaron a reescribir el software para que funcionase en un ordenador PDP-11/20 y, por primera vez, en 1970, UNIX corrió en esa plataforma. Los programadores habían incluido entre las herramientas del paquete un programa capaz de dar formato a textos -llamado runoff- y un primitivo editor de texto. Todo el trabajo se realizó utilizando el lenguaje ensamblador de la PDP-11/20, y los laboratorios Bell utilizaron este primitivo “sistema de procesamiento de texto” para procesar las solicitudes de patentes que  recibían. En poco tiempo runoff recibió importantes mejoras y su nombre cambió a troff, considerado el primer programa de edición electrónica capaz de realizar composición tipográfica. El 3 de noviembre de 1971, Thomson y Ritchie publicaron el primer manual de programación de UNIX, el “UNIX Programmer’s Manual”

En 1972, Ken Thompson y Dennis Ritchie crearon el lenguaje de programación C. Si querían que UNIX fuese portado a otras plataformas, necesitaban un lenguaje de alto nivel pero que se mantuviese cerca del ensamblador. Su idea era que el código generado por el compilador de C fuese lo suficientemente rápido como para utilizarlo en la creación de sistemas operativos. Así, en 1972 se  tomó la decisión de escribir nuevamente UNIX, pero esta vez en el lenguaje de programación C. Esto permitiría que fuese modificado para funcionar en otros ordenadores y que diferentes versiones pudiesen ser desarrolladas por otros programadores. AT&T puso UNIX a disposición de las universidades, empresas privadas y del gobierno de los Estados Unidos, a través de licencias. El Departamento de Computación de la Universidad de California, con sede en Berkeley recibió una de estas licencias, y en 1975 desarrolló y publicó su propio “clon” de UNIX, conocido como Berkeley Software Distribution (BSD), que más tarde se convertiría en un fuerte competidor del UNIX de AT&T. Para tener una idea de los alcances de UNIX en esa época, basta con una frase de junio de 1972 atribuida a Dennis Ritchie y Ken Thompson: “…el número de instalaciones Unix ha alcanzado el número de 10, y esperamos que aumente...”

Un screenshot de Plan9, un sistema basado en UNIX

AT&T creó una división comercial, denominada Unix Systems Laboratories, para que se encargase  de la explotación comercial del sistema operativo. La aparición de nuevos ordenadores y el impulso recibido de parte de nuevos programadores -que utilizaban C para introducir mejoras- hicieron que fuesen liberadas diferentes versiones de UNIX. En 1975, el SO alcanzó la versión 6, que incluía  “pipes” (tuberías). Esto permitió dar una orientación modular al proyecto, consiguiendo aumentar aún más la velocidad de desarrollo. Se estima que en 1978, unos 600 ordenadores alrededor del mundo ya corrían alguna versión de UNIX. La versión 7, última basada en el UNIX original que tuvo una gran distribución, entró en circulación en 1979 y sirvió de base para la creación de Plan 9, un nuevo sistema operativo portable y distribuido, diseñado por los Laboratorios Bell para ser el sucesor de UNIX en tareas de investigación.

La empresa AT&T desarrolló y vendió UNIX System III (basado en la versión 7) a partir de 1981.La proliferación de versiones daba lugar a confusiones, así que la empresa decidió combinar todos los desarrollos propios con los de distintas universidades y empresas en 1983, dando origen al Unix System V Release 1. Esta versión introdujo características como el editor Vi y la biblioteca curses, desarrolladas por Berkeley Software Distribution. La división Unix Systems Laboratories de AT&T fue adquirida por Novell dos años más tarde, y se hizo cargo de la demanda por infracción de los derechos de copyright, revelación de secretos y violación de marca de mercado existente entre Unix Systems Laboratories y BSD. Los accionistas de Novell tuvieron que pasar el mal trago de descubrir grandes porciones del código de BSD habían sido copiadas ilegalmente en UNIX System V, y fueron contra demandados. Como la propiedad intelectual de Novell se reducía a unos pocos ficheros fuente, todo acabó en un acuerdo extrajudicial cuyos términos permanecieron bajo secreto a petición de Novell.

Solaris10, otro hijo de UNIX

De forma paralela al UNIX “oficial”, desde mediados de los ochenta, Richard Stallman, del Instituto Tecnológico de Massachussets, trabajaba en lo que más tarde se conocería como “software libre”. Stallman creo un sistema similar a UNIX con intenciones de cederlo gratuitamente, con el nombre de GNU (Gnu’s Not Unix. GNU no es Unix). En esos meses, un joven estudiante de ciencias de la computación finlandés llamado Linus Torvalds comenzaba el desarrollo del núcleo de un sistema operativo para ordenadores basados en la arquitectura “Intel x86”, que reproducía muchas de las funciones existentes en UNIX. El embrionario sistema operativo fue lanzado en forma de código abierto en 1991, con el nombre de Linux. El año siguiente ese núcleo Linux fue combinado con los programas desarrollados por el Proyecto GNU, dando como resultado el Sistema Operativo GNU/Linux.

El resto es historia: lo que comenzó casi como un pasatiempo de dos geniales programadores se convirtió en un potente, seguro y flexible sistema operativos, capaz de funcionar en un teléfono móvil, un ordenador personal o un cluster de ordenadores. Incluso el aplaudido sistema operativo Mac OS es UNIX completo y aprobado por The Open Group. Se diferencia en que posee una interfaz gráfica propietaria (Aqua), desarrollada en Objective-C en lugar de C o C++. A pesar de tener casi 40 años sobre sus espaldas, UNIX está más vigente que nunca.

Fuente: NeoTeo | Via Arcalinux

Para quien navega seguido por páginas sobre linux, software libre, tecnología y afines, es muy común oír la afirmación que dice: “El software libre siempre es mejor que el privativo”. Pero yo me pregunto: ¿es el software libre siempre mejor que el software privativo?.

Ya de por sí, podemos apreciar que la principal diferencia entre ambos tipos de programas es más de orden ético que de desempeño o rendimiento. Así que empecemos por lo más sencillo: ¿qué es “mejor“?. Que algo sea mejor que otra cosa, implica que es superior en alguna cualidad, sea ésta natural o moral[1]. O sea que algo no es mejor a secas, sino que es mejor en algo puntual, a no ser que sea superior en todos los aspectos posibles, lo cual lo veo medio difícil en el ámbito que estamos tratando. Es más, viendo lo dicho, ya salta a la vista que está mal expresada la pregunta “¿es el software libre siempre mejor que el software privativo?” porque no aclara en qué aspecto es mejor. Porque, si hace referencia a todas las cualidades posibles, la respuesta es un no rotundo. Ya que, en realidad, ambos son grupos con cientos y cientos de programas dentro, por lo que es imposible que todos los de un bando sean superiores a todos los del otro bando en todo. Así que, listo, ninguno es mejor y punto; se terminó la discusión.

Bueno, eso sería una salida fácil, pero vayamos por el camino difícil que siempre es más interesante. Reformulemos la pregunta a algo como “¿el software libre es mejor que el software privativo en X cualidad?“. Ahí me gustó más, pero ¿y la repuesta?. Muy simple, no hay una respuesta absoluta y ahora paso a explicar por qué.

En primer lugar, como son grupos de programas, no podemos enfrentarlos directamente y la comparación debemos hacerla entre los elementos de cada uno. Pero vayamos de a poco: si vamos a hablar de cualidades naturales, como ser rendimiento, consumo de recursos, aspecto visual, etc, debemos referirnos a programas concretos y evaluar cada caso puntual. Por ejemplo, comparar el rendimiento entre un programa privativo A y su alternativa libre B y, del análisis, que es netamente empírico, sacar conclusiones. Pero, como el análisis es empírico y se trata de una cualidad natural del programa, ¿qué importa que éste sea libre o privativo?. O sea, en el momento de hacer la comparación, estos aspectos no influyen en el resultado, ya que ambos son más de carácter moral que natural y hablan de las libertades del usuario que respeta dicho software y no de sus características técnicas puntualmente. En otras palabras, en el aspecto natural, que un programa sea libre o privativo no afecta directamente en el resultado de la comparación. Por lo que la pregunta no tiene mucho sentido en estos casos. Aunque presten atención al “directamente“, ya que ahí reside lo más importante.

Digo que no afecta directamente, y remarco esa palabra, porque indirectamente sí lo afectan; es más, tiene mucha importancia. Esto es así, porque el software libre posee mucho más potencial que el privativo debido a su propia idiosincrasia. ¿Cómo es eso?. Simple: el software libre tiene su código fuente disponible para cualquiera, por lo que todos pueden mejorarlo, depurarlo o corregir los errores que tuviese. Además, generalmente suele ser hecho en comunidad, logrando que mucha más gente esté ahí viendo el programa, por lo que los errores suelen ser descubiertos y corregidos más rápido. Por ejemplo, es muy común que, cuando un bug importante es encontrado dentro de un programa libre, no pase mucho tiempo hasta que se tiene una corrección o parche disponible para el mismo. En cambio, en el software privativo sólo los creadores conocen el código fuente, por lo que ellos son los únicos capaces de corregir los errores. Además, al ser un número limitado de personas, es lógico que se demoren más tiempo. Sin contar que, como nadie puede ver el código, existen errores que nunca son descubiertos.

Además, el software libre tiende a ser más confiable que el privativo, ya que, como todos pueden leer sus entrañas, es fácil descubrir si éste tiene alguna función “maligna” o, mejor dicho, alguna función oculta que realiza algo que no debería hacer o que no queremos que realice. En cambio, en el privativo, al no ver el código, es muy difícil descubrir algo así. En otras palabras, es más confiable porque puedo saber exactamente qué hace y cómo lo hace, con lo que yo tengo el control sobre mi PC. Mientras que con el software privativo no se sabe qué hace realmente el programa, por lo que, aunque no se puede acusar de que haya cosas raras, tampoco se puede corroborar que los programas no las tengan.

En resumen, se puede apreciar que el software libre tiene potenciales de confianza y evolución mayores al software privativo, con lo cual, sus aspectos naturales irán mejorando, posiblemente, a un ritmo mayor que su contrapartida.

Igualmente, considero que la mayor ventaja natural que tiene el software libre es el hecho de su adaptación. O sea, cualquiera puede simplemente adaptarlo a sus necesidades, logrando así optimizar las cualidades naturales de un programa a su conveniencia y eso es algo que, dentro de los programas privativos, es muy poco común. Ahí es uno el que debe adaptarse al programa privativo o depender de si el creador del mismo desea aplicar o mejorar eso que necesitamos, convirtiéndonos en meros espectadores de los cambios. Mientras tanto, en el otro caso, desde el inicio se tienen las herramientas necesarias para esa tarea, léase: el código fuente. Y en cuanto a éste aspecto, no considero válido decir que una persona sin conocimientos del tema no puede hacer uso de dicha adaptabilidad, puesto que puede llevar el programa o el código fuente a un especialista (programador) y éste puede realizar el trabajo por ésta.

Bueno, creo que el aspecto natural ha quedado más o menos claro, así que pasemos al moral. En este caso, moralmente sí tiene muchísima importancia el hecho de ser libre o no, ya que afecta directamente sobre esta área. Pero, bueno, volviendo a nuestra pregunta, estábamos en “¿el software libre siempre es mejor que el software privativo en X cualidad?“. Pero, como ahora vamos a tratar el tema moral, podríamos preguntar de esta forma: “¿el software libre es siempre moralmente mejor que el software privativo?” Yo considero que sí, ya que, el software libre no restringe mis libertades como usuario. Para ejemplificar, primero, recordemos las 4 libertades que definen al Software Libre, las cuales podríamos resumir como la libertad para ejecutar el programa, modificarlo, adaptarlo y para distribuirlo [2]. Por lo que, si un amigo ve el programa que estoy usando y me pide una copia, puedo dársela sin problemas. En cambio, dentro del software privativo, muchas licencias estipulan que sólo uno mismo puede hacer uso de su copia del programa y que no puede dársela a nadie. Por lo que estaría en una encrucijada, entre quebrar la licencia que yo mismo acepté cumplir previamente y darle la copia a mi amigo, o respetar la licencia y le decirle que no. No sé ustedes, pero yo no podría fallarle a un amigo, y con el software libre no tendría esos dilemas morales.

Pero, bueno, la moral no es algo estándar en todo el mundo: cada sociedad e, incluso, cada persona tiene su propia moral y es menéster de cada uno el juzgar ese aspecto. Pero, al menos en mi caso, yo pienso que sí, que el software libre, en todo su conjunto, es mejor moralmente que el software privativo.

Bueno, creo que a esta altura del texto, y si todavía queda alguien leyéndolo, ya hemos tratado la mayoría de los aspectos referentes a nuestra propuesta inicial, en donde preguntaba si el software libre era siempre mejor que el privativo. Por lo que, a modo de conclusión, solo me resta decir que, en mi opinión, uno va a juzgar un software en base a sus necesidades y va ha ser de acuerdo a éstas el lugar que obtendrá dicho programa en nuestra propia lista. Para ésto, cada uno ordenará las cualidades naturales y morales de acuerdo a su propio orden de valores, y en base a eso tomará sus decisiones. En mi caso, yo comparto los valores que tiene el software libre, considero que éste debe ser así y, por ende, cuando elijo un programa lo primero que veo es esa cualidad. Luego, entre los candidatos libres usaré criterios naturales como rendimiento o aspecto visual para elegir uno hasta llegar al que mejor me parezca.

Pero, ¿me estoy perdiendo muchos programas privativos que son realmente buenos?. Sí, posiblemente me pierda muchos buenos programas privativos, pero como son privativos ya sé que no son compatibles con lo que yo busco, por lo que, realmente, no me estoy perdiendo de nada.

__________________________________________________

[1] Definición según la RAE

[2] La definición de Software libre está tomada de la página de GNU. Existen también otras definiciones como la BSD.

Nota: Haciendo click en las imágenes, se accede al sitio de sus autores.

Nota: No te olvides de leer el post hermano de éste: ¿Soy más libre por usar software libre?

Les dejo la info:

BSDday Argentina es una serie de conferencias y charlas hechas por y para desarrolladores, administradores, usuarios e interesados en los sistemas operativos basados en en kernel BSD, y proyectos de software libre relacionados.

A lo largo de los dos días del evento informaremos sobre BSD, su filosofía, los diferentes sistemas operativos basados en este kernel y las ventajas de utilizar este software.

BSDday Argentina 2009 se realizará en la Ciudad de Buenos Aires, Argentina, durante los días 29 y 30 de Mayo del 2009 en el Departamento de Computacion de la Facultad de Ciencias Exactas y Naturales de la Universidad de Buenos Aires.

La entrada es gratuita y es necesario registrarse.

Para aquellos que no los sepan, los sistemas BSD pertenecen a la familia UNIX, poseen un Kernel de sistema y otras partes de software que no son necesariamente las que estamos acostumbrados a utilizar quienes frecuentamos el mundo GNU/Linux.

El evento organizado por OpenBSDeros será el primero en su tipo en el país argentino y abarcará tanto charlas filosóficas como técnicas relacionadas a tales sistemas libres.

Llamamos a la comunidad del software libre a difundir la noticia colocando banners en sus sitios web.

Encontrarán más información sobre el evento en su página web oficial: http://www.bsdday.org

Unetbootin es una aplicación que nos permite instalar varias distribuciones GNU/Linux y BSD en pendrives, dispositivos USB o en un disco duro. sin necesidad de usar un CD o DVD.

El mismo programa tiene soporte incluido para descargar e instalar automáticamente la distribución que deseemos. Igualmente, si nuestra opción no está en la lista, solo necesitamos tener una imagen ISO de la misma.

Los sistemas operativos soportados actualmente son: Ubuntu, Debian, Linux Mint, openSUSE, Arch Linux, Damn Small Linux, SliTaz, Puppy Linux, FreeBSD, NetBSD, Fedora, PCLinuxOS, Gentoo, Zenwalk, Slax, Dreamlinux, Elive, CentOS, Mandriva, FaunOS, Frugalware Linux, Foresight Linux, VectorLinux, Slackware

El programa está bajo una licencia GPL 2.0 y pueden descargarlo desde su página oficial.