Skip to main content

Autor: Joseba Garai

10 frontend para Git

Joseba Garai 2 comentarios

El sistema de control de versiones Git se administra principalmente desde la línea de comandos. Sin embargo, algunas tareas puede ser más fácil de administrar si usamos uno de los muchos frontend disponibles.

Si tenemos una aburrida tarde, podemos pasarla probando algunos de los siguientes frontend para git y descubrir cual nos puede resultar más útil.

1. gtitk.

Navegador gráfico de git. Usa Tcl/Tk. Acompaña a Git en el paquete gitk. Instalar con:

sudo aptitude install gitk
gitk

2. git gui

Componente de Git. Herramienta para hacer commint. Usa Tcl/Tk. Acompaña a Git en el paquete git-gui.

sudo aptitude install git-gui
git gui

3.Qgit

Frontend que usa la herramienta de desarrollo Qt.

sudo aptitude install qgit
qgit

4. Giggle

Frontend que usa el entorno de desarrollo GTK+.

sudo aptitude install giggle
giggle

5. git-cola

Forntend desarrollado en python con el toolkit QT.

sudo aptitude install git-cola
git-cola

6. gitg

Clon de Gitx hecho en GTK+/GNOME.

sudo aptitude install gitg
gitg

7. tig

Forntend en modo texto que usa ncurses. Ligero y excelente para usar en un servidor remoto.

sudo aptitude install tig
tig

8. smartgit
Opción comercial muy potente de un frontend para git. Basado en Java. Se puede descargar para probarlo.

9. Egit
Egit es un plugin para el entorno de desarrollo Eclipse. Se instala desde Help -> Install New software.

10. git extensions
Frondend para Microsoft Windows. Aunque funciona con Mono.

¿Te parecieron pocos?. En el wiki de Git puedes en contrar muchos más, para diferentes sistemas operativos.

Además, multiples IDEs tienen incluido soporte para Gti. Por ejemplo Aptana entre los que suelo usar.

Entendiendo la relación señal ruido y la atenuación

Joseba Garai 1 comentario
Estos días estoy teniendo algunos problemas con el servicio del ADSL. Por eso me he interesado en la terminología relacionada. Los conceptos más importantes para determinar la calidad de la línea son la relación señal ruido o SNR y la atenuación. Dos magnitudes que se pueden conocer fácilmente accediendo al panel de administración del módem router adsl.
Un texto que me ha parecido muy bueno para entenderlo es él que aparece en el siguiente comentario en el foro y que traduzco más abajo.

Relación señal ruido

La relación señal ruido (a menudo abreviado como SNR o S/R) es una medida de ingeniería electrónica que define la relación entre la potencia de una señal con la potencia del ruido que la corrompe.
En términos menos técnicos, la relación señal ruido compara el nivel de una deseada señal (como música) con el nivel del ruido de fondo. Cuanto más alto la relación, menos molesto es el ruido de fondo. El concepto también puede ser entendido como normalizando el nivel de ruido a 1 (0 db) y midiendo como la señal destaca.  En algunos casos de entrelazado puede ayudar incrementar el margen del ruido a un nivel aceptable.
En general cuanto más alto es la señal sobre el ruido mejor; la señal es más clara.

Atenuación

La atenuación es la gradual pérdida de intensidad de cualquier tipo de flujo a través de un medio (por ejemplo, la reducción de la fuerza de señal debido a la longitud de tu línea de teléfono). Por ejemplo, la luz del sol atenuada por unas gafas de sol, y los rayos X atenuados por el plomo. En una ADSL la señal es atenuada por la longitud de las líneas de cobre. La atenuación esta normalmente relacionada con la longitud de la línea. El cobre es tradicionalmente usado en el bucle local y la mayor medida de cobre dará la mejor señal, sin embargo en algunas líneas puede haber algo de aluminio o uniones de aluminio en la línea las cuales incrementan la resistencia… tanto como la oxidación de las uniones. La atenuación es medida en db o ruido. A mayor ruido mas débil la señal de datos.
En general, cuanto más baja la atenuación mejor; la señal es mas fuerte.

Mi tabla de comparaciones

SNR:
6dB o menos es muy malo y se podría experimentar falta de sincronismo o problemas intermitentes de sincronismo.
7dB-10dB es favorable pero no deja mucho espacio para variaciones de las condiciones.
11dB-20dB es bueno con pocos o ningún problema de sincronismo.
20dB-28dB es excelente.
29dB o por encima es extraordinario.
Atenuación:
20dB o menos es extraordinario.
20dB-30dB es excelente
20dB-40dB es muy bueno
40dB-50db es bueno
50db-60dB es pobre y se puede experimentar incidencias de conectividad
60dB o por encima es malo y experimentará problemas de conectividad
La siguiente guía (distancia vs. atenuación vs. velocidad) te da una estimación de lo que puedes lograr: <1km podría estar en 23-24Mbit (bonita velocidad, ¿pero no mosquea que la gente de telefónica pueda caminar a través de tu dormitorio?
1.0km = 13.81dB = 23Mbit
1.5km = 20.7dB = 21Mbit
2.0km = 27.6dB = 18Mbit
2.5km = 34.5dB = 13Mbit
3.0km = 41.4dB = 8Mbit
3.5km = 48.3dB = 6Mbit
4.0km = 56dB = 4Mbit
4.5km = 62.1dB = 3Mbit
5.0km = 69dB = 2Mbit
>5.0km (estas más o menos tocado — lo siento por ti)

Bienvenidas correcciones.

Identificación con el servidor SSH usando llaves RSA Ubuntu server 12.04 LTS

Joseba Garai 1 comentario

Llega un momento en que introducir cada vez que queremos ingresar en nuestro servidor nuestra contraseña empieza a cansar. Esta contraseña además suele ser no muy sólida ya que es de las que debemos recordar. Y en todo caso entrar con contraseña no deja de ser más inseguro que usando claves públicas.

El servicio Ssh permite poder acceder mediante clave pública, de modo que no necesitemos escribir nuestra contraseña para ingresar en el servidor.

La idea detrás es bastante sencilla. En nuestro equipo local desde el que queremos acceder, generamos una llave pública RSA. Después la compartimos con el usuario remoto, para que la guarde añadiéndola a un archivo llamado authorized_keys. En este archivo el usuario remoto guarda todas las claves públicas con las que identifica a los usuarios remotos que quieran ingresar en su cuenta de usuario.

Veamos como hacerlo usando una terminal. En nuestro equipo local, en una terminal, ejecutamos el comando:

ssh-keygen

Este comando va a generar las llaves pública y privada. Aunque ahora solo nos interesa la pública, que estará en un archivo llamado id_rsa.pub. La aplicación nos va a pedir una passphrase, que no necesitamos, y bastará con dar retorno para no poner ninguna.

Una vez creada la llave pública debemos añadirla al almacén del usuario remoto en el cual queremos autentificarnos. Este almacén esta en un directorio oculto en su $HOME, llamado .ssh. Y dentro de él el archivo authoriezed_keys donde se añaden las llaves.

Primero vamos a subir la llave RSA pública al usuario remoto. El comando siguiente bastaría, adaptándolo a nuestro usuario y servidor:

scp ~/.ssh/id_rsa.pub usuario@servidor.com:~/id_rsa.pub

Después accedemos al usuario remoto haciendo la autentificación de la forma normal, es decir usando contraseña. El siguiente comando adaptándolo a nuestro usuario y servidor remoto  nos vale:

ssh usuario@servidor.com

Creamos el directorio, que probablemente no exista con:

mkdir ~/.ssh

Y añadimos o creamos el almacén con la llave RSA pública que subimos antes y que esta en el $HOME del usuario, con:

cat ~/id_rsa.pub >> ~/.ssh/authorized_keys

Ahora, una vez añadida nuestra llave pública al almacén authorized_keys, podemos salir, y volver a intentar conectar. Si todo funciona correctamente la autentificación se producirá sin solicitarnos la contraseña para ingresar.

Para cada usuario local desde donde queremos conectarnos hay que repetir los pasos. Igualmente para cada usuario remoto al que queremos acceder.  Una vez accedemos al usuario remoto con llave pública es buen momento para ponerle una contraseña fuerte como las que podemos generar en gpassword.com. El comando para cambiar la contraseña a un usuario es:

sudo passwd usuario.

Donde usuario lo cambiaremos por el nombre de usuario al que queremos cambiar la contraseña.

Probado en un servidor Ubuntu Server 12.04 LTS. Llave RSA pública generada en Debian 6.0.