Comandos útiles en Ubuntu

Hoy vamos a ver unos cuantos comandos bastante útiles para Ubuntu. No iremos sobre aquellos comandos básicos, sino algunos que puede que sean menos conocidos. Queremos especificar que son para Ubuntu ya que es posible que no funcionen en alguna otra distribución Linux, como por ejemplos los relacionados con repositorios:

tail -F <Nombre de archivo>

Este comando puede ser muy útil para leer logs. Imprime por pantalla en tiempo real el fichero que pasemos como entrada. Si utilizamos grep de la siguiente forma:

tail -F <Nombre de archivo> | grep "<frase a buscar>"

sólo se imprime la frase que coincida con la cadena en el archivo.

sudo apt-get install <nombre del programa>

Apt-get es el famoso programa para instalar otros programas que se encuentren en los repositorios. Recuerda que para usarlo debe ser root (sudo). Para encontrar el nombre a introducir, nos basta con una rápida búsqueda en internet poniendo el comando y el nombre del programa después.

gnome-open <nombre del archivo>
[/code]
Cuando queremos abrir directamente un archivo desde la máquina de comandos y no sabemos que programa puede abrirlo, podemos usar este comando, que abre el archivo con el programa por defecto


find . -name "*" -exec <comando> <parámetros> {} \;

Con este otro comando podemos hacer una búsqueda recursiva y aplicar otro comando sobre todos los archivos que haya en la carpeta que nos encontremos y en sus subcarpetas. Por ejemplo, podríamos buscar todas las apariciones de la palabra "include" en todos las librerías de uno de nuestros programas de la siguiente forma:

find . -name "*.h" -exec grep -H -i "include" {} \;

Con el flag -H imprimimos el nombre del archivo antes de cada ocurrencia, y con -i nos evitamos la distinción entre mayúsculas y minúsculas.

history | grep <comando a buscar>

Cuando no recordamos el uso de un comando que hemos usado recientemente, podemos usar este truco para ver como fue usado por última vez, si es que aún se encuentra dentro de nuestro historial. Por ejemplo, si no recordamos el nombre de un servidor al que nos conectamos hace poco por ssh, podemos probar algo como esto:

history | grep ssh

Y obtenemos todas las últimas conexiones ssh que hemos realizado.

cat <nombre archivo> | more

Cuando intentamos imprimir en pantalla archivos demasiado grandes, podemos usar el comando more, el cual nos permite ver el archivo desde el principio e ir bajando línea a línea pulsando Enter.

Si sabes algún comando que no sea tan conocido pero aún así bastante útil, no dudes en colaborar en los comentarios!

Un saludo!

IDE libres

Muchos de los entornos de desarrollo para programadores son Software Libre. Esto facilita a cualquier persona el aprendizaje de lenguajes de programación y, además, la posibilidad de colaborar en proyectos de Software Libre. Y es que los IDEs más usados están liberados bajo licencias libres. Algunos ejemplos son los siguientes:

Eclipse: Uno de los IDEs más famosos, multiplataforma y con soporte para una gran variedad de lenguajes de programación, aún que está centrado principalmente en Java. Además tiene la posiblidad de incluir plug-ins para añadir funcionalidades, como incluir el sistema de control de versiones o facilitar la documentación de proyectos. Es dirigido por la Fundación Eclipse y se compone de una comunidad que lo mantiene en constante desarrollo. Actualmente se compone de más de 2 millones de líneas de código, la mayoría en Java, y el coste que se ha estimado que valdría crear un IDE como Eclipse es de más de 80 millones de dólares.

NetBeans: Compite en la lucha con Eclipse por ser el IDE más usado para el lenguaje Java, aún que también se puede programar en otros lenguajes como PHP o Python. Tiene un número de líneas de código muy parecido al de Eclipse, y también es desarrollado en su mayoría en Java, por lo que la estimación del coste es tal proyecto es muy similar.

Dev C++: Este IDE está centrado en programación en C y C++ y usa una versión del popular compilador GCC, el cual fue desarrollado por Richard Stallman. Está creado en Delphi.

Kdevelop: Diseñado para el sistema operativo GNU/Linux, en especial para el entorno gráfico KDE, aún que también funciona en Gnome. En realidad es un conjunto de herramientas que componen un IDE; por ejemplo, el compilador es GCC y el editor de texto Kate, también desarrollado para KDE. Se centra principalmente en C/C++.

MonoDevelop: Para el entorno .NET, este IDE, el cual es un fork de SharpDevelop, es ampliamente usado, a pesar de que hasta el momento el más usado para este lenguaje de programación es el creado por Windows.

BlueFish: Es un editor de HTML, enfocado a la edición de webs interactivas. La estimación del coste de tal proyecto es de 1.5 millones de Dólares.

Eso es todo, un saludo!

35% de código libre en aplicaciones europeas

Este mes el CENATIC (Centro Nacional de Referencia de Aplicaciones de las TIC basadas en fuentes abiertas) ha desvelado un estudio llamado «Impacto de la reutilización del software de fuentes abiertas en la economía» el cual concluye a través de encuentas que, en los proyectos de empresas europeas, el 35% del código utilizado viene de Software liberado con licencias libres.

Cenatic

Siempre ha sido un problema la cuantificación del impacto del Software Libre a la economía. A través de este estudio, se ha conocido que el ahorro que ha supuesto a la Unión Europea el Software Libre se eleva, como mínimo, a 114.000 millones de Euros. Este cálculo se ha hecho a través de un herramienta desarrollada por el mismo CENATIC que trata de medir el ahorro que supone el contacto con el Software Libre a las empresas, ya sea a través de utilización, migración, apoyo en la comunidad etc.

Además, hay otra diferencia destacable que refleja este estudio. La calidad del código reutilizado es sustancialmente mayor. Esto es debido a que es compartido, y por ello es más fácil encontrar error y corregirlos comparado con un código que no se comparte. Esto produce ahorros en mantenimiento. Además, reduce de manera significante la tasa de fracaso de proyectos.

El efecto que este ahorro produce es una reinversión en TI, ya que se verifica que no hay una disminución la inversión. Esto repercute tanto en la calidad del software desarrollado como en la productividad de la empresa, lo que lleva a aumentar la competitividad. Esta mejora de la productividad está estimada en 342.000 millones de Euros al año en términos de valor añadido económico.

Un saludo!

Fuentes:

El archivo .bashrc

Este archivo de configuración, para los que estamos acostumbrados a usar el entorno Shell, es de vital importancia y conocerlo nos simplificará mucho la vida a los que trabajamos bajo alguna distribución Linux. Suele encontrarse en nuestro $HOME, pero por si acaso podemos buscarlo con el siguiente comando:


find / -name .bashrc

Lo primero de todo es saber que, en cuanto abramos una Shell Linux, este archivo se ejecutará. Por lo tanto podemos configurar nuestra Shell con todo lo que se nos ocurra poner dentro.

Entre todas las opciones que podemos configurar en nuestro entorno Shell, una es la asignación de variables, por ejemplo de la siguiente forma:


export WORKDIR=$HOME/directoriotrabajo

De esta forma podemos hacer algo como:


cd $WORKDIR

para ir directamente a nuestro directorio de trabajo, que es allí donde tendremos nuestro entorno. También podemos asignar alias, lo cual es de tremenda utilidad; aquí van unos cuantos alias bastante útiles:


## Volver a directorio anterior
alias ..='cd ..'
## Volver dos directorios atrás
alias ...='cd ../..'
## Comando history sustituido por h
alias h='history'
## Ejecutar apt-get con permisos root
alias apt-get='sudo apt-get'
## salida de ls ordenada en tiempo de modificación
alias ls='ls -talr'
## Por si no equivocamos al escribir cd ..
alias cd..='cd ..'
## Borrar logs del directorio de trabajo
alias rmlogs='rm -rf $WORKDIR/logs'
## Ejecutar script que configura variables de entorno
alias setVar='$WORKDIR/scripts/setVar.sh'
## Preguntar antes de borrar archivo
alias rm='rm -i'

Como vemos, los alias nos dan mucha funcionalidad y nos permite ahorrar mucho tiempo.  Otra gran funcionalidad del archivo .bashrc es agrandar la cantidad de comandos que quedan almacenados en el historial. Si ejecutamos lo siguiente:

history

Obtendremos un historial de los últimos comandos que hemos ejecutado. Si usamos el siguiente código:

history | grep ssh

Obtendremos todas las conexiones ssh que hemos hecho últimamente. La parte mala, es que a veces necesitamos echarle un ojo a comandos que ya han sido borrados del historial. Para ello, podemos cambiar el número de comandos que se guardan modificando la siguiente línea:

HISTSIZE=50000

Con esto, los últimos 50.000 comandos serán guardados. Si te hacen falta más, siempre puedes cambiar el número a tu gusto!

Un saludo!

Linus Torvalds, el dictador benévolo: Bronca a un colaborador

Hoy en Libre Soft World queremos relatar una anécdota de Linus Torvalds que nos hace ver su personalidad y el cuidado que tiene con el mantenimiento de Linux.

La respuesta de Linus puede leerse aquí: Respuesta Linus. En él, el creador del sistema operativo argumenta en contra de un commit hecho por uno de los desarrolladores del Kernel. Este commit rompía el funcionamiento de un par de programas de Linux, por lo que el desarrollador suponía que debía ser un Bug en estos programas, y no en los cambios que había hecho. Vayamos citando paso a paso lo que dice Linus:

Mauro, SHUT THE FUCK UP!

Vaya, Linus empieza fuerte…

It's a bug alright - in the kernel. How long have you
been a maintainer? And you *still* haven't learnt
the first rule of kernel maintenance?

If a change results in user programs breaking, it's
a bug in the kernel. We never EVER blame the user
programs. How hard can this be to understand?

Aquí Linus quiere dejar claro que el espacio de usuario es sagrado: nunca ha de romperse. Esta es la primera regla del Kernel. Por lo tanto, el Bug no está en aquellos programas que fallan, sino en los cambios producidos por el desarrollador en el Kernel.

To make matters worse, commit f0ed2ce840b3 is clearly
total and utter CRAP even if it didn't break
applications. ENOENT is not a valid error return
from an ioctl. Never has been, never will be.
ENOENT means  "No such file and directory",
and is for path operations. ioctl's are done on 
files that have already been opened, there's no
way in hell that ENOENT would ever be valid.

Aquí Linus regaña al desarrollador por usar código que no es válido en ese contexto. Eso si, usando unas formas un poco bruscas. La siguiente respuesta corresponde a cuando el desarrollador argumenta que su commit no es ninguna regresión, sino que descubre errores en aplicaciones que debido a su cambio ahora fallan:

Shut up, Mauro. And I don't _ever_ want to hear that
kind of obvious garbage and idiocy from a kernel
maintainer again. Seriously.
I'd wait for Rafael's patch to go through you, but I
have another error report in my mailbox of all KDE 
media applications being broken by v3.8-rc1, and I 
bet it's the same kernel bug. And you've shown 
yourself to not be competent in this issue, so 
I'll apply it directly and immediately myself.

Ahora Linus pone de manifiesto la incompetencia del desarrollador y dice que ya se encargará el mismo de arreglar un Bug que es probable que haya sido provocado por el mismo problema. Y por último:

WE DO NOT BREAK USERSPACE!

Seriously. How hard is this rule to understand? We 
particularly don't break user space with TOTAL CRAP. 
I'm angry, because your whole email was so _horribly_ 
wrong, and the patch that broke things was so 
obviously crap. The whole patch is incredibly 
broken shit. It adds an insane error code (ENOENT), 
and then because it's so insane, it adds a few 
places to fix it up ("ret == -ENOENT ? -EINVAL : 
ret"). The fact that you then try to make *excuses* 
for breaking user space, and blaming some external 
program that *used* to work, is just shameful. It's 
not how we work. Fix your f*cking "compliance tool", 
because it is obviously broken. And fix your 
approach to kernel programming.

               Linus

Termina resaltando la importancia de no romper el espacio de usuario de nuevo. Un programador del Kernel debe tener muy en cuenta que, cosas que funcionaban en el pasado, han de seguir funcionando a pesar de los cambios hechos es el código. Así es como funciona Linux.

Un saludo!

Fuentes: