Una de las últimas versiones de Kopete, el cliente de mensajería instantánea que KDE trae por defecto, añade una pequeña sorpresa que se me ha pasado totalmente desapercibida hasta ahora: su integración con Skype. Kopete no usa directamente el protocolo de Skype ni permite el alta de cuentas de este sistema de forma directa, sino que integra la información de una cuenta de Skype abierta y autenticada mediante su propio cliente nativo y sirve como intermediario entre nosotros y dicho cliente, creándonos la ilusión de tener un único programa de mensajería. Más aún si, además de realizar esta integración, “escondemos” el icono de Skype de forma que no aparezca en nuestra bandeja del sistema.

Kopete nos permitirá, a partir de ahora, la clasificación de los contactos de Skype en grupos (cosa que, inexplicablemente, no ha permitido nunca el cliente original), la inclusión de dichos contactos en meta-contactos (que engloban en una sola las cuentas de diferentes sistemas de mensajería de la misma persona) y derivará todos los eventos generados por Skype al nuevo centralizador de notificaciones incorporado en KDE4.

La verdad es que las últimas versiones de Skype para Linux han dejado mucho que desear y presentan frecuentes problemas con el audio y el video. La reciente versión 2.1, aunque mejor integrada, sigue sin solventar del todo estos problemas. Pero, por desgracia, se trata del cliente VoIP más extendido y por el momento no hay más remedio que “pasar por el aro”, así que esperemos que, aparte de mejoras externas como esta, el señor Andreessen (desde hace sólo unos días su nuevo accionista mayoritario) tenga la intención de cambiar el enfoque y nos permita disfrutar un poco mejor de esta popular herramienta.

Llevo ya unos días probando Ubuntu One, el servicio propietario a través del cual Canonical pretende introducirse en esto del Cloud Computing al tiempo que le da un valor añadido a su distribución de Linux e incluso, si tiene la suficiente aceptación, le proporcionará una fuente de ingresos.

Ubuntu One se presenta como un servicio de almacenamiento remoto, sincronización y compartición de archivos con dos modalidades: una gratuita que ofrece hasta 2 GBytes de espacio y otra de pago que, por 10$ al mes, amplía esta cuota hasta 10 Gbytes. El servicio está disponible, por el momento, sólo mediante beta cerrada a través de invitaciones, tiene aún algunos bugs importantes y ha despertado críticas en muchos sectores ya que, mientras que el cliente de escritorio está escrito en python y su código si es libre, la parte que corre en servidor (en los servidores EC2 de Amazon, concretamente) es propietaria.

Una vez que disponemos de una cuenta, el acceso al servicio de Ubuntu One se puede hacer de dos formas: mediante una aplicación web o mediante un cliente de escritorio. Este último, que es quién realmente le proporciona un carácter difererenciador al servicio, sólo puede utilizarse por el momento desde la versión 9.04 de Ubuntu.

El cliente web no tiene nada de especial y se parece mucho a cualquier otro interfaz FTP vía web. El acceso se hace siempre vía https y la autenticación mediante una cuenta de launchpad. Podeis ver un pantallazo aquí abajo:

Tal vez lo único a destacar de este cliente es que tenemos una opción disponible en el panel derecho a través del cual podemos compartir cualquier directorio tanto en modo de sólo lectura como de lectura y escritura. Cuando invitamos a alguien basta con escribir su dirección de email y el destinatario recibirá en su buzón de correo una invitación con todas las instrucciones necesarias. El enlace recibido por correo nos llevará a un formulario de aceptación y el invitado deberá de disponer de su propia cuenta de Launchpad o, en su defecto, se le invitará a crear una nueva.

Pero, como decíamos antes, la verdadera gracia del servicio está en el cliente de escritorio. Las instrucciones para su instalación están aquí y son bien sencillas. La primera vez que ejecutemos el cliente en nuestra máquina asociará esta a nuestra cuenta de Ubuntu One. Podemos tener tantas máquinas asociadas a una cuenta como queramos (y los archivos compartidos se sincronizaran en todas ellas) pero, por lógica, cada cuenta de usuario en una misma máquina sólo podrá estar asociada a una cuenta de Ubuntu One. Esto es debido a que el servicio lo que hace es crear físicamente un directorio en nuestro home que es sobre el que se realizará la sincronización:

El cliente coloca un icono en la bandeja del sistema desde el que podemos activar o desactivar la sincronización de archivos, abrir los directorios sincronizados, lanzar el cliente web, etc. No lo he probado en KDE así que no se que tal se integra por allí. En Gnome la integración es total. Aparte del icono y del botón de conexión y desconexión que, como veis en el pantallazo de aquí arriba, nos aparece en Nautilus, en el menú contextual también se incluye una nueva opción etiquetada como “Share on Ubuntu One” que nos permite compartir las carpertas con quien queramos simplemente introduciendo su dirección de correo electrónico al igual que hacíamos con el cliente web.

Si alguien tiene curiosidad por comenzar a probarlo por si mismo y no quiere esperar la invitación de Canonical que me deje un comentario con la dirección de correo electrónico donde quiere recibir la invitación: si os invito a compartir uno de mis directorios os dejará, además, crear vuestra propia cuenta. Pero recordad que el cliente de escritorio sólo funciona con Ubuntu 9.04 y que no se, siquiera, si funcionaría con Kubuntu 9.04 o Xubuntu 9.04. Si lo probáis en alguno de estos sistemas decídmelo y así salgo de dudas.

El servicio que presta Ubuntu One no es nuevo. dropbox, box.net, wuala, humyo o mozy, por decir algunos, ofrecen una funcionalidad similar desde hace tiempo. Algunos de ellos incluso con clientes específicos para GNU/Linux. La baza de Canonical, imagino, será presentarlo ya instalado y disponible para su uso como una característica de base en futuras versiones de sus plataformas proporcionandolo como un valor añadido. Veremos.

Configurar las máquinas virtuales de VirtualBox en modo bridge para que sean accesibles cómodamente entre si o con las máquinas “reales” de nuestra red local es ahora un poco más fácil (desde la versión 2.2.2) de lo que contábamos aquí puesto que ahora aparece un casillero específico para esta opción en la configuración de red de la máquina virtual:

Pero, ya puestos vamos a darle un repaso y así vemos como se hace en Fedora 11.

Antes de nada debemos de instalar el paquete bridge-utils (yum install bridge-utils).

Luego editamos el fichero de configuración del interfaz de red de la máquina anfitriona (en mi caso /etc/sysconfig/network-scripts/ifcfg-eth0) y añadimos, al final, la siguiente línea:

BRIDGE=br0

A continuación creamos un nuevo fichero de configuración (/etc/sysconfig/network-scripts/ifcfg-br0) para el bridge:

DEVICE=br0
TYPE=Bridge
BOOTPROTO=dhcp
ONBOOT=yes
DELAY=0
STP=off

Por último reiniciamos los servicios de red (service network restart) y ya sólo nos queda configurar la red de la máquina virtual como se muestra en la imagen de aquí arriba. Con esto la máquina virtual tomará una dirección de forma dinámica del servidor DHCP disponible en la red de la máquina anfitriona y será perfectamente visible tanto por cualquier otra máquina conectada a dicha red como por otras máquinas virtuales configuradas de igual forma en el mismo anfitrión.

Hace ya más de un mes que me dieron una cuenta para probar la versión Alpha del Suse Studio y, a pesar de que he estado jugando bastante con el, ni siquiera he escrito unas líneas para contaros como funciona. Aquí van.

Suse Studio es una herramienta web para crear fácilmente y a golpe de ratón tus propias distribuciones personalizadas basadas en Open Suse o en Suse Linux Enterprise. Admite, como veremos en unos instantes, una gran variedad de plantillas base de partida, permite una personalización del resultado extremadamente fina y como salida podemos obtener desde Live’s CD o USB instalables, hasta imágenes de disco duro para cargar directamente en equipos OEM o máquinas virtuales en formato Xen o VMware (y, a partir de estas, de VirtualBox).

El procedimiento es tan sencillo de seguir que podría entenderse perfectamente con tan sólo dejar unos pantallazos, así que no voy a aburriros mucho. El primer paso para crear tu distribución personalizada es elegir la plantilla de partida de entre las opciones que se nos ofrecen:

La personalización, ahora, se realiza en base a tres grandes bloques: elegir el software que queremos añadir a nuestra plantilla, configurar el aspecto y algunas características del resultado y, finalmente y si así lo deseamos, añadir los archivos o programas que queramos realizados por nosotros mismos. La selección del software adicional se hace en base a bloques temáticos o con la ayuda de un buscador:

La configuración se realiza en base a siete grandes bloques gracias a los cuales podemos configurar desde los elementos más básicos (el idioma del teclado, las cuentas de usuario iniciales, la configuración de red, la activación del cortafuegos, la inclusión, si lo deseamos, de una licencia EULA que el usuario deberá de aceptar tras la instalación) hasta la carga de una base de datos mysql, la ejecución de scripts personalizados tras la instalación o la memoria y tamaño de disco que ocuparemos caso de desear una máquina virtual o una imagen de disco como resultado.

Sin olvidar, claro, el apartado en el que podemos personalizar el aspecto mediante un logo y un fondo de escritorio a nuestro antojo:

Una vez hecha la personalización de la máquina pasamos a la construcción del resultado. Elegimos el soporte final que necesitamos, pulsamos el botón de Build, esperamos unos minutos y listo:

Podemos almacenar diferentes soportes finales (imágenes ISO, máquinas virtuales, etc.) de una misma creación y todas las creaciones que queramos para futuros usos o incluso para que nos sirvan como plantillas iniciales mediante el botón de clone:

Podemos, incluso, probar el resultado de cualquiera de ellas directamente desde la web y antes de descargarla a nuestro PC sin más requisitos que tener instalado un plugin de flash en nuestro navegador mediante el enlace etiquetado como Testdrive:

Y una última nota. Aunque no soporta la creación de imágenes para VirtualBox, puesto que esta lee perfectamente los discos en formato vmdx de Vmware, la traslación a este sistema es un juego de niños:

A mi como herramienta me gusta bastante y, aunque aún tiene algunos defectos y carencias (¡no olvidemos que es una versión Alpha!), creo que tiene muchas posibilidades tanto para uso personal de quien, por ejemplo, quiera crear su propia distribución totalmente a medida, como para la preparación de entornos corporativos, creación de imágenes OEM, distribución de LiveCD’s con aplicaciones personalizadas, etc.

Para quien necesite más información, existe un “screencast” introductorio (en inglés), un foro asociado al proyecto y una wiki que contiene numerosos “howtos” con todas las posibilidades de la herramienta.

Contar de nuevo con VirtualBox ha sido más fácil de lo que pensaba, pero como existe algún detallito fuera de lo habitual lo dejo aquí por escrito y a ver si así le ahorro un par de horas de sufrimientos a algún otro early-adopter como yo. Pues vamos allá.

Lo primero es lo primero: descargar la versión adecuada de virtualbox. Yo me he bajado la genérica para cualquier distribución y arquitectura i386. La última versión, en el momento actual, es la 2.14.

Lo segundo: preparar el entorno adecuado para compilar los módulos necesarios. El equivalente a nuestro hasta ahora habitual apt-get build-essentials kernel-headers se vería así de feo en Fedora:

[root@localhost downloads]# yum install make automake autoconf gcc kernel-devel dkms

Tres: aplicamos permisos de ejecución al .run que nos hemos bajado (chmod +x VirtualBox-2.1.4-43001-Linux_x86.run), y lo ejecutamos con privilegios de root.

Cuatro: necesitamos meter nuestro usuario dentro del grupo habilitado para conceder permisos de ejecución de maquinas virtuales:

[root@localhost downloads]# usermod -a -G vboxusers josemaria

El quinto paso, y el único arcano dentro de todo el proceso, es que para que funcione de forma adecuada a partir de la versión 2.6.29-rc5 del kernel hay que editar el fichero /usr/src/vboxdrv-2.1.4/Makefile y descomentar la siguiente línea:

# VBOX_USE_INSERT_PAGE = 1

Imagino que en las próximas versiones se solventará con un ifdef, pero de momento hay que hacerlo así. Es lo que tiene esto de querer probar las cosas antes que nadie Ah, y no, no soy un gurú del kernel ni nada parecido. Sólo se donde buscar.

Y ya casi estamos. El sexto y último paso es ejecutar, también como root, el proceso que construirá los módulos adecuados para nuestro kernel:

[root@localhost downloads]# /etc/init.d/vboxdrv setup.

Ala, a seguir trabajando.

ACTUALIZACIÓN: Al cambiar a la beta de Fedora 12 me he dado cuenta de que ya no es necesario siquiera esto. La gente de VirtualBox mantiene ahora un completo directorio con paquetes para, incluso las versiones beta más populares. En estos momentos la última versión de Virtualbox es la 3.08 y mirad que muestrario.

hmailServer es un servidor de correo gratuito para windows. Hasta su versión 4 era, además, un proyecto de software libre. La versión 5 es de código propietario aunque sigue siendo gratuita. Nosotros veremos aquí el procedimiento e instalación de la versión 4.4.3 Build 285, la última estable y que mantenía aún la licencia GPL, pero puede aplicarse perfectamente para la instalación de la versión 5.

Como paso previo a la instalación, no debemos de olvidar que para que un servidor de correo funcione necesitamos un dominio. En nuestro ejemplo será moratalaz.es. En segundo lugar necesitamos que el servidor DNS desde el que se vaya a gestionar dicho dominio tenga un registro MX que apunte al servidor que gestionará nuestro correo. Si también estamos obligados a usar un servidor windows para esta función debería de quedar algo así:

Bien. Una vez hecho esto descargamos el ejecutable de la versión 4.4.3 y la instalamos con todas las opciones por defecto. En un momento del proceso se nos pedirá una contraseña que usaremos posteriormente para entrar en el panel de administración del servidor. Al concluir, tendremos un servicio llamado hmailserver (configurado para arrancar automáticamente al iniciar el sistema) y un nuevo grupo de programas en el menú de Inicio de nuestro windows con el mismo nombre. Si entramos ahora en el hmailserver Administrator (para ello se nos pedirá la contraseña que hemos introducido durante la instalación) nos podemos ir haciendo una idea de la multitud de opciones que tenemos disponibles en este servicio:

Luego debemos de añadir el dominio cuyo correo queremos gestionar desde este programa y que, como vemos en el pantallazo anterior, es lo primero que se nos solicita. Pulsamos el botón y lo introducimos en la ficha que se nos abre:

El siguiente paso no es imprescindible para que nuestro servidor funcione, pero si muy recomendable para no tener problemas. En el apartado de protocolos y dentro de la ficha destinada a SMTP deberíamos de especificar el nombre público con el que nuestro servidor se verá en Internet y que, en una instalación sencilla como la que estamos haciendo, posiblemente será el mismo que hemos puesto en el registro MX de nuestro DNS:

Pues ya hemos acabado. Si configuramos ahora nuestro primer buzón de correo y un cliente para que lo use podremos comprobar que funciona correctamente.

Esto en cuanto a la configuración inicial que es hasta donde vamos a llegar aquí. Para explotar el resto de posibilidades que nos ofrece el programa (integración con antivirus, antispam, backups, límites, etc.) podeis echarle un vistazo a la excelente documentación disponible en el propio sitio web del producto.

Google responde a las críticas sobre la falta de información durante la caída, de cerca de 4 horas de duración, de Gmail del pasado martes con Google Apps Status Dashboard, un panel informativo del estado de sus servicios y de las incidencias que afectan a los mismos. Se les pueden criticar muchas cosas a estos chicos (yo ya sabeis que lo hago a menudo), pero lo que es justo es justo y cintura no les falta.

¿Cuánto tiempo hace que no te tropiezas con un servidor con NFS? Si se tratase de un animal seguro que casi podríamos decir que está en peligro de extinción. El caso es que, en ambientes mixtos Windows/*nix con un Directorio Activo (que es el entorno más habitual al que nos enfrentamos) es mucho más práctico y menos problemático montar un servidor con Samba. Pero si en nuestro entorno no existen máquinas con windows o estas son minoritarias, aún podemos montar nuestros servidores de archivos con NFS y usar Windows Services for Unix para dar soporte a este protocolo desde las máquinas con windows (aquí tenéis un tutorial de instalación en castellano).

Para preparar la máquina que ofrecerá los servicios de NFS (y partiendo, como siempre, de una Debian o derivada), sólo tenemos que instalar el paquete nfs-kernel-server (sudo apt-get install nfs-kernel-server) y sus dependencias. Una vez hecho esto podemos ver en el archivo /proc/filesystems que nuestro sistema ya debería de soportar nfs.

Los directorios que queremos compartir se configuran de forma sencilla en el fichero /etc/exports. Allí, y en función de nuestras necesidades, podríamos tener algo como esto:

/mnt/Sistemas 192.168.1.0/25(rw,sync,subtree_check)
/mnt/Desarrollo 192.168.1.0/25(rw,sync,subtree_check)
/mnt/Gestión 192.168.1.0/25(rw,sync,subtree_check)
/mnt/Público (rw,sync,subtree_check)

La sintaxis es bien sencilla. En cada línea pondremos en primer lugar el recurso compartido, en segundo la dirección o direcciones de las máquinas que tendrán acceso a él y, por último y entre paréntesis y sin ningún espacio de separación, los atributos que aplicaremos al recurso compartido.

La forma de expresar las máquinas que tienen acceso al recurso es bien versatil. Podemos poner una única dirección IP (192.168.1.5), una subred completa (192.168.1.0/25 ó 192.168.1.0/255.255.255.128), un nombre de máquina (estacion1.midominio.net), o usar comodines * y ? (estacion*). Si no ponemos nada quiere decir que no habrá restricciones en cuanto al origen de la conexión (como en el caso del recurso /mnt/Público del ejemplo anterior). Si quisiéramos aplicar opciones diferentes según el origen de la conexión lo hacemos de forma consecutiva en la misma línea del fichero exports. De esta forma:

/mnt/Gestión 192.168.1.10(rw) 192.168.1.11(rw) 192.168.1.0/25(ro)

Las diferentes opciones de montaje pueden consultarse con man exports. Algunas de las más comunes son ro (sólo lectura), rw (lectura y escritura), async o sync (según si queremos que replique las modificaciones antes de hacer un commit de estas o no), etc. Despues de cada cambio en el fichero de unidades compartidas debemos de ejecutar la orden exportfs -a para que estos tengan efecto. Ah, y no olvidemos que los permisos aplicados sobre ficheros y directorios de las unidades compartidas ha de ser coherente con los que apliquemos al publicar las mismas.

Y ahora nos vamos con los clientes. En ellos lo único que tenemos que instalar es el paquete nfs-common y sus dependencias. Y listo. Ahora podemos montar las unidades de nuestro servidor remoto de forma manual o, si queremos hacerlo de forma permanente, añadiendo una línea en nuestro fichero fstab. La forma manual sería algo así:

mount -t nfs servidornfs:/mnt/datos /home/josemaria/datos

Si queremos hacerlo desde el fichero fstab, la línea a añadir para el mismo ejemplo anterior sería esta:

servidordns:/mnt/datos /home/josemaria/datos nfs auto,user,noexec,rw

Un par de notas finales. NFS siempre ha recibido muchas críticas por su seguridad hasta la versión 3. La versión 4, que es la que implementan ya los kernels modernos de Debian y sus derivados (Ubuntu, etc.), puede usar Kerberos para proporcionar seguridad en los accesos si así lo requerimos. Por último, aquí tenéis una buena comparativa que señala las debilidades y fortalezas de los sistemas de compartición de archivos más comunes (CIFS es la versión de SMB implementada por los sistemas de Microsoft).

Cuando creas una máquina virtual con VirtualBox, con las opciones de red por defecto, esta cuenta con conexión a cualquier recurso en la red al que tenga acceso la máquina anfitriona (conexión a Internet incluida) y puede compartir archivos con ella si configuramos la opción de “Directorios Compartidos”, pero entre máquina anfitriona y máquina virtual no existe ninguna otra posible conexión. La máquina virtual tampoco es accesible de ninguna forma desde otra máquina de nuestra red local y si abrimos dos máquinas virtuales en la misma máquina anfitriona tampoco pueden verse entre si. Esto puede cambiarse fácilmente para que cualquier máquina virtual que creemos sea totalmente visible, tanto por la máquina anfitriona, como por cualquier otra máquina física (o virtual, en esta u otra máquina anfitriona configurada por este mismo método) como si se tratase verdaderamente de una máquina real conectada de forma independiente a nuestra red. Nos ponemos a ello.

Partimos de una máquina anfitriona con Debian o una distribución derivada (Ubuntu, Kubuntu, etc.), que ya tiene Virtualbox instalado y cuenta con una única interfaz de red (eth0). Lo primero que tenemos que hacer es instalar el paquete bridge-utils.

josemaria@valeria:~$ sudo apt-get install bridge-utils

Luego editamos la configuración de nuestro interface ethernet (/etc/network/interfaces) y lo dejamos de esta forma:

auto lo
iface lo inet loopback


auto eth0
iface eth0 inet dhcp

auto br0
iface br0 inet dhcp
bridge_ports eth0 vbox0 vbox1

Las líneas en negritas son las que hemos añadido. En ellas estamos definiendo dos interfaces virtuales (vbox0 y vbox1) que están ligados a nuestro interfaz físico real (eth0) y que tomaran una IP de forma dinámica a través de un servicio DHCP que debemos de tener disponible en nuestra red. Esto no quiere decir que no podamos ponerles direcciones fijas a nuestras máquinas virtuales: Estas tendrán disponible este servicio, si existe, desde su arranque pero luego nosotros podremos configurarlas perfectamente mediante IP’s estáticas sin ningún problema, ya dentro del sistema operativo que hayamos elegido para ellas. Por cierto: hemos creado dos interfaces por que es lo que necesitamos (yo, en concreto, quiero hacer prácticas para los chicos con un windows 2003 server y un windows xp que deben de verse para que el segundo se conecte al dominio definido por el primero) pero, lógicamente, podríamos definir una sóla. O diez .

Ahora editamos el archivo de configuración de interfaces de virtualbox (/etc/vbox/interfaces) y añadimos las siguientes líneas:

vbox0 josemaria br0
vbox1 josemaria br0

En ellas redefinimos los dos nuevos interfaces virtuales que hemos creado (vbox0 y vbox1) y declaramos el usuario de la máquina anfitriona que tiene permiso para usarlos.

Ya casi estamos. Ahora reiniciamos, por este orden, la interfaz de red física de nuesta máquina anfitriona y luego virtualbox:

josemaria@valeria:~$ sudo /etc/init.d/networking restart
* Reconfiguring network interfaces...
(...)
bound to 192.168.1.10 -- renewal in 39314 seconds.
[ OK ]
josemaria@valeria:~$ sudo /etc/init.d/virtualbox-ose restart
* Shutting down VirtualBox host networking
* done.
* Starting VirtualBox host networking
* done.

Luego iniciamos Virtualbox y configuramos la red de las máquinas que queremos hacer accesibles de esta forma:

Y con esto ya si que hemos acabado. En el siguiente pantallazo (ampliable si hacéis click en él) podéis ver como mis dos máquinas virtuales se ven perfectamente (la XP tomando su IP mediante DHCP, el 2003 server con IP estática configurada manualmente), la autenticación de dominio entre ellos se ha hecho perfectamente y ambas son visibles también desde la máquina anfitriona.

Antes de nada decir que, por supuesto, respeto a todo el que mañana quiera ejercer su derecho e ir a la huelga. Yo no lo haré y me gustaría dejar aquí mis motivos por si el lector ese que pasa de vez en cuando por aquí está aún indeciso y puedo ayudarle a tomar una decisión.

• No soy absolutamente nada corporativista: no me siento ligado a nadie sólo por el hecho de que tenga la misma titulación que yo. Me siento identificado con la gente que desempeña sus funciones con profesionalidad y dentro de este sector conozco a tantas personas sin titulación de informática que hacen su trabajo fabulosamente bien, como a ingenieros en informática que parece que han conseguido su título descargándoselo por el emule.
• Tampoco creo en la excesiva regulación de competencias profesionales. Creo en un modelo en el que un determinado trabajo pueda desempeñarlo quién esté capacitado para ello y una titulación (al igual que una certificación, algo que en esta profesión gusta demasiado) no garantiza absolutamente nada y mucho menos a medida que transcurren años desde que la obtuviste. Esto puede que no sea tan evidente para quién aún esté en la facultad o lleve poco tiempo “en la calle”, pero cualquiera que lleve más de 10 años en el mundo profesional puede dar fe de ello.
• No me siento para nada agraviado por el tratamiento que se le da a otras titulaciones. De hecho yo me matriculé en informática cuando era una Licenciatura, soy Licenciado en Informática y jamás opté a la convalidación de la titulación porque me siento más cercano en mis inquietudes y formación al pensamiento abstracto y científico que a la aplicación práctica de determinados conocimientos. No estoy en contra de las ingenierías, ojo, pero no fue lo que yo elegí estudiar y tampoco me hace gracia que, a veces, me traten como si fuese un ingeniero: ni lo soy ni he querido serlo nunca.
• Me desagradan profundamente los mensajes manipuladores que han lanzado los organizadores y promotores de la huelga: que la titulación de informática iba a desaparecer, que a quienes ya tuvieran el título o estuvieran en ello no les iba a servir para nada, que no podremos trabajar en Europa, la confusión que han tratado de crear mezclando atribuciones y competencias…
• No creo, en definitiva que la situación de los titulados en informática vaya a cambiar ni un ápice en el futuro tras el desarrollo de la nueva ley de universidades. Ni para bien, ni para mal.

Hay mucha gente por ahí que ha escrito sobre esto y en esta línea mucho mejor que yo. Os dejo aquí algunos enlaces para quién quiera leer algo más en este sentido:

• Bolonia y la Ingeniería informática: Preguntas y respuestas
• Yo no secundo la huelga
• ¿Qué pasa con la Ingeniería Informática?
• Ingeniería Informática, camino a la solución