Amantes del software libre

[ArcticWolf]

Hace un tiempo fue la charla de la directora general de Microsoft en mi universidad, y según me contaron, a la señora esta la bombardearon de preguntas sobre el costo de las licencias y la ineficiencia de su sistema, a lo que respondió que ellos estaban enterados del cambio de panorama empresarial al que se tenían que enfrentar y que iban a reenfocar los esfuerzos a otros productos. En otras palabras, se les va a acabar la pista si se mandan más macanas, y lo saben.

Ten a tus amigos cerca, y...

[pescaupintau]

pensé que nunca lo diría... pero, bien por microsoft. ¿el motivo? Liberaron 20k líneas de código para un driver de no-se-que para linux, y lo hicieron con licencia gpl.
Ahora alguien vendrá a decirme que es gpl2, o que lo hacen en su beneficio y cosas así... pero yo contestaré con: podrían no haberlo hecho (de hecho, esa fue la política de siempre no?) o preguntaré que empresa que trabaje con software libre lo hace por amor al arte y no para sacar unos pesos extra*?


*gasttigre-señal?

[arlick]

BUAJAJAJA

BUAJAJA... BUAJAJAJAJA!!

¿bien por microsoft? mmm... bien por evitar una batalla legal que no le beneficia

--

Y después del triunfo de relaciones públicas que resultó para Microsoft la reciente liberación de sus drivers de Hyper-V bajo la licencia GPL se reveló que más que altruismo, esa decisión bien podría haber sido una oportunista acción legal.
Según Stephen Hemminger, ingeniero en Vyatta (empresa que comercializa productos de software y hardware para redes basados en código Open Source), un driver de red en Hyper-V usaba componentes licenciados bajo la GPL y era linkeado estáticamente a otras partes binarias. Esto violaría los términos de la GPL, que no permite mezclar elementos de código libre con otros privativos.
Greg Kroah-Hartman, un programador de Novell y líder del Linux Driver Project, también parece confirmar este hecho.
La conclusión es ahora que Microsoft podría haber actuado simplemente para contrarrestar una potencial embarazosa disputa legal sobre la violación de la GPL.

http://feedproxy.google.com/~r/vival...v-violo-la-gpl

---

No podía ser tan bueno como lo pintaban todos, ¿microsoft colaborando libremente? antes se congela el infierno!! (lo que no deja de ser una desgracia).

[pescaupintau]

ya me parecía demasiado bueno para ser cierto. Al menos esta ves prefirieron liberar a pleitear

[arlick]

Estoy creando un administrador de paquetes inspirado en slackpkg (más bien copiado ) para slackware, llamado slackby, hecho en ruby.

Si alguien quiere probarlo puede hacer esto:

svn checkout http://slackby.googlecode.com/svn/trunk/ slackby
cd slackby/stable
ruby slackby.rb help

Va mucho más rápido (mucho muchísimo) que slackpkg, aunque aún faltán un par de cositas por hacerle. De todas formas ya es perfectamente funcional.

Lo he testeado con la versión de ruby que hay en el repositorio de slackware-current (1.8.7), aquí se puede obtener el paquete:

http://darkstar.ist.utl.pt/slackware...174-i486-1.txz

Antes de instalarlo sería recomendable actualizar todo con slackpkg:

slackpkg update
slackpkg upgrade-all
slackpkg install-new

sunossssss, te animas a probarlo? XD

[ArcticWolf]

¡Grande, Arlick! Me dan ganas de probarlo, pero en estos momentos no tengo Slack instalado... Veremos si hoy lo descargo, así lo pruebo. Ruby no es lo mío, pero nunca viene mal conocer otro lenguaje (más).

[arlick]

Originally Posted by ArcticWolf

¡Grande, Arlick! Me dan ganas de probarlo, pero en estos momentos no tengo Slack instalado... Veremos si hoy lo descargo, así lo pruebo. Ruby no es lo mío, pero nunca viene mal conocer otro lenguaje (más).

Da verguenza el código . Tengo que empezar a pensar en los posibles ojos que lo vean si llega hasta donde quiero que llegue, que sea el administrador de paquetes por defecto \o/ (<- Paso 1. Paso 2: Dominar el mundo).

[ArcticWolf]

Originally Posted by arlick

Da verguenza el código . Tengo que empezar a pensar en los posibles ojos que lo vean si llega hasta donde quiero que llegue, que sea el administrador de paquetes por defecto \o/ (<- Paso 1. Paso 2: Dominar el mundo).

Bueno, por eso es que me gusta un poco más Python, porque fuerza a que seas mucho más ordenado y claro. Pero bueno, si no tenés tiempo de hacer bindings en C y querés un poco más de eficiencia, lo siguiente es Ruby (en escala de claridad-facilidad). Creo que son las dos nuevas navajas suizas del administrador Unix. :P

¿Podrías detallar un poco cómo manejás los paquetes y las actualizaciones? Usás un archivo de texto plano como base de datos, o sqlite?

[arlick]

Originally Posted by ArcticWolf

Bueno, por eso es que me gusta un poco más Python, porque fuerza a que seas mucho más ordenado y claro. Pero bueno, si no tenés tiempo de hacer bindings en C y querés un poco más de eficiencia, lo siguiente es Ruby (en escala de claridad-facilidad). Creo que son las dos nuevas navajas suizas del administrador Unix. :P

¿Podrías detallar un poco cómo manejás los paquetes y las actualizaciones? Usás un archivo de texto plano como base de datos, o sqlite?

[mmm... tal vez todo esto tenga que estar en un futuro en la página de googlecode]

El sistema es el mismo que el de slackpkg. No hay ningún tipo de dependencia, de descarga los ficheros de los repos oficiales y los instala/actualiza/reinstala, según hayas pedido.

En el repo hay diferentes carpetas: slackware (todo el sistema básico de slackware), extra (fácil de deducir), patches, pasture... (*)

Todos esos directorios tienen dos ficheros importantes: PACKAGES.TXT y MANIFEST.bz

El fichero PACKAGES de cada directorio te dice que paquetes hay, cual es su subcarpeta en el repo y una descripción. El fichero MANIFEST podría ser más bien algo opcional, pero puede ser útil. Tiene un listado con todos los ficheros que tiene cada paquete.

Útil para buscar que paquete tiene X librería que se te ha perdido. Solo tendrías que usar ruby slackby.rb search-file <fichero> y busca los paquetes que contienen ese fichero (en realidad los ficheros que contienen ese nombre, no hay que poner el nombre exacto).

Todo se usa con ficheros de texto plano, excepto los de los índices de ficheros, que son descomprimidos, formateados y comprimidos en formato gzip, así es más fácil de usar.

Hay dos funciones que son tal vez las más importantes: get_local_packages (fichero local_packages.rb) y get_remote_packages (fichero remote_packages.rb). Ambos devuelven un lista hash (creo que se llama así, un diccionario en python) tipo:

["nombre_paquete" => objeto_paquete]

Objeto paquete es un clase que he creado para comparar versiones a partir del nombre del paquete de forma sencilla (fichero package.rb).

De esta forma si quieres actualizar los paquetes solo hay que:

* obtener listado de paquetes instalados
* obtener listado de paquetes remotos leyendo ficheros descargados (fichero PACKAGES.TXT)
* comparar listas y crear una con los paquetes remotos ya instalados tal que sean diferente version de los ya instalados (**).
* descargar cada paquete y usar los comandos de pkgtools (installpkg, upgradepkg, revemopkg).

Y la mayor parte de las opciones es jugar con eso. También está el fichero ChangeLog.txt del repo. El programa tiene opción de ir mostrando el changelog.

Tengo que decirlo así... ME ENCANTA la forma de trabajar con arrays y hashes de ruby, además de los string. No tengo otra forma de decirlo. ME ENCANTA el poder usar sobrecarga de operadores (chupate esa java!). ME ENCANTA que para manejar un fichero comprimido o para usar uno en texto plano solo hay que cambiar una palabra, el tipo de objeto a crear.

Con slackby mostrar la lista de paquetes a actualizar tarda menos de un segundo. Con slackpkg tarda... mucho, no me dio por medirlo, es muy molesto.

Tiene una opción que no tiene slackpkg y es que sale un sencillo menu para elegir repositorio y versión, en vez de andar editando ficheros.

(*) Por ahora solo usa el directorio slackware, ya me pondré con lo otro, pero con eso es más que suficiente.

(**) Compara que sean diferentes y no solo una versión mayor porque eso podría dar problemas. Si quieres hacer un downgrade no podrías si solo muestra lo que tenga versión superior, por ejemplo.

[ArcticWolf]

¡Excelente! Veo que tiene muchísimas ventajas, y si es tan bueno entonces hasta podría llegar a reemplazar (o mejor, complementar) el administrador de paquetes actual. El proceso de manejo es simple, aunque el tema de la falta de dependencias me asusta un poco (rpm ).

¿Qué tal integrarlo con dbus, opcionalmente? Podrías hacer (o que alguien más haga) un applet que se encargue de actualizar la lista de paquetes seguido, indicar las actualizaciones e incluso brindar varios frontends.