Test de velocidad de disco duro

Hace un tiempo que he detectado que las prestaciones de mi disco duro han bajado. Además de buscar fallos físicos he querido ver la tasa de velocidad real del mismo. Mediante el siguiente comando:

time dd if=/dev/zero of=TEST bs=4k count=512000

Podemos obtener un informe sobre el funcionamiento del disco, en mi caso:

$ time dd if=/dev/zero of=TEST bs=4k count=512000
512000+0 registros leídos
512000+0 registros escritos
2097152000 bytes (2,1 GB) copiados, 14,8617 s, 141 MB/s

real	0m14.873s
user	0m0.140s
sys	0m5.280s

Así, en el caso de mi disco duro su velocidad en el test ha sido de 141 MB/s.

Referencias

GIT: Repositorios remotos y desarrollo distribuido

Introducción

Hace una semana publiqué una entrada introduciendo el sistema de control de versiones GIT. Ayer añadí otra entrada donde dí unos primeros pasos a git. Hoy después de unas horas de trabajo y recopilar ejemplos basados en mi trabajo diario ha llegado el momento de escribir sobre los repositorio remotos.

Repositorios remotos

Veamos un caso imaginario muy útil. ¿Cual es nuestro escenario?

  • Trabajamos 2+ desarrolladores en un proyecto común.
  • Disponemos de un equipo de trabajo donde día a día actualizamos un repositorio GIT local (a nuestro equipo) para controlar la evolución de nuestro trabajo.
  • Tenemos algún colega/compañero que trabaja desde su casa y también tiene su equipo donde controla su trabajo diario con su instalación local de GIT.
  • Además, cabe la posibilidad que nosotros mismos tengamos en casa otro equipo desde el cual podemos trabajar otras horitas en casa.
La primera pregunta, ¿cómo organizar este lío de tantas personas trabajando en lo mismo sin que haya peligro de sobrescribir uno el trabajo del otro?
Escenario de ejemplo: Repositorios GIT remotos y varios desarolladores
Figura 1: Escenario de ejemplo. Repositorios GIT remotos y varios desarolladores

Bueno, pues ya que hablamos de control de versiones lo primero que entra en juego es un servidor donde crear un/unos repositorio/s GIT donde cada programador realiza un commit de su trabajo y así el resto de colegas estén al tanto de sus cambios (a parte habría que hablar de ciertas políticas o protocolos de trabajo sobre cómo repartir el trabajo pero de eso no hablaremos ahora).

Crear el repositorio en el servidor remoto

Vamos a suponer que disponemos de un servidor con nombre repositorios.net. Este servidor está disponible en Internet o en nuestra red local de trabajo (suponemos una máquina Unix). Hemos creado un usuario llamado git cuya carpeta de trabajo en /home/git. Queremos crear el repositorio para el proyecto ejemplo.

git@repositorios.net:~/$ mkdir ejemplo.git
git@repositorios.net:~/ejemplo.git$ git --bare init
Initialized empty Git repository in /home/git/ejemplo.git/

Ya disponemos de un repositorio (contendor) en crudo donde depositar nuestros commits locales o desde donde descargar las actualizaciones del proyecto realizadas por otros usuarios.

Para poder acceder, desde nuestro directorio de trabajo debemos tener un repositorio git (Vamos a suponer una máquina Windows):

$ git init
Initialized empty Git repository in c:/Workspace/proyecto/.git/
$ git add .
$ git -a -m "Inicio proyecto GIT"

31 files changed, 5873 insertions(+), 0 deletions(-)
create mode 100644 .gitignore
create mode 100644 .project
...
Counting objects: 38, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (37/37), done.
Writing objects: 100% (38/38), 82.87 KiB, done.
Total 38 (delta 1), reused 0 (delta 0)
To ssh://git@repositorios.net/home/git/proyecto.git
* [new branch] master > master

Otro usuario, por ejemplo en un equipo Linux, podría crear su copia de repositorio del siguiente modo:

jperez@jperez-debian:~/gitsample$ git init
Initialized empty Git repository in /home/user/gitsample/.git/
jperez@jperez-debian:~/Desktop/borrar/gitsample$ git remote add Matrix ssh://git@central.ovalus.com:101/home/git/sagema.git
jperez@jperez-debian:~/Desktop/borrar/gitsample$ git pull Matrix
git@central.ovalus.com's password:
remote: Counting objects: 38, done.
remote: Compressing objects: 100% (37/37), done.
remote: Total 38 (delta 1), reused 0 (delta 0)
Unpacking objects: 100% (38/38), done.
From ssh://central.ovalus.com:101/home/git/sagema
* [new branch] master -> Matrix/master
You asked to pull from the remote 'Matrix', but did not specify
a branch. Because this is not the default configured remote
for your current branch, you must specify a branch on the command line.
jperez@jperez-debian:~/Desktop/borrar/gitsample$ git pull Matrix master
git@central.ovalus.com's password:
From ssh://central.ovalus.com:101/home/git/sagema
* branch master -> FETCH_HEAD
jperez@jperez-debian:~/Desktop/borrar/gitsample$ ls
css geo.html google848132b663ce25f4.html index.htm js menu.html responsive robots.txt template.php
jperez@jperez-debian:~/Desktop/borrar/gitsample$ ls -lha
total 76K
drwxr-xr-x 6 jperez jperez 4,0K jun 24 17:05 .
drwxrwxr-x 3 jperez jperez 4,0K jun 24 17:02 ..
drwxr-xr-x 3 jperez jperez 4,0K jun 24 17:05 css
-rw-r--r-- 1 jperez jperez 881 jun 24 17:05 geo.html
drwxr-xr-x 8 jperez jperez 4,0K jun 24 17:05 .git
-rw-r--r-- 1 jperez jperez 46 jun 24 17:05 .gitignore
-rw-r--r-- 1 jperez jperez 53 jun 24 17:05 google848132b663ce25f4.html
-rw-r--r-- 1 jperez jperez 4,1K jun 24 17:05 index.htm
drwxr-xr-x 3 jperez jperez 4,0K jun 24 17:05 js
-rw-r--r-- 1 jperez jperez 8,6K jun 24 17:05 menu.html
-rw-r--r-- 1 jperez jperez 599 jun 24 17:05 .project
drwxr-xr-x 4 jperez jperez 4,0K jun 24 17:05 responsive
-rw-r--r-- 1 jperez jperez 61 jun 24 17:05 robots.txt
-rw-r--r-- 1 jperez jperez 12K jun 24 17:05 template.php
jperez@jperez-debian:~/Desktop/borrar/gitsample$

Apéndice 1: .gitignore

**.gitignore** es un fichero especial para GIT. Se debe situar en la carpeta raíz del repositorio. Contiene los ficheros que no queremos que añada GIT al repositorio (de modo que no serán tenidos en cuenta).

¿Esto es útil? Ya lo creo. Supongamos que trabajamos en un proyecto WEB. Seguramente no querremos añadir los ficheros de imágenes, PDS (photoshop), etc.Si se tratase de un proyecto C++ en Linux seguramente sólo querríamos guardar los ficheros .c y .h. De modo que no querremos guardar los ficheros objeto (.o). En definitiva tratamos de evitar cualquier recurso que no sea código fuente o texto.

Un ejemplo, el caso del proyecto C/C++, no queremos que se tengan en cuenta los ficheros *.o, el directorio tmp (que se usa para almacenar datos temporales de compilación) y otras carpeta que se llama “resources”.

*.o
tmp/
resources/

Considero este tema muy interesante, recomiendo leer la entrada [2].

Referencias

  1. Trabajando con repositorios remotos (Doc oficial de GIT) : http://git-scm.com/book/es/Fundamentos-de-Git-Trabajando-con-repositorios-remotos
  2. Ignorando archivos en GIT: http://es.gitready.com/beginner/2009/01/19/ignoring-files.html

GIT: Guía sencilla para su uso cotidiano

Introducción

Hace unos días publiqué una entrada introduciendo el sistema de control de versiones GIT. Voy a provechar esta entrada para explicar de una forma muy sencilla cómo instalarlo y empezar a trabajar con él.

Instalación en Linux

En Linux es muy sencillo de instalar, desde la propia página WEB nos muestran cómo instalarlo en varias distribuciones:

Distro Comando para su instalación
Debian/Ubuntu
$ apt-get install git 
Fedora
$ yum install git 
Gentoo
$ emerge --ask --verbose dev-vcs/git 
Arch Linux
$ pacman -S git 
FreeBSD
$ cd /usr/ports/devel/git && make install 
Solaris 11 Express
$ pkg install developer/versioning/git 
OpenBSD
$ pkg_add git 

Instalación en Windows

Debemos acceder al apartado de descargas: http://git-scm.com/downloads y obtenerr la versión de Windows. Es un sencillo programa de instalación en modo de asistente (el clásico siguiente-siguiente-siguiente).

Yo recomiendo marcar durante la instalación la opción “Git Bash Here” que nos permite a través del botón derecho del ratón abrir un shell (bash de mingw) en la carpeta que indiquemos. Resulta más cómodo.

Primeros pasos

Supongamos que trabajamos en un proyecto PHP, C u otro lenguaje de programación. Lo primero que hemos de hacer es situarnos en la carpeta raíz del proyecto (Ej: /home/user(projects/gitsample) y crear un repositorio. Si estamos en linux desde el terminal navegamos hasta la carpeta y en Windows con la opción del menú contextual “Git bash here” podemos abrir una consola en esa misma carpeta. Tecleamos los siguientes comandos:

$ git init
$ git add .
$ git commit -m "Estado inicial del proyecto"

¿Qué hemos hecho?

  1. Hemos creado el repositorio (git init, ver carpetas ocultas)
  2. Hemos añadido TODOS los ficheros/carpetas al repositorio (git add .). Es decir, le notificamos que los tenga en cuenta para cualquier cambio.
  3. Realizamos el primer commit del proyecto obteniendo una imagen de su estado inicial (git commit -m MENSAJE)

Conforme trabajemos podemos ir anotando todos los cambios diarios en el proyecto. Por ejemplo del siguiente modo:

$ git add .
$ git commit -a -m "Fecha de hoy: Que cambios hice"

Pero, ¿qué pasa si un día me pongo a trabajar y “me cargo” el proyecto? ¿Cómo lo restablezco todo? ¿Cómo vuelvo a una versión anterior de un fichero? Existen varías formas, pero la más simple es esta (leer la documentación para conocer otros casos y opciones):

$ git reset --hard
$ git reset /directorio/al/fichero/a/recuperar

Este es básicamente el día a día que se lleva a cabo con el control de versiones. En mi caso uso la herramienta gráfica SmartGIT para visualmente consultar todos los diff de los ficheros y como van evolucionando a través de los commit. Si bien es cierto que estos últimos meses trabajo con Aptana Studio y uso directamente algunas de sus herramientas gráficas para manejar GIT.

Proximamente

Otras de las características interesantes de GIT es la posibilidad de trabajar con repositorios distribuidos, ramas y tags. En futuras entradas hablaré de estas funcionalidades.

Referencias

  1. Git sitio WEB oficial: http://git-scm.com/
  2. Manual de referencia de Git :http://git-scm.com/docs
  3. Guía rápida muy útil:http://www.edy.es/dev/docs/git-guia-rapida/
  4. Blog oficial de GIT: http://git-scm.com/blog

Montar una unidad ssh en Windows

¿Alguna vez habéis necesitado copiar ficheros usando una cuenta SSH desde WIndows? Si la respuesta es sí seguramente halláis usado el programa WinSCP. Este programa es muy bueno y cubre muchas necesidades bajo el protocolo SSH. Pero, ¿qué pasa si lo que quieres es montar esa carpeta remota SSH como una unidad de red en Windows?

Hoy he descubierto el programa SSHFS de Dokan que permite configurar una conexión SSH y montar la conexión como una unidad de red en Mi PC (Equipo). En Windows 7 se debe ejecutar como Administrador.

En mi caso, tengo un servidor privado para trabajar, mi equipo personal tiene un GNU/Linux Debian y en mi trabajo uso Windows 7.

Referencias

  1. Dokan: http://dokan-dev.net/en/
  2. Descargar Dokan SSHFS: http://dokan-dev.net/en/download/

GIT: sistema de control de versiones ideal para programadores

Introducción

Hace ya unos años que descubrí GIT y decidí dejar de usar CVS/SVN para el control de versiones de mis proyectos. No voy a explicar sobre cómo funciona y porqué creo que es mejor que otros, sólo diré que cumple totalmente con mis necesidades y me es muy sencillo.

Comencé a usarlo cuando trabaja con el grupo de investigación UniCAD de la Universidad de Alicante. Os dejo unas transparencias que preparé en su día como guía de inicio.

GIT Control de Versiones by José Pérez Martínez

Hoy he tenido que entregar la versión de un proyecto finalizado (en una fecha concreta de su desarrollo) y
me ha sido muy sencillo gracias a GIT. Imaginaos que queréis obtener un ZIP del último commit:

git archive  --format zip --output ~/FICHEROZIP.zip master

Sencillo, ¿no?

Con una sola orden he recuperado una ZIP con TODO el proyecto a fecha de hace tres meses (en mi caso).

Seguiré escribiendo varías entradas con notas sobre GIT,

Referencias

  1. Git sitio WEB oficial: http://git-scm.com/
  2. Manual de referencia de Git :http://git-scm.com/docs

sudo: ejecutar comandos con privilegios de root

Introducción

El comando sudo permite ejecutar un comando como el administrador del sistema (root). Este sistema es de uso obligatorio en Ubuntu o MacOS si se quiere realizar alguna tarea de administrador (apt-get, …). Resulta muy cómoda y “segura” ya que para realizar ciertas tareas simples de instalación/actualización del sistema no necesitamos arrancar un shell como root.

Mi distribución es Debian y en esta distro por defecto existe el usuario root y el usuario que se de de alta durante la instalación. Si queremos instalar un paquete, modificar el grub, o cualquier proceso que necesite privilegios de root necesitamos arrancar un shell como root o iniciar sesión como él. Si no somos expertos además de incomodo puede ser “peligroso”. Por eso configurar nuestro usuario con permisos para usar sudo puede resultar muy interesante.

Permitir el uso de sudo

En primer lugar (en mi caso, en Debian) arrancaremos un shell como root y ejecutaremos el comando:

# visudo

Este comando nos abre (con el editor por defecto: vi, nano, emacs) el fichero /etc/surdoers que por seguridad tiene los siguientes permisos:

$ ls -lh /etc/sudoers
-r--r----- 1 root root 723 jun 1 2012 /etc/sudoers

El comando visudo cambia los permisos y abre un editor con el fichero sudoers, pero además comprueba la integridad del mismo para evitar conflictos en el sistema. Hay que tener en cuenta que es un fichero “critico”. En mi caso el fichero sudoers es algo así:

#
# This file MUST be edited with the 'visudo' command as root.
#
# Please consider adding local content in /etc/sudoers.d/ instead of
# directly modifying this file.
#
# See the man page for details on how to write a sudoers file.
#
Defaults        env_reset
Defaults        secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

# Host alias specification
# User alias specification
# Cmnd alias specification

# User privilege specification
miusuario    ALL=(ALL:ALL) ALL

# Members of the admin group may gain root privileges
%admin ALL=(ALL) ALL

# Allow members of group sudo to execute any command
%sudo   ALL=(ALL:ALL) ALL

# See sudoers(5) for more information on "#include" directives:

#includedir /etc/sudoers.d

Una vez guardado, nuestro usuario ya tendría privilegios de root y puede realizar cualquier tarea de administrador anteponiendo la palabra sudo. Por ejemplo, editar el fichero de fuentes para apt (la primera vez que ejecutemos sudo nos mostrará un mensaje como este, recordando que un gran poder conlleva una gran responsabilidad).

$ sudo nano /etc/apt/sources.lst 

We trust you have received the usual lecture from the local System Administrator.
It usually boils down to these three things: 

   #1) Respect the privacy of others. 
   #2) Think before you type. 
   #3) With great power comes great responsibility. 

Password:_

Referencias

  1. Página oficial de sudo: http://www.sudo.ws/
  2. Página man de sudo: http://www.sudo.ws/sudo/sudo.man.html
  3. Sudo en Wikipedia: http://es.wikipedia.org/wiki/Sudo
  4. Configuración de /etc/sudoers: http://www.rpublica.net/sudo/sudoers.html

Instalar LaTeX en Windows: MiKTeX

Introducción

Hace poco un amigo muy cercano mostró interés a comenzar a componer texto con el procesador de textos LaTeX.

No voy a explicar en este post la historia de LaTeX ni justificarlo (no descarto hacerlo en un futuro), pero adelantaré que es un increíble procesador para texto científicos, matemáticos y texto de ingeniería en general. Pero no sólo eso, es un programa tan prolífico que podemos generar todo tipo de documentos: transparencias (tipo powerpoint), partituras musicales, esquemas de química orgánica, y todo tipo de documentos normales. Quizás en un futuro cercano dedique un post a poner ejemplos de documentos en LaTeX.

MiKTeX

MiKTeX es una distrubición LaTeX para el sistema operativo Windows. Sus principales ventajas son la sencillez en su instalación y la perfecta integración que tiene en el sistema operativo. Podemos descargarlo desde esta página. Si descargamos el basic installer tendremos la versión mínima e indispensable del programa (Solo 200+ MB). Para añadir funcionalidades extra se pueden instalar más tarde en su gestor de paquetes.

Texmaker

Este es uno de los mejores editores para LaTeX tanto para usuarios expertos como nóveles. Es muy sencillo, tiene botones y menús para facilitar la escritura y lo mejor de todo es el panel derecho dónde se muestra el resultado de nuestro documento.

De modo que a la izquierda queda el código fuente y cada vez que se genera el documento a la derecha se refresca éste para poder verlo y además nos indica en rojo a qué altura del documento queda nuestra posición exacta en el editor.

Además es un editor multiplataforma con lo que podemos usarlo en Windows y compartir el trabajo con cualquier usuario de GNU/Linux, MacOS sin problemas. Podemos ver algunos pantallazos esta página.

Referencias

Un clásico: Instalar las fuentes de Windows en Linux

Una de las malas costumbres que tengo cuando uso Linux (sobre todo por la navegación WEB) es instalar las fuentes True Type de Windows en Linux. Me resulta especialmente molesto en algunos sitios WEB entrar y encontrarme una fuente que sé es Arial o similar representada con “alguna” fuente “similar” de mi distro.

Para corregir esto podemos instalar éstas fuentes en Linux.

$ sudo apt-get install msttcorefonts 
$ sudo fc-cache -fv

El paquete msttcorefonts: Contiene estas fuentes:

  • Andale Mono
  • Arial Black
  • Arial (Bold, Italic, Bold Italic)
  • Comic Sans MS (Bold)
  • Courier New (Bold, Italic, Bold Italic)
  • Georgia (Bold, Italic, Bold Italic)
  • Impact
  • Times New Roman (Bold, Italic, Bold Italic)
  • Trebuchet (Bold, Italic, Bold Italic)
  • Verdana (Bold, Italic, Bold Italic)
  • Webdings

Nota: Cuando pongo comando de root suelo usar la instrucción sudo que me proporciona para ese comando privilegios de root. Mi sistema operativo es Debian y por defecto no funcionará (cosa que en Ubuntu sí) para que os sirva debéis añair vuestro usuario al fichero de sudoers.

Editado: He añadido una entrada sobre sudo y el fichero /etc/sudoers, podeís leer más aquí: https://blogs.ua.es/jpm33/?p=73

Referencias

  1. Información del paquete en packages.debian.org: http://packages.debian.org/stable/x11/msttcorefonts
  2. Si eres usuario de Fedora o una distrubición basada en RPM aquí tienes otra opción: http://corefonts.sourceforge.net/

Acceder a particiones Ext3/Ext4/… desde Windows 7

Como ya comenté hace poco me instalé el nuevo GNU Linux Debian 7.0 “Wheezy”. Tengo una serie de proyectos por delante para los cuales prefiero sin dudarlo este sistema operativo.

Cuando esto en Windows (en mi caso Windows 7) en ocasiones necesito acceder a algún fichero en mi partición /home (tipo ext4). Para eso he encontrado el programa Ext2Read.

Debe de ejecutarse como Administrador para que puede tener acceso al disco duro y leer las tablas de inodos. Su uso es muy sencillo. Una vista de árbol donde se va desplegando la jerarquía de disco y para copiar un fichero hacia Windows sólo hay que usar la opción “Save”.

Espero que os sea tan útil como a mi.

Referencias