Archives marzo 2013

El software libre es (parafraseando a la Free Software Foundation), ante todo, una forma ética de entender el software o los programas de ordenador. Eso incluye tanto la fabricación de los programas como su distribución y su utilización.

La definición de la Fundación para el Software Libre dice que para que un programa de ordenador sea considerado software libre debe respetar cuatro derechos o libertades considerados como fundamentales para el usuario de ese programa:

Los usuarios deben tener derecho a utilizar el programa, sin restricciones, donde quiera, como quiera y para lo que quiera.

Los usuarios deben tener derecho a estudiar cómo funciona el programa y, si lo desean, a adaptarlo a sus necesidades específicas.

Los usuarios deben tener derecho a distribuir copias a sus amigos, empleados, conocidos, empleadores y, en fin, a cualquier persona que deseen.

Los usuarios deben tener derecho a mejorar el programa, publicar y distribuir sus mejoras al público (o a quien deseen) de modo que más personas salgan beneficiadas de los cambios.

Por tanto, en contra de lo que la mayoría de la gente piensa acerca del software libre, no es sólo una cuestión técnica y para técnicos, es una cuestión ética.

Es cierto que muchos informáticos y técnicos llegamos al software libre por las bondades técnicas del mismo, pero en mi caso particular, es un argumento (muy importante) más a su favor, pero no el único.

La ética que sustenta este movimiento de derechos, libertades, colaboración, horizontalidad, etc. es igual o más importante.

Si eres usuario de software (y si estás leyendo esto lo eres) te invito a que pienses sobre el software que utlizas, y qué tipo de valores apoyas con ello.

Fuente: www.tacande.net

Google lanza un centro de ayuda para páginas web hackeadas, en el que explica a los usuarios cómo recuperar los datos que hayan perdido

A cualquier webmaster o administrador de una página le amargará el día (como mínimo) descubrir que su web ha sido hackeada. Por suerte, ahora puede contar con la ayuda de Google para recuperar el control de la situación.

Tal y como anuncia en el blog oficial, Google ha lanzado una plataforma de ayuda para los webmasters que hayan sufrido un ataque de hackers informáticos. El centro de ayuda presenta instrucciones mediante vídeos que describen cada paso del proceso de recuperación. Los vídeos son presentados por Maile Oyhe, directora del programa de desarrolladores de tecnología de Google, y sus compañeros.

Google ya avisaba a los webmasters cuando su web había sido hackeada, pero ahora da un paso adelante con esta iniciativa. La ayuda se presta a través de vídeos (en total de una hora de duración) y artículos que ayudan a comprender en detalle cómo y por qué se hackea una web, además de las explicaciones sobre cómo recuperarse. Estas van dirigidas a profesionales con un nivel desde principiante hasta avanzado.

Google también presenta información sobre técnicas de spam y cómo detectarlo. Y también, para evitar males mayores, explica cómo prevenir ante todo ser hackeado: «Igual que te preocupas de construir una web adecuada para los usuarios y los buscadores, mantener el lugar seguro para ti y tus visitantes es vital».

Fuente: www.baquia.com

Steelcase ha diseñado Gesture, una silla que se ajusta a las diferentes posturas que adopta el usuario de un dispositivo móvil.

Hace algo más de dos años, Ubuntu anunciaba el proyecto Wayland, un nuevo servidor gráfico para sustituir a X.Org y así ahorrarse sus problemas de rendimiento y de código antiguo. Sin embargo, con la aparición de Ubuntu para tablets y teléfonos, el panorama ha cambiado y ahora las necesidades son otras.

Ahora se necesita un sistema mucho más abstraído de los drivers del sistema, más ligero, que facilite la interacción entre aplicaciones y la gestión de eventos de entrada (táctiles, de ratón o incluso 3D) y que esté listo para ampliarse en el futuro sin demasiados problemas. Por supuesto, pretenden que el rendimiento y la fiabilidad sean excelentes.

Según Canonical, Wayland no ofrece todas estas ventajas y por eso van a crear su propio servidor gráfico, Mir. La idea es que en abril de 2014 esté completamente listo e implementado en Ubuntu.

No parece una solución perfecta Aunque parece una solución buena, si nos vamos al otro lado y nos salimos del punto de vista Canonical las cosas cambian. Al menos eso es lo que piensa Aaron Seigo, uno de los desarrolladores más importantes dentro de KDE.

La principal crítica es que están reinventando la rueda, creando de nuevo más fragmentación en el mundo Linux en lugar de reaprovechar Wayland mejorándolo con lo que le falta. También hace notar que esto lo lleva haciendo KDE con Plasma Workspaces desde hace bastante más tiempo y sin tantos problemas.

Personalmente, no consigo formarme una opinión clara en esto. Estamos hablando de un tema muy complejo, y hay que tener experiencia en desarrollo de servidores gráficos para poder entender bien qué está pasando y saber si las razones técnicas que da Canonical son suficientes para justificar la creación de otro sistema.

Es cierto que estaría mejor que el desarrollo se basase en el resto de tecnologías y que colaborasen con KDE en el desarollo de Qt/Wayland y demás en otros sistemas y factores de forma. Pero, como digo, tampoco sé si esto es realmente posible en los plazos de tiempo que Canonical quiere cumplir.

Fuente: http://www.somoslibres.org

Desde hace mucho tiempo veo que ciertas personas difunden ideas erróneas sobre dos términos que definen la misma categoría de software. El propio Stallman escribió en su libro “Software libre para una sociedad libre”:

Los términos «software libre» y «código abierto» describen más o menos la misma categoría de software, pero implican cosas muy distintas acerca del software y sus valores. El Proyecto GNU sigue empleando el término «software libre» para expresar la idea de que la libertad, y no sólo la tecnología, es importante.

Algunos dicen que “más o menos la misma categoría de software” significa que son dos categorías diferentes. Eso es falso. Stallman pone lo de “más o menos” para no pillarse los dedos porque la OSI acepta algunas licencias que la FSF rechaza (y viceversa). Lo cierto es que comparten la mayoría de las licencias. Stallman intenta que se imponga el término “software libre” pero no tiene nada en contra del software de código abierto (en general) porque es prácticamente el mismo software que promueve desde la FSF (es algo que repite constantemente en sus conferencias).

¿Por qué hay gente que piensa que el software libre y el software de código abierto son distintos? Existen ciertas empresas, personas y organizaciones que quieren hacernos creer que el mero acceso al código fuente convierte a un software en “open source” y eso es falso. El software de código abierto (según la OSI) debe cumplir lo siguiente:

[V 1.9] Código fuente abierto (“open source”, en inglés) no significa el mero acceso al código fuente. Los términos para la distribución del software de código fuente abierto (“open-source software”, en inglés) tienen que cumplir el siguiente criterio:

1. Redistribución Libre

La licencia no deberá impedir la venta o el ofrecimiento del software como un componente de una distribución de software agregado conteniendo programas de muchas fuentes distintas a ninguna parte. La licencia no deberá requerir el pago de los derechos de autor u otra tasa por dicha venta.

2. Código Fuente

El programa tiene que incluir el código fuente, y tiene que permitir la distribución tanto en código fuente como en forma compilada. Si alguna forma de un producto no es distribuida con el código fuente, tiene que haber un medio bien-publicado de obtener el código fuente por no más que un costo razonable de reproducción preferentemente, una descarga a través de Internet sin cargo. El código fuente tiene que ser la forma preferida en la cuál un programador modificaría el programa. El código fuente deliberadamente ofuscado no está permitido. Las formas intermedias tales como la salida de un preprocesador o traductor no estan permitidas.

3. Trabajos Derivados

La licencia tiene que permitir modificaciones y trabajos derivados, y tiene que permitir que ellos sean distribuidos bajo los mismos terminos de la licencia del software original.

4. Integridad Del Código Fuente Del Autor

La licencia puede impedir que el código fuente sea distribuido en forma modificada solamente si la licencia permite que la distribución de “archivos parches” con el código fuente con el objetivo de modificar el programa en el tiempo de contrucción. La licencia tiene que permitir explícitamente la distribución del software construido a partir del código fuente modificado. La licencia puede requerir que los trabajos derivados tengan un nombre distinto o un número de versión distinto al del software original.

5. No a la Discriminación de Personas o Grupos

La licencia no tiene que discriminar a ninguna persona o grupo de personas.

6. No a la Discriminación de Campos Laborales

La licencia no tiene que restringir a nadie que haga uso del programa en un campo laboral específico. Por ejemplo, no puede impedir que el programa sea usado en un negocio, o que sea usado para una investigación genética.

7. Distribución de la Licencia

Los derechos adjuntos al programa tienen que aplicarse a todos aquellos que reciben el programa sin la necesidad de ejecutar una licencia adicional para estas partes.

8. La Licencia No Tiene que Ser Específica de un Producto

Los derechos adjuntos al programa no tienen que depender de que el programa forme parte de una distribución particular de software. Si el programa es extraído de esa distribución y es usado o distribuido de acuerdo a los términos de la licencia del programa, todas las partes a las que el programa sea redistribuido deben tener los mismos derechos que son garantizados en conjuncto con la distribución original del software.

9. La Licencia No Tiene que Restringir a Otro Software

La licencia no tiene que colocar restricciones en otro software que es distribuido junto con el software licenciado. Por ejemplo, la licencia no tiene que insistir en que todos los otros programas distribuidos en el mismo medio tengan que ser software de código fuente abierto.

10. La Licencia Debe Ser Tecnológicamente Neutral

Ninguna disposición de la licencia puede basarse en una tecnología o estilo de interfaz.

El punto 9 no es incompatible con la definición de software libre ¿Quieres contradecirme? Pues antes de hacerlo pregunta a los de la OSI por qué han aprobado la licencia GPL si no cumple sus criterios (obviamente no los incumple).

Si entendemos correctamente las condiciones, vemos que se mantienen las cuatro libertades que garantiza el software libre (según la FSF):

Un programa es software libre si los usuarios tienen las cuatro libertades esenciales:

La libertad de ejecutar el programa para cualquier propósito (libertad 0). La libertad de estudiar cómo funciona el programa, y cambiarlo para que haga lo que usted quiera (libertad 1). El acceso al código fuente es una condición necesaria para ello. La libertad de redistribuir copias para ayudar a su prójimo (libertad 2).

La libertad de distribuir copias de sus versiones modificadas a terceros (libertad 3). Esto le permite ofrecer a toda la comunidad la oportunidad de beneficiarse de las modificaciones. El acceso al código fuente es una condición necesaria para ello.

¿Por qué no comparten todas las licencias si son prácticamente lo mismo? Ahí entramos en las interpretaciones de los textos por parte de la OSI y la FSF. De hecho muchos desarrolladores de espíritu libre/abierto modificaron licencias para acomodarse a las exigencias de estas organizaciones. Otras quedaron fuera sin querer o a propósito. La situación se puede esquematizar así:

Dentro del software libre, la FSF recomienda el uso de aquel que sea compatible con su licencia GPL (dos nuevas subcategorías):

¿A donde quiero llegar con todo esto? Nadie puede decir que el software de código abierto es peor que el software libre, ni que es menos libre o que directamente no lo es. Es un absurdo comparar unos términos que engloban casi lo mismo. Por poner un ejemplo, Webkit es software de código abierto y software libre. Es una tontería intentar degradarlo diciendo que es un proyecto de código abierto pero no software libre. En cambio sí puedes decir que la licencia GPL es la mejor (según tu criterio personal) sin faltar a la verdad. La licencia BSD (de momento) sigue siendo una licencia de software libre aunque la odies.

¿Por qué «software libre» es mejor que «código abierto» (según la FSF)?

Aunque el software libre con cualquier otro nombre le daría la misma libertad, el nombre que usemos hace una gran diferencia: palabras diferentes transmiten ideas diferentes.

En 1998, algunas de las personas de la comunidad de software libre empezaron a usar el término «software de código abierto» (del inglés «open source software») en vez de «software libre» para describir lo que hacen. El término «código abierto» se asoció rápidamente con una aproximación diferente, una filosofía diferente, valores diferentes, e incluso un criterio diferente por el cual las licencias son aceptables. El movimiento por el software libre y el movimiento por el código abierto hoy son movimientos separados con visiones y metas diferentes, aunque podamos y trabajemos juntos en algunos proyectos prácticos.

La diferencia fundamental entre los dos movimientos está en sus valores, sus formas de mirar al mundo. Para el movimiento por el código abierto, el asunto sobre si el software debiera ser de código abierto es una cuestión práctica, no ética. Como alguien dijo, «el código abierto es una metodología de desarrollo; el software libre es un movimiento social». Para el movimiento por el código abierto, el software que no sea libre es una solución ineficiente. Para el movimiento por el software libre, el software que no es libre es un problema social y el software libre es la solución.

Fuente: http://www.somoslibres.org

El nuevo firmware Android 5.0 Key Lime Pie probablemente no vea la luz hasta el mes de mayo, momento en el que se celebra el Google I/O -el congreso de desarrolladores web organizado por Google- y que quizá sea aprovechado para presentar la nueva versión, que según parece podría basarse en el Kernel 3.8 de Linux.

Las últimas informaciones que llegan a este respecto, es que la compañía de Mountain View ha hecho público un repositorio experimental de Linux Kernel 3.8. Este, se basaría en un Kernel estándar de Linux en el que Google habría hecho algunas modificaciones. Estos nuevos datos, que provienen de la web Phoronix, podrían confirmar que Android 5.0 Key Lime Pie vendría con el Kernel de Linux 3.8, lo cual acallaría aquellas voces que indicaban que no sería así.

De confirmarse, será una buena noticia para fabricantes y desarrolladores

Además, este Kernel 3.8 incluiría algunas mejoras bastante destacables en la comunidad Android, ya que es el soporte para procesadores Nvidia Tegra y Samsung Exynos. Por tanto, si finalmente se confirman estas informaciones, sin duda se trata de una buena noticia para fabricantes y desarrolladores que, de cara a temas de compatibilidades, les evitará trabajo extra para poder soportar estos procesadores. También traería consigo un menor uso de la memoria RAM, lo que implica una mayor eficiencia y rendimiento.

No cabe duda de que Google está apostando fuerte por la nueva versión de Android 5.0 Kie Lime Pie, y se habla de que se está gestando algo grande dentro de la compañía de Mountain View (incluso parece que incluirá más cosas), para posicionarse frente a los nuevos sistemas operativos que se han presentado últimamente como Ubuntu y Firefox OS, que vienen pisando fuerte.

En definitiva, este tema ya está en marcha y los desarrolladores que así lo deseen pueden empezar a empaparse con el código antes de la salida al mercado de Android 5.0 Key Lime Pie. Las novedades parece que serán grandes.

Fuente: movilzona.es

 La multiplicación de dispositivos provoca que tengamos que adaptar el código para que sea flexible y dinámico.

Hasta hace unos años, los diseñadores sólo tenían que tener en cuenta la resolución de la pantalla del ordenador y poco más para adaptar sus creaciones. Como mucho, pensaban en las diferentes versiones de Internet Explorer…

Hoy en día, sabemos que probablemente ni el PC ni Internet Explorer conducen el tráfico a nuestra web (por lo menos, no la mayoría del tráfico), por lo que tendremos que tener en cuenta los accesos desde diferentes navegadores y dispositivos a la hora de programar nuestras páginas. Y es que está claro que el futuro de Internet es móvil.

Lo primero que tenemos que hacer es recordar que nuestra web no se verá igual en todos los navegadores y gadgets. Así que debemos centrarnos en un código basado en HTML5, que rompa los moldes fijos para adaptarse al tamaño y dimensiones que cada usuario espera encontrar en cada dispositivo.

Así, podemos diferenciar cuatro tipos de diseño:

– Fijo: el ancho es fijo, por lo que cambiar el tamaño del navegador o verlo en diferentes dispositivos no afectará al aspecto de la web. Sin embargo, será necesario un scroll horizontal para abarcarla entera, y tendremos una web que no tendrá buen aspecto en smartphones y tabletas.

– Fluido: la web se construye utilizando porcentajes para determinar la anchura de las columnas. De esta forma, las columnas serán proporcionales entre sí y el navegador, variando de manera fluida hacia más anchas o más estrechas.

– Adaptativo: se utilizan anchos fijos o relativos, pero el código incluye preguntas específicas para adaptarse a tamaños de pantalla específicos, como monitores pequeños, tabletas o smartphones.

– Sensible: este tipo de webs se construyen sobre un código fluido, y utiliza también preguntas para controlar el diseño y el contenido a medida que cambiar la escala para adaptarse al navegador o dispositivo.

En este vídeo de Treehouse podemos ver un resumen con las caracterísiticas de cada diseño:

Fuente: www.baquia.com