atom.io 1.13 x32 bits para linux

Mucha gente conoce Atom. Atom es un editor de código open source desarrollado por GitHub. Su mejor característica es su alta personalización.

Pues bien, en su web oficial podemos encontrar para descargar muchas versiones para las diferentes arquitecturas de procesadores (x86 y x86_64), excepto para distribuciones Linux. Para estas sólo se encuentra la versión de 64 bits, por lo que si usamos una distribución de 32 bits (como la que uso en la universidad) no podremos contar con este editor. No, a menos que lo compilemos manualmente, cosa que no es sencilla para alguien principante en la materia, puesto que el código tiene un pequeño bug que compila la versión de 64 bits aunque estemos en una plataforma de 32bits. Hay solución, pero aún no están implementados los cambios a día de hoy (20/10/2016) por lo que hay que hacerlos a mano.

Yo lo hice, compilé el programa y lo subí a un fork de un repositorio de alguien que ya había compilado una versión anterior. Está compilado en lubuntu xenial x32, una versión ligera de Ubuntu.

El archivo .deb lo podéis encontrar aquí. Si no sabéis instalarlo, seguid esta guía, aunque en muchas distribuciones con hacer doble click al archivo sería suficiente.

Como bonus, un muy buen artículo de emezeta donde hablan de cómo sacarle partido; confirarlo y los mejores plugins.

Optimizar OSMC/KODI para reproducción en LAN (parte 2)

En la entrega anterior vimos una parte de cómo optimizar Kodi para que la reproducción a través de nuestra red doméstica vaya mejor de lo que iba antes.

En mi caso esto no era suficiente, ya que seguía teniendo tirones para archivos de vídeo mayores de 900 megas (hoy en día casi cualquier archivo supera ese tamaño.

Para ello debemos prescindir del protocolo Samba y pasarnos al sistema NFS, o usar ambos si vamos a acceder a las carpetas que tengamos compartidas desde otros PC con windows. Si tenemos un servidor windows también podemos usar programas que nos ofrezcan esta funcionalidad, como por ejemplo FreeNFS (la última aztualización es del 2013) o haneWIN NFS Server. Personalmente no los he probado, así que no podría recomendar ninguno

Bueno, al meollo de la cuestión. Todo este post está orientado para ser realizado con Debian 8 en la parte del servidor y con OSMC en la parte de la raspberry pi 2, el cual está basado también en Debian. También debería funcionar en distribuciones ubuntu y sus variables, tanto en la versión cliente como en la versión del servidor.

Lo primero que tenemos que hacer es instalar el paquete NFS. En el cliente escribimos:

sudo apt-get install nfs-common

Pulsamos que  que queremos instalar los paquetes adicionales en caso de que los haya. Seguidamente, en la parte del servidor:

sudo apt-get install nfs-kernel-server nfs-common

Volvemos a indicar que instale las dependencias de los paquetes en caso de haberlas. Ya tenemos instalado en ambas partes los paquetes necesarios. Ahora trabajamos en la parte del servidor, mas concretamente en el archivo /etc/exports 

Indicamos la ruta de los directorios que queremos exportar y, como medida de seguridad adicional, a la ip que queremos exportarla (es decir, quién puede acceder a dichas carpetas). Por esta razón tengo puesta una ip fija en la raspberry. El archivo quedaría tal que así:


# /etc/exports: the access control list for filesystems which may be exported
# to NFS clients. See exports(5).
#
# Example for NFSv2 and NFSv3:
# /srv/homes hostname1(rw,sync,no_subtree_check) hostname2(ro,sync,no_subtree_check)
#
# Example for NFSv4:
# /srv/nfs4 gss/krb5i(rw,sync,fsid=0,crossmnt,no_subtree_check)
# /srv/nfs4/homes gss/krb5i(rw,sync,no_subtree_check)
#
/home/archivos_video 192.168.1.254(ro)
/home/public 192.168.1.254(rw)

Básicamente, las líneas que empiezan por # son comentarios. En la penúltima línea se indica que la ruta /home/archivos_video se «exporta» a la dirección ip 192.168.1.254 (la de mi raspberry) como sólo lectura (read only).

Seguidamente en la raspberry, los importamos editando el archivo /etc/fstab, quedando de la siguiente manera:

/dev/mmcblk0p1 /boot vfat defaults,noatime 0 0
/dev/mmcblk0p2 / ext4 defaults,noatime 0 0
192.168.1.192:/home/transmission/pelis /home/osmc/Movies nfs vers=3,udp,x-systemd.automount,noauto
192.168.1.192:/home/transmission/series /home/osmc/TVShows nfs vers=3,udp,x-systemd.automount,noauto
192.168.1.192:/home/transmission/documentales /home/osmc/Documentals nfs vers=3,udp,x-systemd.automount,noauto
192.168.1.192:/home/public/temp /home/osmc/.kodi/temp nfs vers=3,udp,x-systemd.automount

Las dos primeras líneas vienen por defecto. En las líneas 3,4,5 y 6 estoy montando los directorios que estoy exportando en unas carpetas previamente creadas. Paso a explicar qué es cada opción de las líneas del archivo:

  • 192.168.1.192:/home/transimision…..: La ruta remota que hemos compartido a través de NFS
  • nfs: Probablemente el parámetro más obvio. Estamos indicando el sistema de archivos a usar
  • vers=3La versión a usar del protocolo NFS. En este caso la 3. No hemos cogido la 4 porque hay opciones que no nos interesan y complicarían la configuración ligeramente. Para más información podéis leer el artículo de la wikipedia.
  • udp: Pese a que UDP no está orientado a conexión y no tiene reenvío de tramas erróneas, lo vamos a elegir porque es el que mayor tasa de transferencia nos da. A mi no me ha dado ningún problema. Más abajo tenéis una tabla donde se indica el resultado de diferentes pruebas cliente-servidor realizados en mi red interna.
  • noauto: esto hará que el montaje no se realice ni cuando se inicia el sistema ni cuando ejecutamos mount -a.
  • x-systemd.automount: El montaje se realizará la primera vez que se accede a los datos (por lo que evitaremos el error de device not found que da al inicio, pues se intenta montar antes de que esté disponible la tarjeta de red). Hay una línea que no tiene la opción de noauto y, aunque dará error al iniciar OSMC, se montará igualmente. Esto lo he puesto así porque me interesa que se monte cuanto antes. Suele ir en conjunción con noauto.

noauto x-systemd.automount en la misma línea básicamente indica al sistema que se monte el directorio bajo demanda.

Prueba 1

Montando a pelo con el comando: sudo mount.nfs 192.168.1.192:/home/public /home/osmc/temporal/

El montaje queda: 192.168.1.192:/home/public on /home/osmc/temporal type nfs4 (rw,relatime,vers=4.0,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.254,local_lock=none,addr=192.168.1.192)

Sequential Output Sequential Input Random
Per chr Block Rewrite Per chr Block Seeks
K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec K/sec /sec %CP
154 97 11257 5 5147 6 508 99 11806 5 161.5 18
259ms 6606ms 6788ms 33374us 443ms 1955ms
Sequential create Random create
Create Read Delete Create Read Delete
/sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
21 1 2587 9 197 8 21 1 1815 23 791 21
348ms 1008ms 11378ms 433ms 5781us 269ms

Prueba 2

Modificación en fstab192.168.1.192:/home/public /home/osmc/temporal nfs vers=3,udp

El montaje queda: 192.168.1.192:/home/public on /home/osmc/temporal type nfs (rw,relatime,vers=3,rsize=32768,wsize=32768,namlen=255,hard,proto=udp,timeo=11,retrans=3,sec=sys,mountaddr=192.168.1.192,mountvers=3,mountport=49609,mountproto=udp,local_lock=none,addr=192.168.1.192)

Sequential Output Sequential Input Random
Per chr Block Rewrite Per chr Block Seeks
K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec K/sec /sec %CP
157 97 11596 5 5554 7 525 99 11674 6 115.2 14
258ms 5168ms 5931ms 34241us 44100us 3154ms
Sequential create Random create
Create Read Delete Create Read Delete
/sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
21 1 12000 28 1285 19 21 1 2051 23 1680 20
349ms 81877us 264ms 344ms 9133us 54287us

Prueba 3

Modificación en fstab192.168.1.192:/home/public /home/osmc/temporal nfs vers=3,rsize=8192,wsize=8192,udp,retrans=2.

El montaje queda: 192.168.1.192:/home/public on /home/osmc/temporal type nfs (rw,relatime,vers=3,rsize=8192,wsize=8192,namlen=255,hard,proto=udp,timeo=11,retrans=2,sec=sys,mountaddr=192.168.1.192,mountvers=3,mountport=49609,mountproto=udp,local_lock=none,addr=192.168.1.192)

Sequential Output Sequential Input Random
Per chr Block Rewrite Per chr Block Seeks
K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec K/sec /sec %CP
158 97 11362 5 5487 9 525 98 11430 9 138.7 16
261ms 5146ms 5791ms 31337us 81089us 5215ms
Sequential create Random create
Create Read Delete Create Read Delete
/sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
21 1 12067 27 1291 18 21 1 2005 24 1653 22
403ms 84253us 247ms 1064ms 10077us 7101us

Optimizar OSMC/KODI para reproducción en LAN (parte 1)

Muchos en casa tenemos un pequeño NAS o algún PC antiguo que nos hace de servidor (torrent, owncloud, apache, etc..) con carpetas compartidas para poder acceder a los archivos de vídeo que tenemos en el servidor.

Por desgarcia, el método normal que todo el mundo conoce de compartir archivos (mediante samba) no es eficiente y produce cortes en archivos de video muy pesados (también de audio).

En esta serie de artículos escribiré las configuraciones que tengo en casa y los pasos para llevarlas a cabo, ya que desde que lo tengo así configurado me va muy bien, llegando a  reproducir a la perfección archivos de 30 gigas.

Configuración de KODI v16

Esta configuración es válida para KODI v16, puesto que en el 17 cambiarán las etiquetas.

Este paso es el más obvio, pues el que más se recomienda tanto en foros como en blogs especializados.

Consiste en editar el archivo advancedsettings.xml que se encuentra en la ruta /home/osmc/.kodi/userdata/

Copio y pego parte del contenido (el que nos interesa en esta sección) de mi archivo y pongo una breve descripción de qué hace cada cosa.


<advancedsettings>
 <network>
  <cachemembuffersize>104857600</cachemembuffersize>
  <readbufferfactor>3</readbufferfactor>
  <buffermode>0</buffermode>
 </network>
</advancedsettings>

  • cachemembuffersize: Son los bytes de memoria RAM que se usarán para almacenar la cache de lo que vayamos a reproducir. Si se pone un 0, se usará todo el espacio disponible en el disco como cache. En esta configuración discrepo, ya que, cuando usamos Pulsar, por ejemplo, el archivo de vídeo se descarga entero a la tarjeta de memoria si o si. En otro artículo veremos como cambiar la ubicación de la cache para alargar la vida de nuestra tarjeta microSD.
  • readbufferfactor: Factor que multiplica lo que guarda de vídeo respecto a lo que estás viendo. EL valor 1 guarda un poco más. El 2 el doble de ese valor etc. Por defecto es 4. Cuanto mayor valor, mayor ancho de banda.
  • buffermode: Aquí va un valor desde 0 a 3. Estos valores son lo siguiente:
    • 0: Forzar el uso del buffer en todos los sistemas de archivos de Internet ( como “2” pero añadiendo también ftp,webdav,etc) Opción por defecto.
    • 1: Forzar el uso del buffer en todos los sistemas de archivos (incluyendo el local).
    • 2: Usar solo el buffer en los sistemas de archivos de Internet de streaming (http,etc).
    • 3: No usar el buffer bajo ningún concepto.

Configuración de KODI v17

En la siguiente versión de Kodi, las etiquetas del archivo advancedsettings.xml quedarían de la siguiente forma:


<advancedsettings>
 <cache>
  <memorysize>104857600</memorysize>
  <readfactor>3</readfactor>
  <buffermode>0</buffermode>
 </cache>
</advancedsettings>

En esta versión cambia el parámetro cachemembuffersize por memorysize readbufferfactor por readfactor, siendo exactamente los mismo parámetros que antes, solo que mejor organizados y cambiados de la sección network a la sección cache.

En el siguiente artículo se verá cómo mejorar la velocidad de transferencia entre nuestro servidor y la raspberry mediante el cambio de sambaNFS y su posterior montaje en local. Aunque estará dedicado a servidores Linux, también se puede usar Windows como un servidor NFS con software de terceros.

Apagar la pantalla en servidores Debian

Antes de nada aclarar el título, ya que puede llevar a confusión. Este método vale para casi todas las distribuciones linux (digo casi todas porque tengo entendido que este método en ArchLinux no funciona bien del todo). Está orientado a servidores puesto que no nos interesa tener la pantalla encendida gastando energía tontamente.

La mayoría de métodos que he encontrado, aunque se introducen por consola, hace falta tener entorno gráfico o instalar aparte las utilidades X-Org. En el servidor (no vale por telnet ni por SSH) nos logueamos y escribimos:

setterm -blank 1
setterm -powersave on
setterm -powerdown 1

Si queremos guardar los cambios o no tenemos acceso a la consola física del servidor, mediante telnet, SSH o cualquier otro, editamos el archivo /etc/rc.local e introducimos justo antes de la línea que indica exit 0 los mismos comandos. El archivo quedaría de la siguiente manera, a no ser que hubiera otra modificación:

#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.
setterm -blank 1
setterm -powersave on
setterm -powerdown 1

exit 0