Usar una partición NTFS desde Mac OS X

Hace poco he tenido que pasar unos ficheros desde un mac mini a un disco duro externo con una partición NTFS. En Linux lo suelo hacer con FUSE y el driver NTFS-3G. FUSE (File-system in USErspace) permite implementar un sistema de ficheros, totalmente funcional, en el espacio de usuario. El driver NTFS-3G permite operaciones de lectura y escritura sobre un sistema de ficheros NTFS y es estable desde febrero de este año (después de doce de desarrollo).

Un empleado de Google, Amit Singh, ha creado MacFUSE, que unido al driver NTFS-3G hará posible que podamos usar ese tipo de particiones desde nuestro mac. Los pasos a seguir son los siguientes:

Descargamos MacFUSE y lo instalamos. Tienen una versión para Tiger y otra para Leopard.

Hacemos lo mismo con el driver NTFS-3G. Yo he descargado la opción Mac OS X Binary Package, que también es compatible con las versiones 10.4 y 10.5 de Mac OS X.

Si hemos conectado el disco duro externo deberíamos ver algo como lo siguiente:

rcmac:~ rafacas$ diskutil list
/dev/disk0
#:              type name               size      identifier
0:  GUID_partition_scheme               *74.5 GB  disk0
1:               EFI                    200.0 MB  disk0s1
2:         Apple_HFS Macintosh HD       74.1 GB   disk0s2
/dev/disk1
#:              type name               size      identifier
0: FDisk_partition_scheme               *74.5 GB  disk1
1:      Windows_NTFS NEWTEKS            74.5 GB   disk1s5

En mi caso, la partición NTFS es disk1s5. La desmontamos.

rcmac:~ rafacas$ diskutil unmount disk1s5
Volume disk1s5 unmounted

Creamos una carpeta, y en ella montamos la partición

rcmac:~ rafacas$ mkdir /Volumes/NTFS

rcmac:~ rafacas$ sudo /usr/local/bin/ntfs-3g /dev/disk1s5 /Volumes/NTFS/ \
-o pingarb,volname="NTFS"
kextload: /System/Library/Filesystems/fusefs.fs/Support/fusefs.kext loaded
successfully

Con esto ya tenemos montada la partición, lista para usarse.

Si la vamos a usar con cierta frecuencia, podemos crear un script con lo que hemos hecho antes. Llamaremos al fichero NTFS.sh:

#!/bin/bash
diskutil unmount disk1s5
mkdir /Volumes/NTFS
/usr/local/bin/ntfs-3g /dev/disk1s5 /Volumes/NTFS/ -o pingarb,volname="NTFS"

Le damos permisos de ejecución

chmod a+x NTFS.sh

Cada vez que queramos usarlo, ejecutaremos

./NTFS.sh

Si la vamos a usar siempre, lo único que tenemos que hacer es añadir el script al arranque.

Home, sweet home

Ah, otra cosa, lo que usted llama infierno, él lo llama hogar.

Coronel Trautmant (Rambo II)

Dual head en Linux

Hace poco he instalado GNU/Linux en el portátil de la empresa y una de las cosas que he tenido que configurar son los dos monitores que uso (normalmente se le llama dual head). Uno es el del portátil (con una resolución de 1280×800) y un TFT de 17” (de 1280×1024). La verdad es que nunca había necesitado hacer esto y por lo tanto no sabía si era fácil o difícil, lo único que me sonaba era que con Xinerama se conseguía.

Los primeros intentos con Xinerama no funcionaron. El problema era que la pantalla del portátil es panorámica (16:9) y la del TFT es normal (4:3) y ahí es donde se volvía loco. Podía usar resoluciones distintas pero con la misma relación de aspecto en los dos monitores, o bien 16:9 ó 4:3, pero nunca mezclarlas.

Buscando soluciones por Internet encontré XRandR, que es una librería que permite cambiar el tamaño y rotar la pantalla, y además funciona bien con las tarjetas de Intel, que es la que trae el portátil. El problema es que la versión estable de Xorg todavía no soporta las opciones que se necesitan, por lo que hay que instalar una versión beta. En mi caso, que uso Archlinux, se haría de la siguiente forma:

Primero hay que actualizar a las últimas versiones estables varios protocolos de las X.

# pacman -S xproto glproto inputproto

Luego, actualizaremos un par de paquetes, también relacionados con las X.

# pacman -S libxi libdrm

Instalamos la última versión de Xorg (actualmente, en los repositorios de Arch, está la versión 1.4)

# pacman -S testing/xorg-server

Una vez hecho esto deberíamos tener las X funcionando correctamente. Ahora nos falta instalar los nuevos drivers de intel (que actualmente corresponde a la versión 2.1.1)

# pacman -S testing/xf86-video-intel

Por último instalamos xrandr (versión 1.2.2)

# pacman -S testing/libxrandr

Si ejecutamos xrandr, con los dos monitores encendidos, obtenemos lo siguiente:

$ xrandr
Screen 0: minimum 320 x 200, current 2560 x 1024, maximum 2560 x 1024
VGA connected 1280x1024+1280+0 (normal left inverted right x axis y axis) 312mm x 234mm
1280x1024      64.9*
1152x864       75.0
1024x768       70.1     60.0
832x624        74.6
800x600        72.2     75.0     60.3     56.2
640x480        75.0     72.8     66.7     60.0
720x400        70.1
LVDS connected 1280x800+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
1280x800       60.2*+   85.0     75.0     70.0     60.0
1280x768       85.0     75.0     70.0     60.0
1280x720       85.0     75.0     70.0     60.0
1152x768       54.8
1024x768       85.0     75.0     70.1     60.0
832x624        74.6
800x600        85.1     72.2     75.0     60.3     56.2
640x480        85.0     72.8     75.0     59.9
720x400        85.0
640x400        85.1
640x350        85.1
TV disconnected (normal left inverted right x axis y axis)

Indica que el monitor TFT está conectado (VGA) y el del portátil también (LVDS). También indica los modos permitidos y cuáles tiene por defecto (los marcados con *).

Los cambios que hay que hacer en el fichero xorg.conf son muy sencillos, lo único que hay que añadir es el parámetro Virtual dentro de la subsección Display (perteneciente a la sección Screen). En mi caso, el fichero queda de la siguiente manera:

Identifier "Monitor"
Option "DPMS" "true"
HorizSync    28.0 - 96.0
VertRefresh  50.0 - 75.0
EndSection

Section "Device"
Identifier  "Intel card"
Driver      "intel"Section "Monitor"
Option      "XAANoOffscreenPixmaps"
VendorName  "Intel Corporation"
BoardName   "Intel Corporation Mobile 945GM/GMS/940GML"
EndSection

Section "Screen"
Identifier "Screen"
Device     "Intel card"
Monitor    "Monitor"
DefaultColorDepth 24
SubSection "Display"
  Depth     24
  Modes "1280x800" "1024x768" "800x600" "640x480"
  Virtual 2560 1024
EndSubSection
EndSection

En Virtual, lo que hay que especificar es el tamaño del escritorio real. En este caso, quería poner los monitores en horizontal, uno al lado del otro, por lo tanto sería 2560 de ancho (1280 + 1280) y de alto 1024. En caso de haberlos querido poner uno encima del otro la resolución a poner en Virtual sería 1280×1824.

Como hay veces que uso el portátil sin el segundo monitor, he creado un script que se ejecuta al iniciar KDE y que lo único que hace es comprobar si está conectado o no. En caso de estarlo configura las resoluciones y las posiciones de los dos monitores.

#!/bin/bash
if xrandr -q | grep -q  "VGA connected"; then
xrandr --output LVDS --mode 1280x800 --output VGA --mode 1280x1024 --right-of LVDS
else
xrandr --output VGA --off --output LVDS --mode 1280x800
fi

¡Quiero una de éstas! (II)

Vía Boing Boing llego a la tienda online Etsy, donde venden un jersey con un diseño del mítico juego Space Invaders, también conocido como marcianitos (al menos, por mi tierra).

Para los más jóvenes -esos que no perdieron mil horas con el Spectrum sino con la PS2-, decir que es un juego bastante simple: consistía en el manejo de un cañón que únicamente podía moverse a izquierda o derecha y que tenía como misión destruir a los alien que se aproximaban a la Tierra. Se contaba con 4 escudos de protección, tal y como se ve en el jersey. La verdad es que necesitábamos bastante poco para pasar las horas :D

Para los nostálgicos, dejo el enlace al juego en versión flash. ¡Ojo! puede hacerte perder gran parte de la tarde del domingo ;-)

El problema de Skype… ¿Windows?

La parada del servicio que ha tenido Skype el pasado día 16, y que duró aproximadamente 2 días, lo han justificado alegando que la mayoría de sus usuarios tuvieron que reiniciar sus ordenadores -y volver a registrarse en el servicio- en un intervalo de tiempo muy pequeño. Esto lo provocó la instalación casi simultánea de parches (el famoso Patch Tuesday) por medio de Windows Update, lo que colapsó los recursos de red de Skype y reveló un bug en uno de sus algoritmos de asignación de recursos.

En esta ocasión tengo que salir en defensa de Microsoft, ellos no han tenido la culpa. Si Skype no soporta que la mayoría de sus usuarios intenten autenticarse al mismo tiempo, tienen un problema (como ha quedado demostrado). Aún así, me pregunto por qué no les ha pasado antes si es ésa la razón, porque Windows Update no es del mes pasado y los Patch Tuesday tampoco. ¿Querían quitarse un poco de culpa? Aunque tampoco se la echan de forma explícita, ya que lo único que indican es que ha sido la causa que desencadenó el problema y que ya han localizado y arreglado el error (que es suyo, claro).

Por si alguien quiere conocer alternativas a Skype, existe Gizmo, que descubrí hace poco buscando clientes de mensajería instantánea para la Palm y me ha parecido bastante bueno. La idea es la misma, pero se basa en estándares abiertos (SIP). Además, permite tener junto a los contactos de Gizmo, los de AIM, MSN, Yahoo y Jabber (en breve los de iChat también). Y existen clientes para Windows, Linux y Mac (y para determinados móviles y PDA).

Actualización (23:40): Vía Enrique Dans llego a la explicación de la explicación que ha dado Skype. En ella aclaran todas las reacciones que se produjeron tras su primera explicación, y se pueden resumir en:

  1. Ellos no han echado la culpa a Microsoft por lo que ocurrió. Los parches de Microsoft Updates fueron un catalizador (y no la raíz) de una serie de eventos que llevaron a la interrupción del servicio.
  2. No existen diferencias entre el último conjunto de parches y los anteriores. También han comprobado que Microsoft no ha cambiado el proceso de actualización.
  3. La razón por la que actualizaciones anteriores de Windows Update no produjeron interrupciones es, precisamente, que éstas no son la causa del problema. Fué uno de los factores de una “tormenta perfecta”.
  4. Finalmente indican que el bug ha sido corregido.

¿Quién ha dicho que Windows es inseguro?

Vía Digg llego a una página de ayuda y soporte de Microsoft. El error afecta a los Windows 2000 que usan Kerberos como protocolo de autenticación de los usuarios del dominio. Se produce cuando se intenta cambiar la contraseña del usuario y el mensaje que muestra es el siguiente:

Your password must be at least 18770 characters and cannot repeat any of your previous 30689 passwords. Please type a different password. Type a password that meets these requirements in both text boxes.

Que traducido sería algo como:

La contraseña debe tener como mínimo 18770 caracteres y no puede usar ninguna de las 30689 contraseñas anteriores. Por favor, introduzca una contraseña diferente. Introduzca la contraseña que cumpla estos requisitos en los dos campos de texto.

En la página de Kerberos dicen que Kerberos es un protocolo de autenticación por red y está diseñado para proporcionar autenticación fuerte para aplicaciones cliente/servidor. Pues la implementación de Microsoft sí que es fuerte, sí. Aunque no sé que es más fuerte, si pedir una contraseña de 18770 caracteres, o pedir que no coincida con las 30689 anteriores :D

La nota que incluyen en la página de ayuda tampoco tiene desperdicio: Note that the number of required characters changes from 17,145 to 18,770 with the installation of SP1 (Tenga en cuenta que el número necesario de caracteres cambia de 17.145 a 18.770 con la instalación de SP1). ¡Perfecto! actualizas el sistema con el SP1 y te incrementan la contraseña en más de 1500 caracteres :D

En fin, que es una entrada tonta pero la pongo porque el error me ha sacado una sonrisa esta tarde. A continuación traduzco algunos de los comentarios de los usuarios de Digg que me han parecido bastante buenos.

Router "monopuesto"

Ayer estuve en las oficinas de un cliente y no pude evitar sacar una foto al router.

router

Tú no lo entiendes…

Tú no lo entiendes. Han matado a mi perro.

Bob Lee Swager (Shooter, 2007)

El goto es bello… ¿o no?

La tira del webcomic xkcd de hace unos días me pareció muy buena. Me recordó al debate que mantuvieron Edsger Dijkstra y Donald Knuth acerca de si era necesario o no.

La controversia se generó cuando Dijkstra envió un pequeño artículo al Communications of ACM, dedicado exclusivamente a la sentencia goto. El editor, a fin de publicarlo rápidamente, decidió publicar el artículo como una carta titulada “Go To Statement Considered Harmful” (Sentencia Go To Considerada Perjudicial). En ella Dijkstra argumenta que el uso del goto debería eliminarse en lenguajes de alto nivel (excepto en código máquina) ya que dificultan el análisis y la depuración de los programas. Por otro lado, Knuth en su artículo “Structured Programming with goto Statements” (Programación estructurada con sentencias goto), explica ciertas situaciones en las que conviene usar el goto. Éstas son situaciones en las que el lenguaje no dispone de una estructura específica y el goto puede simularla eficientemente, como por ejemplo, el tratamiento de excepciones.

Las frases que siempre he escuchado y que les atribuyen son, la afirmación de Dijstra:

“La programación es una ciencia y el goto es aberrante

Y la contestación de Knuth:

“La programación es un arte y el goto es bello

Supongo que estas afirmaciones son más bien una leyenda o mito, ya que nunca he conseguido ninguna referencia, pero creo que resume bastante bien la discusión que mantuvieron.

En la actualidad, con los lenguajes de programación que más se usan (Java, .NET) carece de sentido el uso del goto para el control de excepciones, ya que incluyen éstas y su tratamiento como parte del lenguaje.

Dejo a continuación la tira de xkcd y una traducción libre de la misma.

Viñeta 1: Podría reestructurar el flujo del programa – o usar un pequeño ‘goto’
Viñeta 2: Que le den a las buenas prácticas, total ¿qué va a pasar? – goto main_sub3; – *COMPILAR*

Con Kolivas abandona el kernel. ¿Se aleja Linux del escritorio?


Vía Barrapunto me entero que Con Kolivas, uno de los desarrolladores del kernel de Linux ha abandonado el desarrollo. Se dedicaba a la rama -ck (iniciales de su nombre) en la que agrupaba una gran cantidad de parches destinados a mejorar el rendimiento en el escritorio.

APCMag le ha realizado una entrevista y de las primeras cosas que comenta -y que me llamó bastante la atención- es que no es informático, es anestesista en un hospital de Melbourne y, evidentemente, el desarrollo de la rama -ck es un hobby. Según dice, aprendió C y terminó entendiéndolo después de tanto leer código del núcleo.

Una de sus principales motivaciones era mejorar los problemas de rendimiento de Linux en el escritorio, a pesar de darse cuenta que nadie programaba para eso. Como anécdota cuenta que después de enviar un informe de un bug relativo a la interactividad, uno de los desarrolladores le contestó que no había sido capaz de reproducir el error, ya que usaba un ordenador con 4 procesadores y 4GB de RAM.

Piensa que Linux ha triunfado en el mercado de servidores, pero los usuarios (de los ordenadores personales) han perdido. Echa la culpa en gran parte a que casi todos los desarrolladores trabajan para grandes empresas y éstas están más preocupadas de las pruebas de rendimiento de bases de datos, de carga, etc, que por el rendimiento del escritorio.

No entiende el porqué se ha avanzado tan lentamente en este campo si todos tenemos ordenadores que se consideraban supercomputadoras hace 10 años y 10 años antes teníamos las supercomputadoras de hace 20.

Entre las razones que le ha llevado a abandonar, está el ego de muchos de los desarrolladores, que les lleva a distanciarse de las necesidades del 99% de los usuarios. Pero en realidad, la gota que colmó el vaso fué el rechazo, tanto de Linus Torvalds -que no necesita presentación- como de Ingo Molnar -responsable del planificador-, de incluir el framework que había creado para el planificador de la CPU, que permitía elegir en el arranque cuál ejecutar (tenía pensado mejorarlo para que se pudiese hacer la elección en tiempo de ejecución). Esto permitiría tener varios planificadores y dependiendo para qué se use el ordenador (escritorio, servidor web, de bases de datos, etc) se ejecutaría el mejor para cada ocasión. La razón que le dieron para rechazar esta idea fué que los dos preferían un planificador genérico que fuese bueno en todos los casos. Yo me pregunto ¿eso realmente existe?

Después de leer el artículo, me he preguntado si realmente el escritorio en Linux va tan mal. Creo que tiene bastante razón, y entiendo su frustación, a la hora de asegurar que los desarrolladores están alejados de los usuarios. Pero es que veo normal que si la mayoría trabajan para IBM, HP, Red Hat, etc, las mejoras que hagan tengan que ver, sobre todo, con el rendimiento en los servidores. Supongo que se puede mejorar, y mucho, pero hoy en día con los dos grandes en el escritorio, como son KDE y GNOME, que uniéndolo a Compiz Fusion, por ejemplo, se puede tener un escritorio bastante bueno y no necesitar un ordenador muy potente.

Otra pregunta, ¿puede ser ésta una de las razones por las que no ha despegado aún lo de los juegos en Linux? Creo que no, todavía no es tan generalizado el uso de Linux como para que los usuarios empiecen a reclamar juegos para este sistema operativo. Aunque, en cuanto al número de usuarios, leí hace poco un artículo en el que Mark Shuttleworth, fundador de Ubuntu, habla sobre el éxito de esa distribución y que en la actualidad tiene entre 6 y 12 millones de usuarios (un rango un poco amplio, ¿no?). También hay una entrada en Kriptópolis en la que se plantean cómo se podría saber el número de usuarios de Linux que existen en la actualidad, ya que no hay muchos datos fiables al respecto. Aún habiéndose incrementado bastante, creo que todavía no tiene el número suficiente para que esas quejas se escuchen. En este sentido Loki Games está haciendo un buen trabajo portando bastantes juegos a Linux.

Mientras escribía esta entrada he llegado, vía Slashdot, a esta otra de Kernel Trap. Comentan las razones que ha dado Linus para elegir el planificador de processos de Ingo, CFS, frente al de Con, SD. Vienen una serie de correos de Linus en los que explica y contesta a usuarios que creen mejor el planificador SD. Artículo interesante para tener los puntos de vista de las dos personas que han generado este debate.

Actualización (08/08/07): Como muy bien me indica David en un comentario, Loki Games cerró hace bastante tiempo, en concreto, en enero de 2002.



CC Homo cybersapiens ¡Gracias por la visita!