Crea un servidor GIT en un NAS Synology

Desde hace unos meses adquirí un NAS DS215j de la marca Synology. La cual sorprende por la cantidad de aplicaciones que pueden instalarse con un par de clicks:

https://www.synology.com/es-es/dsm/app_packages

Una de las utilidades que pueden ser instaladas es Git Server, permitiendo crear un servidor Git propio en el que alojar tus proyectos.

Lo primero que necesitamos es habilitar el acceso por ssh a nuestro servidor desde Panel de control > Terminal. Es conveniente que no uses el puerto 22 y uses otro de tu elección, para mejorar la seguridad de tu NAS al no usar los puertos por defecto.

Lo segundo es instalar el paquete que nos proporciona el Servidor Git. Una vez instalado nos permitirá dar acceso a los usuarios que queramos:

synology_git-server

 

Los usuarios de Git quedarán restringidos a realizar actividades relacionadas con Git con una herramienta shell llamada git-shell. Esta shell de inicio de sesión se aplicará a los usuarios de Git para garantizar que las cuentas se utilicen únicamente para operaciones Git. El resultado es que los usuarios de Git solo pueden utilizar la conexión SSH para introducir y extraer repositorios Git, y no tendrán acceso completo a DSM.

Debido a la limitación citada, sólo el usuario "admin" del NAS puede crear los repositorios. Una vez creados los repositorios, cualquier usuario al que demos acceso desde la app del Servidor Git, podrá usar los repositorios.

Para crear el repositorio podemos hacerlo desde un cliente ssh como Putty. Usando la dirección DDNS de nuestro NAS (Panel de control > Acceso Externo > DDNS) y el puerto que definimos para acceder por ssh (Panel de control > Terminal), nos conectamos con las credenciales de acceso del usuario "admin". Una vez dentro creamos el repositorio con los siguientes comandos:

 

cd /volumeX #Donde X es el número del volumen
mkdir GIT #Crear la carpeta
cd GIT
git init --bare --shared mi-repositorio.git

 

Con el repositorio creado, podremos acceder un clone usando la dirección:

 

git clone ssh://[Usuarios]@[DDNS:Puerto]/volumeX/GIT/mi-repositorio.git

 

O si prefieres, sin el usuario, de la siguiente manera:

 

git clone ssh://[DDNS:Puerto]/volumeX/GIT/mi-repositorio.git

 

A partir de este momento, ya tenemos listo nuestro proyecto para trabajar con él en local y sincronizar los cambios con el servidor.

Para más información consulta la ayuda de Synology:

https://help.synology.com/dsm/?section=Git&version=2.3&link=git.htm

El veterano eMule vuelve a la carga tras años de inactividad

eMule el programa más conocido de intercambio de ficheros iniciado el 13 de mayo de 2002 por Hendrik Breitkreuz (Merkur), y que hacía uso de la filosofía P2P en su diseño, vuelve aparentemente a la carga con una la versión 0.50b. El comunicado ha sido publicado en el foro de la comunidad de eMule:

http://forum.emule-project.net/index.php?showtopic=159790

Las mejoras que se incluirán en esta versión 0.50b son las siguientes:

  • Revisión del código de subida
  • Mejor manejo en la IO (Entrada y Salida)
  • Optimización del manejo interno de hashes AICH
  • Sustituido Filedonkey Search por ContentDB
  • Actualización de librerías (como la librería miniupnpc haciendo compatible UPnP con más routers)
  • Cambios y correciones menores

Estas mejoras principalmente aumentan la eficiencia en el uso de ancho de banda de las conexiones, pudiendo usar completamente la capacidad de subida. Esto quiere decir que otros usuarios descargarán más rápido. Una puesta apunto que le vendrá muy bien.

eMule fue el sistema P2P más extendido en su momento hasta que poco a poco fue desplazado por BitTorrent. A pesar de ello tiene una extensa base de usuarios activos y existen muchos archivos compartidos en sus redes.

Descargar la versión beta desde los siguientes enlaces:

v0.50b BETA1 - Installer

v0.50b BETA1 - Binary

v0.50b BETA1 - Sources

Puedes reportar errores si los detectas en el foro de eMule.

eMule_matrix

Corrección de colores en Windows para Juegos Abandonware

El tiempo pasa y la tecnología cambia mejorándose y haciéndose más cómoda y rápida. Los sistemas operativos cómo núcleo y base para la ejecución de programas no son ajenos a ello, y lejos de solamente evolucionar, tienen la difícil tarea de mantener la compatibilidad con lo ya existente.

En el caso concreto de Windows, el cual cumplirá 35 años el próximo 20 de Noviembre, existe multitud de software que ha sido desarrollado. De manera nativa Windows ha intentado ofrecer compatibilidad con el software desarrollado para sistemas anteriores, ya sea de manera implícita sin que el usuario tuviese que hacer nada o explícita, permitiendo que el usuario elija la compatibilidad de manera manual desde propiedades del archivo.

Propiedades-Compatibilidad

Por norma general estas opciones suelen bastar para hacer funcionar buena parte del software antiguo o también denominado Abandonware.

En el caso particular de los juegos suelen ser especialmente útiles estas opciones, permitiendo correr juegos que se diseñaron para sistemas operativos anteriores. En la práctica, y para la gran parte de los casos, las opciones facilitadas por las versiones de Windows más actuales, nos resuelven la papeleta para poder correr dichos juegos.

En casos particulares esto a veces no es suficiente y los juegos a pesar de funcionar, contienen errores gráficos que afectan a la interpretación de los colores originales del juego. Un caso en el que se comprueba fácilmente estos fallos, es el juego de "Age of Empires 2" si se ejecuta, por ejemplo, en un Windows 7.

age_of_empires_color errors

El fallo en la interpretación de los colores es causado por la corrupción de la paleta de colores. El causante de que se corrompan los colores es el proceso "explorer.exe" que se ejecuta en todo momento en el sistema, encargado de gestionar toda la interacción que hay en el escritorio (iconos del escritorio, barra de navegación...).

El problema viene dado porque dicho proceso tiene problemas de funcionamiento para modos de vídeo con color de 16 bits sin aceleración gráfica. Puesto que el proceso explorer presenta dicho problema, el cierre del mismo antes de lanzar el juego, solucionará el problema de corrupción de la paleta de colores.

Un solución práctica consiste en cerrar el proceso explorer, lanzar el juego y volver a lanzar el proceso explorer cuando se cierre el juego. Para ello basta con crear un  archivo con extensión ".bat", por ejemplo "Lanzador.bat".

Dentro del fichero escribiremos las siguientes líneas:

taskkill /F /IM Explorer.exe
EJECUTABLE_DEL_JUEGO.EXE
start explorer.exe 

Este archivo Lanzador.bat es un script que nos lanza el ejecutable (.EXE) que queramos tras cerrar el proceso explorer mediante el comando "taskkill", y queda a la espera de que termine el ejecutable para poder volver a lanzarlo con el comando "start".

Esta solución simple y sencilla es válida para todos aquellos programas y juegos que presenten errores en la paleta de colores.

Google Code cierra sus puerta

Google Code nació en 2006 como un plataforma para que los desarrolladores pudiesen compartir y gestionar  sus proyectos de manera fiable con la comunidad. En su momento fue la primera plataforma de este tipo y no tuvo competencia hasta el año 2008 en el que aparecieron Github y Bitbucket.

La falta de evolución de la plataforma Google Code le ha llevado a quedarse bastante atrás respecto a sus alternativas. En los último años ha habido una gran migración de proyecto alojados en Google Code, hacia Github y Bitbucket, siendo Github preferido en el caso de respositorios para proyectos públicos y Bitbucket para repositorios de carácter privado. Esto le ha llevado a Google al anuncio del cierre de la  plataforma para el próximo 26 de Enero de 2016.

Desde el 12 de Marzo del 2015, Google ya no permite la creación de nuevos proyectos y partir del 24 de Agosto de 2015 el sitio será de sólo lectura hasta el 26 de Enero de 2016. No obstante, Google permitirá la descarga del código fuente de los proyectos durante todo el 2016.

Google  no cerrará el servicio para todos los proyectos, ya que mantendrá los proyecto como Android y Chrome. También seguirá manteniendo los mirrors de proyectos como Eclipse, Kernel.org y otros.

Para el resto de proyectos que no son los citados, Google a proporcionado herramientas para portar los proyectos a Github, Bitbucket, SourceForge o Gitlab.  Adicionalmente Google ha integrado en Google Code una herramienta para migrar a Github los proyectos.

 

Google_Code_Export_to_Github

 

Google se desprende así de lo que fue su precursor en este tipo de herramientas, seguramente para centrarse en Cloud Source Respositories que actualmente se encuentra en estado beta.

A pesar del diplomático cierre de Google Code por parte de Google, la plataforma tiene multitud de proyectos, muchos de ellos alojados en exclusiva en Google Code. Esto quiere decir que si no se migran, los proyectos serán borrados. Lo ideal es que los desarrolladores de cada proyecto migren los proyectos, pero es posible que muchos proyectos estén abandonados por sus desarrolladores o que hayan caído en el olvido y solo se distribuyan los binarios. No obstante, con la herramienta de migración de proyecto a Github, cualquier usuario puede perpetuar un repositorio de Google Code en Github.

Por eso animo a que todos aquellos proyectos de Google Code que tengas como favoritos, conozcas o hayas consultado alguna vez,  los exportes a un respositorio público de Github, si no lo están ya en Github u otra plataforma de las citadas. Entre todos podemos perpetuar el ecosistema de código abierto que inició Google Code.