Archivo mensual: octubre 2016

Bios Chip

Algo que siempre se ha asociado al sistema operativo Windows es, entre otras cosas, la actualización de la Bios.

Cuando adquirí mi portátil lo primero que hice, antes de eliminar Windows, fue actualizar todo lo actualizable desde ese sistema. Después ya instale Ubuntu 15.04 o la 15.10 con Gnome.

Pues bien, el tema esta en que una vez que la versión 16.04 ya paso a estable me salían un par de errores referentes a Intel, decir que mi portátil es un Think Pad X1 Carbon de 3ª generación con un Intel Core i7-5600U CPU @ 2.60GHz x 4 y que tiene menos de 1 año desde que lo compre.  Decir también que funciona extraordinariamente bajo GNU/Linux y no hay nada que envidiar a otros sistemas operativos ni Hardware existentes en el mercado., pues bien, estuve buscando soluciones en la red y también expuse lo que me sucedía en Launchpad y foros especializados en GNU/Linux. Mi pequeña obsesión por tener siempre lo último, o lo más actualizado posible, me llevo a encontrar un tutorial sobre como actualizar la Bios desde GNU/Linux, cosa rara, ya que normalmente es algo peliagudo de realizar y ya no digamos desde cualquier distribución GNU/Linux.

Este tutorial dice lo siguiente:

Entrar en la web de Lenovo para descargar el archivo más reciente de nuestro modelo de portátil.

Descargar el archivo ISO más reciente, nombrado como Bios Update (Bootable CD)

Convertir ese archivo ISO en un .img con la utilidad geteltorito, si no la tienes instalar con un simple:

sudo apt install genisoimage

ejemplo del comando para crear el bios.img:

geteltorito -o bios.img n14ur11w.iso

Insertar una memoria USB, teniendo en cuenta que el .img que generamos no pesa más de 40 o 50 MB.

Comprobar muy bien donde nos monta el USB para crear con él un booteable con el bios.img, por ejemplo yo lo llevaba en Descargas:

cd Descargas

Con el comando dd realizamos el proceso:

dd if=bios.img of=/dev/sdb bs=1M

Reiniciamos el portátil y con F12 booteamos.

Yo tuve que entrar en la Bios y volver a activar el Secure boot y cambiar al modo UEFI desde Legacy mode, ya que he preferido tenerlo así. Además es una tontería mantener una Bios con estos sistemas de control por parte de Windows.
Si no cambiamos estos valores nos nos dejará bootear y por tanto actualizar la Bios.

bios7

Una vez cambiando y guardado volvemos a reiniciar y entrar con el USB. Se nos abrirá un menú con 3 sub-menús.

Dejar el USB hasta después del reinicio que es cuando se actualizará la BIOS, de hecho yo no lo quite hasta cambiar de nuevo la BIOS al modo Legacy y estar ya en mi flamante Ubuntu 16.04 con Gnome.

La versión que tenía de la Bios era la 1.10:

sudo dmidecode -s bios-version sudo dmidecode -s bios-release-date
N14ET32W (1.10 )
08/13/2015

Y ahora llevo la última 1.12, pero ha habido como 4 versiones intermedias entre una y otra:

sudo dmidecode -s bios-version sudo dmidecode -s bios-release-date
N14ET34W (1.12 )
02/04/2016

Feliz flasheo y leer siempre, siempre los Readme.

Como todos los años, la Oficina de Software Libre estará presente en las Jornadas de Recepción de Estudiantes 2016-2017, que tendrán lugar en los paseillos universitarios, donde estaremos encantados de contaros las diferentes actividades que hacemos en el día a día en la OSL, desde cursos a asistencia en software libre como talleres o hackatones.

Desde la OSL tenemos preparada una sorpresa de la que solo podemos adelantar que esta muy relacionado con nuestro deseo de ayudaros a aprender y que será de gran utilidad a la hora de aprender  a programar , como por ejemplo en Python.

Solo podemos deciros que estéis muy atentos a las redes sociales, principalmente a nuestro Twitter: https://twitter.com/OSLUGR y mañana por la mañana podréis averiguar que tenemos preparado.

Unidad de Calidad AmbientalOficina de Software Libre Delegación de la Rectora para la Universidad Digital

 

Orientado a estudiantes de Bellas Artes, Conservación y Restauración de Bienes Culturales, Comunicación Audiovisual, Arquitectura, Informática y otros posibles interesados, del 26 de octubre de 2016 al 25 de enero de 2017 tendrán lugar en la Facultad de Bellas Artes de Granada una serie de talleres relacionados con diferentes herramientas digitales libre. Esta enfocado a aplicaciones relacionadas con multimedia, dibujo, imagen y sonido. Los talleres tienen un enfoque práctico y en los mismos los asistentes podrán llevar su propio ordenador para llevar los ejemplos a cabo. Los talleres son gratuitos, y serán impartidos por profesorado de la UGR, personal de la misma y técnicos de la OSL.Más información sobre el programa y formulario de inscripción en

http://bellasartes.ugr.es/pages/tablon/*/cursos-seminarios-talleres-/talleres-de-software-libre-multimedia-3a-edicion

En ocasiones, necesitamos tener varios entornos de trabajo distintos, con distintas versiones del intérprete, distintas librerías, etc.

Una de las soluciones más comunes es usar varios ordenadores o varias máquinas virtuales, cada una con una instalación diferente.

Pero Python nos provee de una herramienta simple y útil para facilitarnos ese trabajo, sin necesidad de recurrir a soluciones más complicadas. Esta herramienta es “virtualenv”.

virtualenv es un programa que permite crear entornos virtuales de Python. Un entorno virtual consta de un intérprete (podemos elegir la versión concreta) acompañado de todos los módulos que necesitemos instalar. Se pueden tener varios entornos distintos, instalando en cada uno los módulos que necesitemos, sin que unos entornos afecten a los otros.

Vamos a verlo de forma práctica.

Para empezar, necesitamos instalar la propia aplicación virtualenv. Esto se puede hacer desde el gestor de paquetes de tu distribución (apt-get, emerge, yum, pacman…) o, de manera más general, con pip (en cualquier caso, hacen falta permisos de superusuario):

pip install virtualenv

Tras esto, ya tendremos el programa instalado y podemos comenzar a usarlo.

En Python 3 nos podemos ahorrar el paso de la instalación, porque ya viene por defecto.

virtualenv guarda cada entorno virtual en un directorio con el nombre de ese entorno. Dentro de ese directorio se guardarán todos los archivos necesarios (de ellos nos interesan, en particular, los módulos que instalemos en el entorno y el script que lo inicia).

Es una buena idea tener en tu home un directorio donde agruparemos todos los entornos virtuales. En mi caso, en una escandalosa falta de originalidad, ese directorio se llama “virtualenvs”.

Crear un entorno virtual es muy simple, del siguiente modo:

virtualenv DIRECTORIO-DEL-ENTORNO-VIRTUAL

Por ejemplo:

virtualenv nuevo-entorno

O, en mi caso, que estoy usando ese directorio llamado virtualenvs que ya he comentado para agrupar todos mis entornos:

virtualenv virtualenvs/nuevo-entorno

Al hacerse en espacio del usuario, ni la creación de un entorno virtual ni (como veremos más adelante) la instalación de paquetes en él, necesitan permisos especiales.

Esto crea el nuevo entrono en el directorio que le hemos indicado, creando en él una estructura de directorios, copiando allí el ejecutable de Python y otros archivos necesarios, e incluyendo algunos módulos por defecto (en realidad, la mayoría de ellos son enlaces simbólicos a los originales, a menos que usemos la opción –always-copy, que cambia este comportamiento).

Para que virtualenv nos dé más detalles durante la creación de nuestro entorno, podemos usar la opción –vervose (o -v en su versión corta):

virtualenv --vervose virtualenvs/nuevo-entorno

Si necesitamos que nuestro entorno virtual ejecute una versión concreta del intérprete de Python (que, lógicamente, debemos tener instalada en nuestro sistema), podemos indicarlo con la opción -p de este modo:

virtualenv -p /usr/bin/python3.5 virtualenvs/nuevo-entorno

Si no se indica la opción -p, se usará el intérprete en /usr/bin/python.

Una vez creado nuestro entorno virtual, necesitamos activarlo para poder usarlo. Para ello vamos a usar uno de los scripts que se han instalado por defecto al crearlo. El script necesario es activate, y se encuentra en el directorio bin que se ha creado dentro del de nuestro entrono virtual:

source mis-virtualenvs/mi-entorno-virtual/bin/activate

La orden source se encarga de ejecutar en la sesión de shell actual el script que se le pasa como parámetro (es decir, que el efecto es el mismo que si el usuario tecleara esas instrucciones en su consola) en lugar de en su propia shell, como se ejecutan normalmente los scripts.

Al hacer esto, el prompt de shell cambiará para indicar que se ha activado el entorno virtual, poniendo el nombre de este delante del prompt habitual, de un modo parecido a este:

(nuevo-entorno) usuario@host:~ 

A partir de este momento cualquier comando o script de python que se ejecute lo hará en el entorno virtual. Y, lo que es más importante, cualquier módulo que se instale (con pip, no con el gestor de paquetes del sistema) lo hará también en el entorno virtual y no afectará ni al resto de entornos virtuales que podamos tener, ni a la instalación de Python del sistema.

Naturalmente, esto se aplica sólo a la sesión en la que se ha activado el entorno virtual. Si abrimos otra sesión en otro terminal, por ejemplo, esa sesión tendrá el entorno de Python normal de nuestro sistema. Por supuesto, se pueden tener varios entornos virtuales distintos corriendo simultáneamente en diferentes sesiones sin ningún problema.

El comando deactivate desactivará el entorno virtual, volviendo al entorno normal:

deactivate

Cualquier módulo que se haya instalado en el entorno virtual se “desvanecerá” como si nunca hubiese estado ahí, hasta que se active de nuevo el mismo entorno virtual.

Para eliminar un entorno virtual que no queramos volver a usar, sólo es necesario borrar el directorio de su mismo su nombre con todo su contenido.

virtualenv es una herramienta muy útil que tiene otros usos más allá de lo que se comenta en este artículo. Se pueden ver más opciones de este programa en su propia ayuda:

virtualenv --help

¿Te interesa? Este artículo se ha escrito como parte del curso virtual Introducción al lenguaje de programación Python que se iniciará el próximo 24 de octubre. ¡Aún quedan plazas libres!

Como deberéis saber ya, una de nuestras principales ocupaciones en la OSL es dar soporte sobre software libre a toda la comunidad universitaria de la Universidad de Granada, y más concretamente, una de nuestras acciones más populares es la de realizar instalaciones de distribuciones GNU/Linux en los portátiles de los estudiantes que ya sea porque son recién llegados o porque por fin se han decidido a dar el “salto”, necesitan ayuda para tener un sistema operativo libre en su equipo de trabajo.

distros_de_linux_zpsa31e27f0-1

Gracias a la gran evolución de estos sistemas operativos (entre los que por ejemplo podríamos destacar Ubuntu), hasta hace unos años realizar este tipo de instalaciones era un proceso trivial: el ordenador arrancaba sin problemas el instalador del sistema operativo, seleccionábamos las opciones de idioma y teclado, se realizaba el particionamiento del disco duro y después de introducir los datos personas y de contraseña ya lo único que quedaba era esperar a que la instalación se completase. Una vez terminado este proceso semiautomático, salvo incidencias puntuales con drivers de tarjetas de red inalámbricas o tarjetas gráficas dedicadas ya teníamos el sistema en perfecto estado para comenzar a funcionar.

El problema está en cuanto todo esto dejó de ser así de fácil, cuando alguien decidió que tener la libertad de instalarse cualquier sistema en un ordenador era algo tremendamente peligroso para el propio usuario de a pie. Para ello, y aprovechando que se estaba ultimando el nuevo sistema UEFI (que vendría a sustituir a la tradicional BIOS) se introdujo un sistema que precisamente controlara esto: todo sistema operativo que se fuera a instalar en un equipo debería estar firmado como seguro por los promotores del proyecto para que este nuevo sistema permitiese la instalación en el equipo. Estos promotores eran gran número de compañías tecnológicas entre los que podemos destacar HP, Dell, Intel, IBM o, casualmente, Microsoft.

lenovo-idepad-u450p-notebook-review

El sistema UEFI en sí mismo es la evolución lógica de la clásica BIOS, el sistema imprescindible para que nuestros ordenadores sepan cómo arrancar, pero que con décadas de antigüedad necesitaba una actualización debido a los grandes avances tecnológicos actuales. Este sistema UEFI presenta por un lado aspectos superficiales como interfaces más vistosas o permitir el uso del ratón, pero principalmente añade compatibilidad con discos duros de más de 2 TB y controladores de dispositivos de firmware de 64 bits a los que este mismo sistema puede controlar directamente, pero además también añade el “Secure Boot”; un modo de “arranque seguro” según lo establecido por las directivas de estas compañías, en las que el usuario de a pie no tiene opinión, lo que viendo en qué terminará desencadenando puede parecer que se buscase más bien un beneficio propio, que una posición neutral que se debería esperar de un órgano intermediario y que desde luego no va en consonancia con la libertad tecnológica que nos gustaría tener; aquí empiezan los problemas.

Empezamos a encontrarnos con situaciones en las que para realizar una simple instalación era necesario realizar un gran número de comprobaciones y pasos previos antes de empezar para asegurarnos de que siquiera podríamos iniciar el proceso de instalación, o en el caso de optar por la comodidad de realizar una instalación desde un pendrive, asegurarnos además de que ese pendrive ha sido “booteablilizado” de forma que sea compatible con UEFI para que nos permita realizar una instalación en dicho modo; pero tanto en uno como en otro caso, nada de esto nos aseguraba que la instalación se pudiera hacer correctamente. Todo esto derivó en que ante todos los problemas ocasionados, por un lado muchas personas empezaran a buscar equipos que no tuvieran que usar el modo “Secure Boot” de forma obligatoria y pudieran funcionar en “Legacy mode”, y por otro lado, algunas compañías como Red Hat optaran por pagar para que su sistema pudiera ser instalado sin problemas (ante un previsible miedo de que esto afectara a sus posición en el mercado del sector empresarial, su principal actividad económica).

f7574_uefi (1)

Aunque poco a poco se consiguieron saltar los problemas para instalar nuestros sistemas operativos en los ordenadores, de pronto apareció un nuevo problema: Windows 8 empezó a venir preinstalado en muchos ordenadores. El problema que nos encontramos es que estos sistemas vienen en discos duros cuyas tablas de particiones dejan de ser las clásicas MBR para ser la nueva GPT, lo que en un principio es ventajoso ya que entre sus características permite usar discos duros de más de 2 TB y nos libra de la limitación de cuatro particiones primarios en un mismo disco duro (podemos tener hasta 128), pero además viene con otra particularidad: esta tabla de particiones obliga a tener una partición “boot”.

¿Por qué es necesario una partición “boot”? ¿Está relacionado con las particiones “boot” de las distribuciones GNU/Linux? Sí, pero con una gran diferencia. Hasta ahora, cuando instalábamos un sistema operativo este a sus vez instalaba un gestor de arranque al principio del disco duro para que cuando la BIOS arrancase el dispositivo, un pequeño programa supiera cómo arrancar el sistema operativo pertinente; como UEFI provee de una interfaz que puede controlar los dispositivos, ya no se encarga simplemente de realizar verificaciones para después transferir el control al gestor de arranque en el disco duro, ahora también es el propio sistema el que se encarga de realizar también el arranque del sistema para “garantizar la seguridad” del sistema.

Hasta aquí todo bien, pero… ¿y si el sistema que se instala en la partición “boot” no reconoce otro tipo de sistemas que no sea el suyo? Pues con las políticas monopolísticas hemos topado. Esto no es nada nuevo, siempre han existido problemas para que sistemas Microsoft y cualquier otra “cosa” convivieran en un mismo ordenador, sin embargo, si tenías la opción de realizar una instalación limpia y la necesidad de tener un dual boot, ya sabías que tenías que instalar primero el sistema Windows de turno, dejarlo que se acomodase en tu máquina y después instalar cualquier otro sistema, ya que seguramente este último no tendría ningún problema en compartir máquina con él, instalándose en el sector de arranque de tu disco duro sin hacer mucho ruido y sin ningún problema permitirte arrancar el sistemas que necesites en cada ocasión.

Ahora la cosa cambia, porque Windows se adueña de la partición “boot” y en muchas ocasiones no puedes hacer una instalación limpia ya que en el caso de eliminar la partición de recuperación te arriesgas a perder la garantía del ordenador; pues en estos casos, en ocasiones concretas simplemente no vas a poder instalar otro sistema que no sea el que viene de fábrica. ¿Para qué queremos tener un sistema de particionado que nos permite tener 128 particiones primarias si solo vamos a poder instalarle un único sistema operativo de Microsoft? Además, en otros sistemas si hay una mayor configuración de particionamiento disponible y típica en función de las preferencias del usuario: “root”, “home”, “var”, “tmp”…, que además en el caso de tener varias distribuciones distintas nos puede dar un gran juego; aunque en el caso de Windows no encontramos esta capacidad de personalización, por lo cual, sigue pareciendo innecesario un número tan alto de particiones, por lo cual, este tipo de bloqueo solo puede responder a argumentos más bien de un propio interés comercial que a argumentos de seguridad para el usuario, usuario que al final y al cabo es el dueño del equipo y que por lo cual debería tener el derecho de poder hacer con él lo que desee y crea conveniente.

Sc0EH

Es cierto que también Microsoft cada vez parece que está cambiando su enfoque en muchos aspectos a su clásica filosofía, en la que buscaba tener sobretodo una posición dominante que no tuviera por qué ir vinculada a tener una posición igualmente innovadora; ya sea este cambio ideológico por decisión propia o por necesidad, iniciativas como Microsoft Openness, que su plataforma en la nube Azure sea una plataforma de código abierto o que cada vez patrocinen y organicen más eventos e iniciativas relacionadas con el software libre es algo que todos aplaudimos y celebramos, pero precisamente por eso, porque es un buen camino el que parece que están tomando, deberían aplicar ese tipo de políticas a niveles más globales para no encontrar tantas incoherencias en una misma compañía, ya que si no, en lo que a nosotros nos compete, cuando un alumno viene a que le ayudemos a instalar Ubuntu en su ordenador no queremos tener que decirle que no es posible porque Microsoft no lo permite.

El pasado miércoles 05 de Octubre tuvo lugar la la charla “El Zen de Git (introducción a git para los que no saben git)”, impartida de manera magistral por Pablo Hinojosa.

En un principio, estaba prevista en el Salón de Grados de la ETSIIT, aunque finalmente se traslado al aula 1.7 debido a la gran demanda de plazas.  El aforo supero las 80 personas, las cuáles asistieron a un magnífico taller de introducción a git, en el que se explicaron desde los aspectos básicos para el uso de git hasta algunos mas complejos. Angel Pablo destaco la importancia del uso de git tanto en el ámbito personal como de trabajo y resolvió las dudas de los asistentes.

Además, se regalaron pegatinas e información sobre cursos y actividades de la Oficina de Software Libre.

Tanto para aquellos pudieron disfrutar de la charla como para los que no pudieron, está disponible en el siguiente enlace el video de la charla.

La presentación de la charla se puede descargar aquí.

También tenemos algunas fotos del evento.

photo51504960507062731 photo51504960507062732 photo51504960507062733 photo51504960507062734photo51504960507062730

git_Pablo

Ya está abierta la decimoctava campaña de donación de material informático,  tras las campañas I, II, III, IV, V, VI ,VII, VIII, IX, X,  XI , XII , XIII , XIV , XV , XVI, XVII y XVIII en las que se han donado más de 470 equipos informáticos completos. En esta campaña, cuyas bases podéis consultar en la web, en esta Campaña contamos con  ordenadores de sobremesa (Intel Celeron con 512 MB y Pentium IV con 1024 MB)  e impresoras, que se pueden solicitar en el formulario .

DSC_0246

Como en la anterior campaña, se cuenta con el apoyo del resto de la Delegación de la Rectora para la Universidad Digital (DRUD), especialmente el CSIRC, Gerencia y la Unidad de Calidad Ambiental de la UGR. Los únicos requisitos para recibir la donación, aparte de lo indicado en las bases, es asistir al taller de formación sobre el uso de los equipos y comprometerse a retirar personalmente los equipos, a parte de documentar la instalación en la sede de la entidad receptora, mediante la publicación de una noticia de los equipos entregados y publicarlo en la web o los medios sociales de los que la entidad disponga. Siendo también necesario publicar la asignación de material antes del taller. La campaña termina el día 26 de octubre de 2016, en los días siguientes a esa fecha de cierre de la campaña se les comunicará a las asociaciones solicitantes, mediante correo electrónico, los equipos que les han sido concedidos, y en los días sucesivos, según se confirmen o no las aceptaciones de las donaciones, al resto. El taller de introducción a Ubuntu 14.04 tendrá lugar en la Oficina de Software Libre el  7 de noviembre de 2016. Aún así se comunicará el día mediante correo electrónico a las asociaciones beneficiadas, por si hubiese cambios de última hora. La asistencia al mismo es obligatoria y la publicación previa de la asignación en la web (como viene reflejado en las bases). Resumiendo:

Otro año más, la Oficina de Software Libre de la Universidad de Granada organiza actividades para celebrar la semana del código. El objetivo es acercar a las familias a la programación desde el punto de vista más lúdico.

A partir del día 10 (lunes que viene) y en dos grupos, uno para familias y otro para niñas y niños de 9 a 13 años, se enseñará a programar juegos en el ordenador y en el móvil, usando las aplicaciones Scratch y AppInventor.

Los ordenadores que usaremos son los que están disponibles en los laboratorios de la ETSIIT, aunque os podéis llevar tablets o móvil (el segundo día) para ver en ellos los resultados del programa.
La actividad es gratuita, pero hay que inscribirse por el aforo limitado.

Familias

El evento para familias con niñas y niños desde 7 hasta 11 años será los días 10 y 11 de octubre, de 18:30 a 20:30

El taller tendrá lugar a lo largo de los dos días.

Inscripciones en este formulario.

Niñas y niños

Para niñas y niños con edades entre 9 y 13 años, podrán venir solos a los talleres del 13 y e 14 de octubre. Serán 4 horas a lo largo de los dos días con Scratch (programación lúdica) y AppInventor (programación fácil en el móvil).

Rellenad este formulario si vais a asistir.

http://events.codeweek.eu/view/14796/semana-del-codigo-2016/

El Zen de git

El Zen de git

Ante la gran demanda de plazas, la charla “El Zen de Git (introducción a git para los que no saben git)” se ha cambiado del aula -1.2 donde estaba prevista al Salón de Grados de la ETSIIT, que dispone de más espacio.

De modo que, al final, la charla será mañana, miércoles 5 de octubre, a las 12:30 en el Salón de Grados de la ETSIIT de la Universidad de Granada.

La entrada es libre mientras haya plazas disponibles (y ya no quedan muchas), y puedes inscribirte y ver más detalles en el evento en Meetup.

Web Jornadas de Software Libre
Logo y enlace Web Jornadas de Software Libre 2018
Web SereIngeniera
Logo y enlace Web SereIngeniera 2018
Web Campus Infantil 2018
Logo y enlace Web Campus Infantil 2018
Calendario
agosto 2018
lunes martes miércoles jueves viernes sábado domingo
30 julio, 2018 31 julio, 2018 1 agosto, 2018 2 agosto, 2018 3 agosto, 2018 4 agosto, 2018 5 agosto, 2018
6 agosto, 2018 7 agosto, 2018 8 agosto, 2018 9 agosto, 2018 10 agosto, 2018 11 agosto, 2018 12 agosto, 2018
13 agosto, 2018 14 agosto, 2018 15 agosto, 2018 16 agosto, 2018 17 agosto, 2018 18 agosto, 2018 19 agosto, 2018
20 agosto, 2018 21 agosto, 2018 22 agosto, 2018 23 agosto, 2018 24 agosto, 2018 25 agosto, 2018 26 agosto, 2018
27 agosto, 2018 28 agosto, 2018 29 agosto, 2018 30 agosto, 2018 31 agosto, 2018 1 septiembre, 2018

Categoría: General10:00 pm: Inscripción JSLUGR

10:00 pm: Inscripción JSLUGR
2 septiembre, 2018
Archivos
Categorías