El experimento de Leopard no duró demasiado. El rendimiento gráfico era algo malo. Exposè se ralentizaba por momentos, tal vez porque mi 8600GT no es de las mejor soportadas por NVinject, al contrario de la serie 7000 de nvidia, con las que lo he visto funcionando de maravilla.
Así que he vuelto a mi Gentoo Linux como SO de escritorio, y comparando el rendimiento con mi Athlon64 x2 3800+, el E8500 se lo come con patatas. Por poner un ejemplo, glibc se compila en 33 minutos en el 3800, contra los 12 minutos del E8500. Supongo que el cambio será más espectacular cuando Gentoo pase a gcc 4.3, capaz de utilizar SSSE3 y SSE4.1.
Por otro lado, en el aspecto gráfico he mejorado muchísimo, el rendimiento OpenGL de la 8600GT es 15 veces mejor que el de la 6600 LE, y pensar que pagué menos por la 8600GT de lo que pagué en su momento por la 6600…
Ya tengo funcionado mi equipo nuevo, no está ni en Windows ni en Linux, me he decidido a montarme un Hackintosh con Leopard. El hardware usado ha sido el siguiente:
- Placa base: Gigabyte GA-P35-DS35
- CPU: Intel Core 2 Duo E8500 (3.16Ghz)
- RAM: 4Gb DDR2-800 Kingston
- T. Gráfica: Geforce 8600GT 256Mb DDR3
La instalación fue un poco problemática, probé con 2 versiones de osx86, iATKOS y Kalyway. Al final me he quedado con Kalyway, aunque solo sea por facilitarme la vida a la hora de elegir el tipo de bootloader y hacer arrancable la partición de Leopard.De primeras, solo funcionaba la ethernet, el sonido no iba y la gráfica no pasaba de 1024×768. Para solucionar lo de la gráfica tuve que instalar el framework de OpenGL 10.5.2, y después ya pude instalar NVinject 256Mb sin problemas.El sonido fue más sencillo, simplemente localicé el kext para el ALC889, lo instalé y a funcionar sin problemas.Una vez que tuve el hardware funcionando, actualicé a 10.5.2, otra vez volví a elegir kalyway, su update a 10.5.2, tanto el comboUpdate como el kernel funcionaron a la primera.El rendimiento es más que aceptable, no me he encontrado demasiados problemas de estabilidad, y como veis en la captura, Geekbench 2 puntua al sistema con 4330 puntos, que si se compara con otros macs, supera a un Mac Pro con 2 Xeons a 2.66Ghz, creo que no está nada mal
![]()
Hoy fui a instalar y poner en marcha un servidor de ficheros (4Tb online en RAID-5). Después de 1 semana de pruebas en la oficina y sin un solo fallo parecía estar todo correcto.
Conecto todo, me acuerdo de la familia del electricista que dejó todos los RJ-45 hembra sin conectar, y cuando comenzamos a volcar datos al servidor de ficheros, uno de los discos falla, se escucha el tipico ruido de cabezales tocando con el plato…
Murphy me estaba esperando en la oficina del cliente
Se me ocurrió montar una VPN IPSec/L2TP usando openswan + xl2tpd + pppd para poder acceder a la red de casa de forma segura. Cuando la tengo funcionando me doy cuenta de que tengo abierto el puerto 1701 (l2tp) para cualquier cosa que venga desde el dispositivo de internet, y como estoy usando netkey no tengo dispositivos ipsecX que me permitan diferenciar de forma trivial el tráfico que viene en tuneles IPSec del resto del tráfico entrante desde internet. Buscando por ahi y después de diversas pruebas encontré mi solución en el módulo policy de netfilter:
iptables -A INPUT -m policy --pol ipsec --dir in -p tcp --dport 1701 -j ACCEPT
iptables -A INPUT -m policy --pol ipsec --dir in -p udp --dport 1701 -j ACCEPT
Especificamos que aceptamos el tráfico TCP/UDP entrante en el puerto 1701 para tráfico IPSec entrante, evitando así el aceptar paquetes con destino al l2tpd desde orígenes dudosos.
VMware y el kernel 2.6.21 se llevan mal, muy mal. Casi todo el día perdido con cuelgues intentando montar unas 2003, que si comprobando que tuviese bien el disco duro, la RAM…
Para acabar descubriendo que hay algún tipo de problema entre VMware & 2.6.21, ha sido bajar la versión del kernel a 2.6.20 y dejar de tener problemas.
Actualmente en el despacho tenemos 2 equipos en los que interesa reproducir audio y sólo 1 par de altavoces conectados a un equipo. Había 2 opciones o bien comprar un selector de señales de audio y conmutar entre un equipo y el otro o bien compartir los altavoces/tarjeta de sonido.
Como en tiempos había conseguido hacer que un xmms mandase la salida de audio a un esound remoto decidí probar por el camino de compartir altavoces.
Resulta que esound actualmente está viejo/desfasado/deprecated/oxidado, buscando un poco encontré en Pulseaudio la solución perfecta. Pulseaudio es un servidor de audio con soporte de red, con la ventaja de estar soportado por el propio ALSA, con lo cual no sólo ciertas aplicaciones se escucharán en los altavoces remotos, si no que todo lo que soporte ALSA ó OSS (ALSA nos ayuda a emular OSS) podrá ser escuchado en nuestros altavoces compartidos.
Manos a la obra, en el equipo que posee los altavoces y tarjeta de sonido deberemos de tener el demonio de Pulseaudio funcionando y admitiendo conexiones via TCP/IP. En mis gentoo es algo así:
- emerge pulseaudio (con USE=”alsa” como mínimo para que pueda mandar el audio a la tarjetea de sonido, que en mi caso lo tengo definido en /etc/make.conf)
- editamos /etc/pulse/default.pa y descomentamos la siguiente línea para que la salida de Pulseaudio sea el ALSA del equipo que tiene la tarjeta de sonido funcionando:
- load-module module-alsa-sink
- en el mismo /etc/pulse/default.pa añadimos las siguientes líneas para admitir conexiones entrantes desde localhost y la red local (192.168.0.0/24 en mi caso):
- load-module module-native-protocol-tcp auth-ip-acl=127.0.0.1;192.168.0.0/24
- load-module module-esound-protocol-tcp auth-ip-acl=127.0.0.1;192.168.0.0/24
- Arrancamos pulseaudio: /etc/init.d/pulseaudio start
En los equipos cliente deberemos de hacer lo siguiente:
- Añadimos pulseaudio al USE del /etc/make.conf e instalamos pulseaudio, xine-lib (si ya está instalado la reinstalamos para que vaya con soporte de pulseaudio) y alsa-plugins: emerge pulseaudio xine-lib
- Editamos /etc/pulse/client.conf y añadimos la siguiente línea para que el pulseaudio de los clientes mande el audio al pulseaudio que si tiene tarjeta de sonido como salida (multivac en mi caso):
- default-server = multivac
- Configuramos ALSA para que utilice pulseaudio por defecto añadiendo las siguientes líneas a /etc/asound.conf:
- pcm.pulse { type pulse }
- ctl.pulse { type pulse }
- pcm.!default { type pulse }
- ctl.!default { type pulse }
Una vez hecho esto he comprobado que el amarok ejecutado en los clientes, que usa xine-lib, usa pulseaudio tanto si elegimos como salida ALSA o Pulseaudio, así que teoricamente cualquier cosa que sea capaz de usar ALSA la escucharemos en el equipo con salida de altavoces
He afinado más el proceso de conversión de xvid a wmv para poder reproducir en la 360. Además ya he conseguido incrustar subtítulos en el video.
Para evitarme problemas y pérdidas de calidad, he optado por hacer la conversión de xvid a wmv con ffmpeg, con el siguiente comando: ffmpeg -i entrada.avi -vcodec wmv2 -acodec wmav2 -sameq salida.wmv. No especifico ningún bitrate, ya que de ello se encarga la opción -sameq (same quality), el único inconveniente es que para mantener la calidad el tamaño a veces llega a duplicarse, aunque con un poco de suerte, con el upgrade de dashboard de la semana del 7 mayo nos evitaremos la conversión a wmv, ya que soportará xvid. Queda por ver si soportará audio en mp3 y container AVI, si no lo hace, solo tendremos que cambiar el container y el audio, pero podremos dejar el video intacto.
Para incrustar los subtítulos he optado por usar mencoder y dejarlo en xvid, así que para primero le incrusto los subtítulos y después lo convierto a wmv. El comando es el siguiente: mencoder entrada.avi -ovc lavc -lavcopts vcodec=mpeg4:vbitrate=1000:vhq -oac copy -fontconfig -font ‘Bitstream Vera Sans’ -sub subtitulos.srt -subfont-text-scale 3.0 -o salida.avi. He probado con Numb3rs S03 y no he tenido ningún problema, sin embargo con Scrubs S06, los subtítulos en la tele se me iban por debajo de la pantalla, así que tendré que jugar con los parámetros que permiten manipular la posición de los subtítulos.
Al migrar mis sistemas a UTF-8 me encontré con un grave problema en el bitlbee.. todos los acentos que usaba los veían mal en el cliente de Microsoft, pues bien, he aquí la solución:
set charset utf-8
Lo sé… resulta evidente, pero en parte por pereza ni siquiera lo había mirado, y fue Sevein quien me dio la solución, thx.
Hace poco me hice con una xbox360 con el objetivo de jubilar a mi xbox y al PC que tenía en el salón. La parte de hacer que la nueva consola funcionase con copias de seguridad fue bastante sencilla, basta con seguir las instrucciones en cualquiera de los sitios dedicados al tema.
En cuanto a ver xvid/divx en la 360 la cosa se pone un poco más complicada. La 360 puede reproducir video si, siempre que sea video WMV2, audio WMAV2 y container ASF. Así que hay 2 opciones, o empiezas a convertir lo que quieras ver a ese formato, o bien buscas una forma de hacer la conversión en tiempo real (al mismo tiempo que lo vas viendo).
Primero probé con la conversión en tiempo real, la forma de hacerlo es montando unas Windows XP Media Center 2005 y después montarle algun plugin al media center como Transcode360 o VLC360. En mi caso, como no iba a eliminar linux de mi equipo, decidí probar dentro de un VMWare Server, y si bien pude llegar a comprobar que funcionaban ambas soluciones, el resultado no era el esperado. El rendimiento dejaba bastante que desear, iba a tirones (mi equipo es un Athlon64 x2 3800+ con 2Gb de RAM y le había asignado 512Mb de RAM a la máquina virtual con Media Center).
Viendo que iba a tener que convertir lo que quisiese ver, quería hacerlo de la forma más rapida, así que tenía que ser en linux y a 64 bits, nada de chroots guarros de 32 bits para hacer funcionar win32codecs y cosas del estilo.
Revisando la página de FFMPEG pude comprobar que la versión disponible en el SVN a partir del 09/03/2007 podía codificar de forma nativa WMAV2 (el codec de audio que soporta la 360) y WMV2. Mi primer intento fue algo así: ffmpeg -i input.avi -vcodec wmv2 -acodec wmav2 test.wmv. El resultado fue un fichero de .wmv en una pésima calidad (por no especificar bitrate) pero que se veía sin problemas en mi 360.
Pero no podía quedarme con ffmpeg, ya que no soporta subtítulos, y como me he enganchado a series en inglés subtituladas, no es una opción aceptable ;). Así que recurrí a mi amigo mencoder, la pareja del reproductor mplayer. Mencoder se puede apoyar en FFMPEG y en su libavcodec para codificar videos y soporta subtítulos. Después de digerirme el man de mencoder hice la siguiente prueba: mencoder input.avi -o test.wmv -ovc lavc -lavcopts vcodec=wmv2:vbitrate=900 -oac lavc -lavcopts acodec=wmav2:abitrate=128. Cual es mi sorpresa cuando intento reproducirlo en la 360 y me dice que el formato no es válido. Usando midentify veo el problema, los codecs están bien, pero el container es un AVI en vez de un ASF. Revisando (otra vez) la documentación encontré la solución: mencoder input.avi -o test.wmv -of lavf -lavfopts format=asf:i_certify_that_my_video_stream_does_not_use_b_frames -ovc lavc -lavcopts vcodec=wmv2:vbitrate=900 -oac lavc -lavcopts acodec=wmav2:abitrate=128. Los ficheros producidos a partir de este comando son reproducibles sin problemas en la xbox 360.
La ventaja de poder usar mencoder y no ffmpeg es que podemos aplicar filtros, hacer que mencoder renderize los subtítulos en el video…





