Portátiles interesantes, 2017

Todos los modelos tienen 8 GB de RAM, pantalla de 15″ y tarjeta GTX 1050 4GB (salvo que se indique lo contrario)

  • MSI GL62M 7REX-1603XES: i5-7300HQ, 15.6″ IPS FullHD, 1 TB HDD, HDMI, no OS, 1.5 Kg. 850 EUR.
  • Dell Inspiron 15 7000 Gaming: i5, HD IPS, 1TB SATA, HDMI, Thunderbolt, Ethernet, ampliable, Win10, 3Kg. 900 EUR
  • Lenovo Y520-15IKBN: i7, 15.6″ FullHD, 1 TB HDD, HDMI, no OS, 2.4 Kg. 900 EUR.
  • Lenovo T470: i3, 4GB, intel 620, WXGA TN, 500GB SATA, HDMI, Thunderbolt, Ethernet, Win10, 2Kg. 960 EUR
  • Acer Aspire VX5-591G-73FR: i7 , 15.6″ Full-HD, 128GB SSD+1TB, Win10, 1.8 Kg. 970 EUR
  • ASUS GL553VD-DM078T: i7-7700HQ , 15.6″ Full-HD, 1 TB HDD, Win10. 1000 EUR
  • MSI GL62M 7REX-1601XES: i7-7700HQ, GTX 1050 Ti 4GB, 15.6″ IPS FullHD, 256GB SSD+1 TB HDD, HDMI, no OS, 2.2 Kg. 1050 EUR.
  • ASUS Zenbook UX550VD-BN032T: i7 , 15.6″ Full-HD, 256GB SSD, Win10, 1.8 Kg. 1300 EUR
  • Dell Inspiron 15 7000 Gaming: i7, 16GB, GTX 1060 6GB, HD IPS, 256GB SSD + 1TB SATA, HDMI, Thunderbolt, Ethernet, Win10, 3Kg. 1400 EUR
  • Dell XPS 15: i5, HD IPS, 256GB SSD, HDMI, Thunderbolt(Ethernet), Win10, 2Kg. 1500 EUR

Windows 10: home (100 EUR), professional (135 EUR).

(precios IVA incluido)

Thinkpad X62

SSL Reverse proxy con Apache

Un ejemplo que sirve para Meteor:


SSLProxyEngine On
# snake oil certs in proxyied service -> skip checks
SSLProxyVerify none
SSLProxyCheckPeerCN off
SSLProxyCheckPeerName off

ProxyRequests Off
ProxyPreserveHost On

ProxyPass /websocket ws://localhost:3000/websocket
ProxyPassMatch ^/sockjs/(.*)/websocket ws://localhost:3000/sockjs/$1/websocket

ProxyPass / http://localhost:3000/
ProxyPassReverse / http://localhost:3000/
ProxyPassReverseCookiePath / /
ProxyPassReverseCookieDomain 127.0.0.1 52.211.154.50
RequestHeader set X-Forwarded-Proto "https"

Parece que en nginx la configuración análoga es trivial. Quizá sea un buen argumento para convertirse…

Secure cookies over reverse proxy with https

Discos virtuales en Xen Server

Con el comando vhd-util podemos obtener un listado de los VDI/VHD de un Storage Repository (SR) de Xen Server:

vhd-util scan -f -a -c -m “VHD-*” -l nombre_VG

(el nombre del vg de Xen lo podemos averiguar con vgs. Normalmente empieza con VG_XenStorage)

vhd-util scan muestra una jerarquía de VHD, con su tamaño virtual y real. Esto es útil para hacer un seguimiento de los snapshots. Cada VHD es un volumen lógico en el VG, con lo cual a partir del identificador de VHD podemos obtener información adicional (por ejemplo, cuando se creó) buscándolo en la salida del comando lvdisplay

Para averiguar a qué VM corresponde un VDI…

xe vbd-list vdi-uuid=UUID

(el UUID es el que aparece en vhd-util scan, pero sin VHD-)

Otro comando para obtener información sobre los VDI es

xe vdi-list

Para empezar es cómodo, pero sólo muestra el tamaño virtual del disco.

Lista de instantáneas:

xe snapshot-list

Desde el interfaz de Xen Server es fácil eliminar un snapshot. Generalmente, en el interfaz desaparece al instante, pero en función de las dependencias en la cadena de snapshots puede tardar un rato en eliminarse del almacenamiento (cada vez que se elimina un snapshot, por detrás se lleva a cabo un “online coalescencing”). Se puede hacer un seguimiento más detallado del proceso en el log de Xen Server /var/log/SMlog

Repartir espacio disco NVME entre Windows y Linux

Arrancar Linux desde pendrive (por ejemplo, Ubuntu live)

Gparted. Reducir tamaño partición Windows. Mover comienzo partición Linux (para aprovechar el espacio liberado). Al cambiar el sector de inicio de la partición de sistema de Linux, puede ser que Grub no sea capaz de arrancar Linux. Con lo cual lo más simple es volver a reinstalar grub.

En Gparted podemos ver los nombres de dispositivo del disco nvme. Normalmente, el disco se denomina nvme0n1, y las particiones nvme0n1p1, p2…

Reinstalar Grub:

Montar sistema de ficheros raíz de Linux en /mnt/os
bind-mount sistemas de ficheros dev, proc, sys en /mnt/os
chroot /mnt/os
mount /boot/efi
grub-install /dev/nvme0n1

OpenGL en remoto (ssh) y Nvidia

Para el rendering OpenGL en un ordenador remoto se recurre (por defecto) a “indirect rendering” (los comandos Open GL pasan por el protocolo GLX). El “direct rendering” permite acceder directamente a la GPU del ordenador donde se ejecuta la aplicación. Este es el modo que usa por defecto el controlador nativo de Nvidia, que de hecho por defecto rechaza el uso del “indirect rendering” (se puede rehabilitar con la opción “AllowIndirectGLX” de la sección “ServerFlags” de xorg.con).

Así pues, ejecutando la instalación por defecto del driver nativo de Nvidia, se sustituye la biblioteca del sistema libGL. Con lo cual, se pierde el “indirect rendering” y las aplicaciones OpenGL dejan de funcionar en remoto (X11 sobre SSH)

Por otro lado, la biblioteca libGL que Nvidia instala puede ser necesaria para otras aplicaciones (por ejemplo, CUDA)

Una posibilidad es rescatar la biblioteca libGL original (del paquete libgl1-mesa-glx, o equivalente) y recurrir a ella para uso remoto, anteponiendo LD_PRELOAD=/ruta/a/libGLoriginal.so al programa a utilizar.

Si MESA recurre a swrast_dri.so para hacer el rendering (render por software), es probable que haya conflictos con bibliotecas como libstdc++.so.6 o libgcc_s.so (como suele suceder con UCSF Chimera, que tiene sus propias copias de esas bibliotecas en su directorio lib). En este caso se puede usar el mismo “truco” de LD_PRELOAD, pero con esas bibliotecas:

LD_PRELOAD=/usr/lib/gcc/x86_64-linux-gnu/4.9/libgcc_s.so:/usr/lib/x86_64-linux-gnu/libstdc++.so.6 chimera