Paquetes Linux Debian

Tengo un poco de lío con los paquetes de Debian, en concreto Testing, referentes al kernel. Cuando realizamos una consulta a la cache del repositorio de apt nos sale un listado larguísimo de paquetes relacionados con el kernel Linux, lo cual puede confundir a error, o al menos en mi caso.

Voy a intentar ir describiendo cada uno de los paquetes que nos puede aparecer al realizar un apt-cache search linux (|grep linux para filtrar un poquico).

Bajantes y Seguros

Hace ya unos tres meses que vengo sufriendo un problema con un bajante el cual me está mojando toda la pared y techo.

En primer lugar se avisó al seguro de la comunidad, el cual envió un extranjero de una empresa de reparación que lo único que hizo fue abrir un boquete y decir que no es problema de la comunidad, sino que es un problema particular de mi vecino de arriba.

Una vez abierto el agujero, se podía observar que la perdida se deslizaba y filtraba por el bloque de cemento.

Avisado mi vecino de arriba con el cual ya tengo problemas por otro bajante (del cual espero hablar en breve), y tras largas discusiones por no reconocer su avería, consigo que de parte a su seguro. Estos mandan a un perito [1] que valore los daños.

El perito llega un día, con la mala suerte de que no se apreciaba la fuga continua en ese momento, e indica a mi vecino de arriba que suba y abra todos los grifos del servicio que se encuentra encima de la avería. Supongo que por la presión de agua producida al abrir todos los grifos, se aprecia que por la junta de los tubos de la imagen, revoca una pequeña lágrima de agua, por lo que determina que el problema proviene de la conexión de los tubos que no está bien sellada.

En parte, tiene razón, ya que dicha junta debería estar sellada para prevenir posibles escapes, e incluso malos olores, pero le indico que la fuga principal debe encontrarse en otro lado, puesto que es escape que vimos provenía del bloque de cemento, por lo que a mi entender, debe de filtrase desde otro punto de la tubería, a lo cual, no me hace ni caso, y me indica que como yo estoy de obras en la oficina, van a realizarme un ingreso por la cantidad que determinen en función de un baremo que según un baremo que según ellos se ajusta a los precios de mercado, a lo cual, yo acepté (en que mala hora).

Pues bien, me ha ingresado 130 putos € para que realice las pertinentes reparaciones. Yo sinceramente, no se en que baremo se habrán basado, pero la empresa de construcción que me está realizando las obras en el local me dice que por ese precio no se molesta ni en mandarme al fontanero, y la verdad, es que en vista de las imágenes, yo hago un llamamiento, ¿alguien con una empresa de reparación está dispuesto a repararme los daños ocasionados por la perdida de agua a ese generoso precio?.

En mi humilde opinión, habría que reparar la tubería, tapar el agujero, y enlucir la pared, que lleva una masilla para alisar la pared y se me está despegando, ya que inicialmente era gotelé.

El caso es que para evitar daños mayores, he llamado por mi cuenta a un fontanero para que me tapone la junta que “según el perito del seguro” era ocasionante del recalo.

Una vez sellada la tubería, tal y como yo le había avisado al perito, el agua sigue saliendo. Y no!, no proviene de dicha junta, sino que proviene de más arriba, ya que sale a través del cemento.

Creo que las imágenes lo dicen todo, y se aprecia perfectamente de donde proviene el agua, y el que no lo vea, debería hacerse perito para alguna compañía importante de seguros…

Ahora tras llamar al teléfono de Atención a Siniestros, me dicen que eso es un nuevo parte, que quien tiene que llamarlos es su asegurado, siendo este mi vecino de arriba, con el cual me resulta imposible hablar y explicarle que el peritaje que hicieron en primer lugar no es del todo correcto, y que me dice que lo suyo ya está arreglado y que llame al seguro de la comunidad que el no quiere saber nada.

Pues a día de hoy, así están las cosas, y ya no se que hacer. He llamado a una empresa de reparación para ver si pueden repararlo aunque sea a mi costa, y así al menos me quito el problema de en medio, aunque también tengo pensado dejar puesta una denuncia, en cuanto la empresa de reparación localice el foco de la avería, ya que no estoy seguro si pertenece a la comunidad o a algún vecino.

La verdad es que no se para que valen los seguros, si cuando tienes una avería por lo general no la cubren, y si la cubren lo hacen de malas maneras, y reparar, lo que se dice reparar, no reparan nada. A mi esto me está pasando con un seguro de la compañía La Estrella, pero supongo que esto pasa con todas las compañías de seguros, que al parecer, lo único que hacen es llenarse los bolsillos con el dinero de sus asegurados, para luego no responder de forma efectiva ante los partes por averías.

Y ya puestos a decir, el teléfono de atención al cliente para siniestros, el cual funciona solamente de 9:00 a 12:00, es una puta mierda. Primero cada vez que llamas te dicen que las líneas están colapsadas, y que por tu bien te recomiendan llamar en otro momento. Claro, lo normal es que cuelgues y lo intentes en otro momento… ¡no!, ¡mal!, no lo hagas. Si les haces caso te pasarás la mañana intentando llamar para encontrar las líneas desocupadas, cosa que al parecer nunca pasa. Hay que quedarse a la espera, con el celular pegado a la oreja, y esperar, y esperar, y esperar, y esperar, y así hasta la media hora en el que por fin te atiende una señorita que no te va a solucionar nada, pero por lo menos le habrás chillado a alguien y por un momento te sentirás bien, aunque al colgar vuelve la sensación de frustración cuando te das cuenta de que no te han solucionado nada, y que aun te deben quedar, como mínimo, otros tres meses de luchas y peleas para que algún día, el agua de este país, ese bien tan escaso, preciado y querido por todos, no se desperdicie día tras día.

[1] Perito, experto en alguna materia o ciencia, cuya actividad es vital en la resolución de conflictos (Wikipedia)

Creative Commons Attribution-NonCommercial-ShareAlike 2.5

Sigo sin entender, como un portal de documentación sobre una distribución Linux de Software Libre, puede tener una licencia Creative Commons Attribution-NonCommercial-ShareAlike 2.5

Es cierto que en el campo FLOSS (Free/Libre Open Source Software) hay multitud de diferentes opiniones (por poner un ejemplo las de Richard Stallman y la Free Software Foundation, o la de la Open Source Initiative), y también una cantidad impensable de licencias (como la GPL, BSD, MPL, CDDL, OSL, etc) y ciertamente no soy ningún experto ni conocedor de temas legales, y ni que decir tiene que no me he leído todas estas licencias y ni siquiera se si algún día lo haré.

De cualquiera de las maneras, sigo siendo incapaz de concebir que una documentación referente a un software libre (ya sea kernel, distribución, aplicación, librería, etc), desarrollada de manera colaborativa mediante una plataforma generalmente de las llamadas Wiki, tenga una licencia tan restrictiva como es la citada anteriormente, y digo restrictiva principalmente por la clausula NonCommercial, ya que tal y como yo entiendo el Software Libre sea cual sea su licencia, es la de la posibilidad de hacer un uso comercial de dicha obra, llamase código, documentación, gráficos, etc.

Claro, como ya he dicho, esto es solo una opinión más de todas las ya existentes, como diría Juan Cuesta, en esta nuestra comunidad.

¿Adaptar o contribuir en software libre?

Desde hace más de una década se viene hablando de software libre en una u otra forma. Afortunadamente, cada vez es menos una cuestión de GNU/Linux y más de modelos de desarrollo o de negocio.
En las diferentes charlas a las que podemos asistir hoy en día se mezclan frases como «la economía de las personas», «web 2.0», «servicios de valor añadido», «desarrollo distribuido», «copyleft» o «dictadores benevolentes».

Todas parecen coincidir en que el software libre –la cultura libre– es una marcha imparable porque procede de los individuos exigentes y alfabetizados digitalmente. Esto es más una voluntad bienpensante que una realidad hoy en día, pero hay que reconocer que, de momento, no hay señales de alarma que ilegitimen ese sueño.

Sin embargo, en cuanto a los modelos de desarrollo referidos al software libre hay un exceso de confianza ciega en «los otros». Efectivamente, ya sea porque nos consideramos pequeños en la vorágine copyleftera o porque nos gusta descansar sin más en las espaldas de lo que los gurús comentan, caemos en el error de repetir como loros las siete maravillas del software libre.

Analicemos una de esas siete maravillas: «el software libre es mejor que el privativo porque permite realizar adaptaciones a medida de las necesidades del cliente». Esta frase parece grabarse a fuego en todo documento doctrinario. Posibilidad de adaptación gracias a la posesión del código fuente = bien. Lo contrario = mal. Veamos hasta qué punto es aplicable esta afirmación.

La adaptación del código fuente de un software concreto para satisfacer necesidades particulares no es nada nuevo bajo el sol. Se ha hecho toda la vida independientemente de la naturaleza legal del software. Lo original del hecho de que se rija bajo una licencia libre es que habilita a mucha más gente esas adaptaciones en su copia local y, por tanto, pueden cumplirse las expectativas de muchos más usuarios finales (o, al menos, más perfiles de usuario). Por lo tanto, al igual que las licencias libres como la GPL no son rupturistas con la Ley de Propiedad Intelectual, sino que la enriquecen en sus diversas expresiones, el software libre no inventó la posibilidad de adaptación del código, simplemente la elevó a cotas mucho más interesantes.

Si a ello le sumamos algo ya bastante asumido, que las nuevas tecnologías banalizan cada vez más la réplica exacta –la clonación digital– esperando obtener algún beneficio o dividendo por otras vías y no por tener dos bits en 0 en lugar de sólo uno, tendremos un lema intrínseco al software libre: copiar, sí; plagiar, no.

Sin embargo, tras proceder a descargar en nuestro disco duro el software Z y mirarlo con ojos golosos pensando «tengo todo el potencial a mi disposición y sólo dependo de mi pericia como desarrollador», suele surgir una débil y minúscula pregunta que, en la mayoría de las ocasiones, queda sepultada por una mezcla de pereza y baja autoestima.

La pregunta a la que me refiero es: «¿Convendría que contribuyera al propio proyecto en lugar de hacer una versión a medida de mis necesidades?»

Esta pregunta es igual de relevante tanto si nos encontramos en un contexto puramente personal o de ocio, como si lo enfocamos desde un punto de vista profesional o remunerado. En este artículo me centraré en el segundo modelo.

Ahora mismo, mientras lee este artículo, multitud de empresas de todo el mundo tienen ocupados a buena parte de sus técnicos desarrolladores en descargar software libre para probarlo, jugar con él, simular un caso práctico, realizar comparativas con software privativo y, cómo no, integrarlo en un proyecto software concreto.

En un porcentaje nada desdeñable de estos casos, el software libre descargado es alterado o mejorado en algún punto para adecuarse perfectamente a las necesidades del equipo desarrollador. Puede ser simplemente una forma diferente de compilación, sustitución de un componente por otro o hasta la alteración del código fuente.

En los dos primeros casos, podemos entender la naturaleza «documental» del esfuerzo y, si bien sería de agradecer su puesta en común en foros o listas de correo, es perfectamente comprensible que el día a día nos arrastre e ignoremos este gasto de tiempo. Veamos dos ejemplos que a muchos les sonarán familiares si han desarrollado alguna vez (o manipulado con cierto grado técnico software en general) y que opino que ilustran razonablemente mi punto de vista:

• Encontramos un problema. Buscamos solución en Internet (típicamente, googleando). Nos agrada encontrar a más gente con el mismo problema pues nos da esperanza. Finalmente, leemos respuestas del tipo «Al final lo arreglé, era una tontería. De todas formas, gracias por la ayuda». De la «tonteria» ni rastro. La frustración nos invade.
• Encontramos un problema. Buscamos solución en Internet seguros de encontrar a más gente en idéntica situación (por ejemplo: el software afectado es bien conocido y el contexto es habitual). No encontramos nada. Finalmente, lo solucionamos por nuestra cuenta. No nos tomamos el tiempo de comunicar la solución. Alimentamos el círculo vicioso del misterio con la sensación personal de ser un crack.

¿Verdad que le suenan? Lógicamente, no podemos activar una Policía de la Colaboración Mundial; sólo insistir en las bondades de participar en un modelo en donde aportamos una solución o ayuda cada mes y, a cambio, recibimos mil de éstas al día (y, desde el punto de vista ético, satisfacción personal).

Si volvemos al hilo principal, queda pendiente el asunto de «alteración del código fuente». Aquí ya el escenario es más propio del proyecto o necesidad concreta del equipo de desarrollo. De nuevo, podemos optar por modificar y no decir nada. Con no decir nada me estoy refiriendo a no comentarlo en los foros o listas de correo del proyecto software original ni, por descontado, proponer su inclusión en el código fuente de la versión matriz.

Si la licencia del software que hemos estado modificando es de tipo copyleft «fuerte» (como la GPL) y nos obliga a distribuir las modificaciones bajo la misma licencia, tenemos tres opciones:

• Ignorar la GPL, violando una licencia y arriesgándonos a que el titular del copyright nos demande por infracción legal. Resulta vergonzoso el número de veces que se produce.
• Cumplirla y distribuir la versión modificada «tal cual», sin ningún afán de identificar las nuevas funcionalidades o cuestiones técnicas asociadas. Esto es quizá poco profesional pero lícito y comprensible.

En el caso de ser una licencia más flexible (aunque, en mi opinión, menos libre globalmente) como las del tipo BSD, pueden seguir dándose los dos escenarios anteriores aunque el primero de ellos será más difícil de alcanzar por las menores imposiciones sobre las obras derivadas a las que hay que atenerse.

• Por último, queda, creo yo, la única opción inteligente a medio y largo plazo: integrar parte o todo de los cambios en la versión «oficial». Para ello, hay que formar parte del equipo principal de desarrollo o contribuir con parches y correcciones. Esa condición es la clave para poder influir verdaderamente en el desarrollo actual y futuro de un producto y mientras nosotros, o nuestros clientes, vayan a depender de él de manera significativa no hay que desdeñar esta posibilidad en absoluto.

Imaginemos un caso práctico: tenemos un producto software libre para fabricar Intranets corporativas (secciones con documentos, gestión de vacaciones, notas de gasto, foros, noticias, etc) al que llamaremos FreeIntranet. Al evaluarlo nos convence su madurez, el número de instalaciones en el mundo, la calidad del código y su carácter multilingüe. Nos lanzamos a un proyecto con un cliente X que nos obliga a integrar FreeIntranet con su directorio de usuarios corporativo (para que los empleados hagan login de la forma en la que ya lo hacen con otras herramientas). No hay problema, pensamos; FreeIntranet es compatible con el producto de directorio de usuarios del cliente. A la hora de la verdad resulta que no es todo tan sencillo[1] y hay que invertir horas en arreglar errores de interpretación de formato, codificación de caracteres y rendimiento. Para ello, ha habido que tocar código de bajo nivel y librerías incluidas en FreeIntranet pero, para consuelo de todos, finalmente aquello marcha perfectamente.

Pasa un año y nuestro cliente, satisfecho con nuestro trabajo en la Intranet corporativa, nos encarga una ampliación (ahora quieren un blog por empleado, encuestas, gestión RR.HH y descarga de la nómina en PDF). En principio estamos de enhorabuena pero todo puede torcerse si no hicimos bien los deberes al término del anterior proyecto. Al parecer, FreeIntranet ha pasado de la versión 3.5 a la 4.0 en este tiempo y, como lo ideal sería desarrollar las nuevas funcionalidades con la flamante nueva versión 4.0 con AJAX, consideramos seriamente la actualización de la plataforma 3.5 ya instalada en el cliente a la 4.0. En principio, los módulos funcionales que se pidieron en su momento necesitarán cambios menores (referentes a la API, por ejemplo) pero no ocurre lo mismo con la parte de autenticación contra el directorio de usuarios. De la 3.5 a la 4.0 no ha habido mejoras en ese sentido y, lo que es peor, se ha alterado completamente el módulo de gestión de usuarios, haciendo imposible trazar una correspondencia entre las dos secciones de código, la 3.5 y la 4.0. Desafortunadamente, es necesario volver a realizar todo el trabajo de integración. Ello supuso tantos quebraderos de cabeza en su momento que surgen ahora dudas sobre la conveniencia o no de imponer la 4.0. Al final, optamos por ser conservadores y seguir con «lo que funciona». Es decir, mantener la 3.5, con lo que el cliente no se beneficia de las mejoras aparecidas en la 4.0 y los desarrolladores «sienten» que están trabajando con tecnología, si no «legacy», si «deprecated».

Como amante de los proyectos tecnológicos, esta posibilidad me aterra y propongo evitarlo siempre que haya alguna posibilidad. ¿Qué alternativa sería deseable?

Tras el final del proyecto primero, el asociado a la versión 3.5, el equipo de desarrollo debería haber limpiado el código, documentado los cambios y, de forma modular, proponer su inclusión en la versión oficial. Lógicamente, cuando fusionamos ingeniería informática y software libre la palabreja «meritocracia» salta como un resorte y nos obliga en parte a defender con argumentos sólidos nuestra contribución.

• ¿Está bien codificada? ¿Cumple el estándar propio del proyecto FreeIntranet?
• ¿Está bien documentada? ¿Se comprende bien dónde empieza y dónde acaba nuestra contribución?
• ¿Qué resuelve exactamente? ¿En qué situaciones es útil?
• ¿Qué dependencias de terceros tiene?

No es seguro que nuestra aportación sea aceptada pero no intentarlo es ciertamente poco profesional. Cada línea de código o funcionalidad que consigamos introducir en el repositorio de código de FreeIntranet, seguirá su vida cuasiindependiente en la evolución global y más compleja del software y tiene grandes posibilidades de mutar adecuadamente en el paso a la versión 4.0, enriqueciéndose incluso de aportaciones de otros desarrolladores que construyen mejoras sobre nuestra propuesta ahora que pueden emplearla en situaciones como la que nosotros nos encontramos y que no eran tan infrecuentes.

Naturalmente, si las modificaciones son críticas, convendrá estar pendiente de su evolución dentro del mar de código general y defender su permanencia (de nuevo, con argumentos sólidos) o alterarlas si lo estimamos conveniente. Debemos valorar objetivamente el ahorro de trabajo y la satisfacción de nuestros clientes al pensar en la supervivencia de nuestra contribución.

En definitiva, el modelo, tanto de desarrollo como de negocio, basado en el software libre no depende de si hay más o menos autores (todos estamos, de alguna manera, obligados a fabricar o crear) sino de qué decisiones tomamos como autores y cómo nos coordinamos para invertir tiempo en lugar de gastarlo sin más. De lo contrario, estaremos mucho más cerca del modelo del software privativo de lo que creemos.

Notas:

[1] En esto no hay diferencia esencial entre software libre y software privativo.

Fuente | diacritica.net

e-verano 2007: Una mirada a la Sociedad libre

Tras la formidable experiencia del pasado verano, donde se juntaron varias experiencias entorno al Conocimiento Libre, las nuevas Redes Sociales, Web 2.0 y la cultura geek, denominada e-verano.org : Una mirada a la Sociedad libre, volvemos a esta nueva edición, con objetivos renovados y nuevos retos.

En esta ocasión, el e-verano.org ha sufrido algunas modificaciones, la principal motivada por la demanda de los participantes, en su fecha, del 16 al 30 de julio de 2007.

Por otro lado, este año tenemos la suerte de contar con la implicación y apoyo de la Universidad Pablo de Olavide, que en cuanto conocieron el proyecto decidieron apostar firmemente por el mismo.

Por este motivo, también trasladamos la sede de esta nueva edición a la propia Universidad y a su moderno campus. Queremos también destacar el apoyo de las diferentes entidades e instituciones que hacen posible la realización de esta edición, principalmente la Consejería de Innovación, Ciencia y Empresa de la Junta de Andalucía , el Centro de Gestión Avanzado (CGA) de la Consejería de Educación de la Junta de Andalucía y Fundecyt – Consejería de Infraestructura y Desarrollo Tecnológico Junta de Extremadura

Esperamos poder estar a la altura de las expectativas que para esta edición se han levantado y seguir siendo el evento de conocimiento libre referente del verano en el panorama nacional.

Destinatarios:

El siguiente proyecto, cuyo enfoque es eminentemente prágmático, va dirigido a la comunidad internacional en general, así como a personas vinculadas con los siguientes sectores:

• Profesores Centros TIC y Ciclos
• Alumnos Centros TIC y Ciclos
• Dinamizadores de Centros de Alfabetización Digital:Guadalinfo,NCC,Telecentros,…
• Empresarios y futuros empresarios
• Emprendedores
• Comunidad Universitaria(estudiantes,profesores,técnicos,…)
• Ciudadanía(Guadalinex y GNU/Linex entre otros)
• Comunidad del Software Libre: Desarrolladores, programadores, usuarios, …
• Profesionales

Número de Participantes:

• 4 JTASL (Jornadas Tecnológicas de Software Libre): 200
• Cursos de Profesorado: 150
• Cursos Técnicos de Perfeccionamiento: 150
• Symposium: 120
• Convivencias de profesorado técnico de secundaria: 120

Totales: 740

Desarrollo:

Las actividades se desarrollarán del 16 al 28 de julio de 2007.

• Recepción de propuestas (Call for Papers) hasta el 16 de junio.
• Matriculación/inscripciones a partir del día 27 de junio.
• Campaña publicitaria (web, radio, televisión, prensa y calle) a partir del 12 de junio.
• Presentación oficial el 5 de Julio

Licencia Wikipedia

Como todos sabemos, la Wikipedia es lo que se entiendo como una Enciclopedia Libre. ¿Y que quiere decir esto de Libre?.

Pues en mi humilde opinión tenemos que entender libre tal y como es definido dentro del proyecto GNU, ya que la licencia que utiliza la Wikipedia para proteger su contenido es la Licencia de Documentación Libre de GNU o lo que es lo mismo GFDL o simplemente FDL.

¡Puede usar libremente esta información, siempre que cumpla con las condiciones de la licencia!

El lema de Wikipedia es «La enciclopedia libre que todos podemos editar», y el proyecto es descrito por su cofundador Jimmy Wales como «un esfuerzo para crear y distribuir una enciclopedia libre, de la más alta calidad posible, a cada persona del planeta, en su idioma», para lograr «un mundo en el que cada persona del planeta tenga acceso libre a la suma de todo el saber de la humanidad».

Existen tres características esenciales del proyecto Wikipedia que definen conjuntamente su función en la web:

1. Es una enciclopedia, entendida como soporte que permite la recopilación, el almacenamiento y la transmisión de la información de forma estructurada.
2. Es un wiki, por lo que, con pequeñas excepciones, puede ser editada por cualquiera.
3. Es de contenido abierto y utiliza la licencia GFDL.

Sin embargo, a la hora de utilizar el texto de los diferentes artículos existentes en la enciclopedia me surge una duda. Creo recordar, que según la licencia, tenemos la posibilidad de utilizar el contenido de las obras así licenciadas, pero con el requisito de citar la fuente y autor, pero ¿quién es el autor?. Quizás únicamente citando la fuente (Wikipedia) sea suficiente pero ¿y si no es así?, ¿quien es el autor de un determinado artículo?.

La verdad es que es una putada, pero me va a tocar leerme la licencia FDL o más bien una traducción no oficial de esta, y digo no oficial ya que las licencias son “legales” en su idioma original, y cualquier traducción no es más que eso, una traducción no oficial.

¿Cuál es el futuro de NVIDIA en GNU/Linux?

En una reciente entrevista a Andy Ritger, director de software UNIX en nVidia y uno de los máximos responsables del desarrollo de controladores para Linux, se habla acerca del futuro del soporte de nVidia bajo Linux.

Al parecer prtenden continuar con su actual política de controladores: por un lado la versión abierta del driver 2D (nv), y por otro, su driver propietario 3D que seguirá utilizando la misma filosofía que hasta ahora.

Referente al proyecto Nouveau, el responsable de nVidia afirma que es un proyecto al que no prestan ayuda, pero que tampoco tratan de detener.

El proyecto Nouveau pretende desarrollar unos drivers libres para aceleración hardware 2D (EXA) y 3D (DRI) en las tarjetas Nvidia.

El desarrollo se está realizando mediante ingeniería inversa e intentando aglutinar los diversos esfuerzos del actual driver libre “nv”.

Para tomar datos de las tarjetas hacen uso de dos apliaciones: Renouveau, con la que realizan pequeños test OpenGL y observan los cambios que se realizan en los registros de la tarjeta, y mediante una modificación de nvclock pueden leer/escribir directamente en los registros de las tarjetas Nvidia.

Fuentes:

http://www.linuxjuegos.com/2006/10/16/nouveau-drivers-3d-libres-para-nvidia/
http://barrapunto.com/softlibre/06/10/16/1113255.shtml

A mi juicio, no está de más plantearse que si la mayoría de usuarios de Linux usamos tarjetas gráficas de nVidia frente a soluciones similares, es por el echo del soporte que siempre han dado hacia Linux, y la aceleración 3D. El día que el proyecto Nouveau pueda competir con los controladores propietarios de nVidia, seguramente ya no estén a tiempo para colaborar en el desarrollo de este proyecto, o quizás sí…

Pero creo que lo más grave no es eso, sino que están perdiendo una gran oportunidad, frente a otras empresas como es el caso de Intel, cuyas últimas noticias es que han liberado los controladores para sus tarjetas gráficas, haciendolos Open Source, por lo cual, mi próxima adquisición, se me plantea como apoyar esta iniciativa comprando el portátil con una tarjeta gráfica Intel, en lugar de una nVidia como tenía pensado al principio, por la sencilla razón de que un driver libre facilita la compatibilidad software en el tiempo de un hardware, que por anticuado, deje de ser interesante mantener por los drivers oficiales.

Tira Guadalinex V4

Parece que la nueva versión de Guadalinex, la distribución Linux de la Junta de Andalucía, ha llegado hasta el proyecto LinuxHispano.

Esto es una buena noticia que hará mucha publicidad al proyecto Guadalinex, ya que la tirada de esta tira cómica a mi entender es infinitamente superior a la de muchos medios tradicionales, ya que somos muchos (yo me incluyo) los que tenemos enlazada dicha tira en nuestro blog, página personal, e incluso portales dedicados a la informática, especialmente al Software Libre.

Lo que me extraña un poco, es que tratándose de un proyecto originado en La Plata (Argentina) hablen de nuestra distribución andaluza Guadalinex, habiendo otras muchas distribuciones de las que hablar, pero seguramente algo bueno habremos echo para estar ahí.

De momento me toca esperar a ver si la próxima versión de Guadalinex viene con los nuevos escritorios 3D y sus transparencias, para ver si las camisetas hacen honor a la distribución ;o)