Categoria: Software

He detectado que aquellas instalaciones de Starcraft 2 sobre Wine que intentan actualizar al parche 1.0.3 (de hoy mismo), se pegan un golpetazo y no hay manera de hacerlas seguir.

La forma de solucionarlo es sencilla:

Cuando esté descargando y aparezca la ventana de Wine que dice que hay un problema, cierrala y, sin cerrar el lanzador de SC2, abre un terminal y escribe:

$ ps -ef | grep Blizz

Debería aparecerte una linea parecida a esta:

10001 14769 14591 2 20:26 ? 00:00:01 [BlizzardDownloa] "defunct"

Pues bien, sólo mata el proceso hijo (el de la izquierda, el otro no) y vuelve a la ventana del lanzador de SC2:

$kill -9 14769

Si no se reanuda la descarga, repite el proceso las veces que sea necesario. Al final descargaras el paquete completo y continuará con la instalación.

El nuevo servidor de PQMC, Galactus, ya está casi listo para entrar a dar servicio, y sustituir a nuestro vetusto y machacado Cosmicgirl, que dejará las calles para dar algún otro servicio.

Galactus es técnicamente mucho más avanzado y en teoría más potente, gracias a su Intel Xeon de doble núcleo y 3.0 Ghz. Pero en la práctica, ¿cuán potente puede llegar a ser?

Por ello estos realizando una serie de tests de carga. Como la labor principal de Galactus es servir web en PHP y albergar bases de datos MySQL, he utilizado una herramienta incluida con el paquete de apache para calcular, de una manera más o menos precisa, la carga que puede soportar un servidor web: el comando ab.

ApacheBench es una utilidad que, sencillamente, realiza peticiones a un servidor Apache y genera unas estadísticas: tiempo de respuesta, peticiones admitidas, rechazadas, errores, tasa de transferencia máxima, etc. No es la gran herramienta pero como veremos nos será muy útil para darnos una idea de la capacidad de nuestro servidor web.

Hay que tener en cuenta que AB no puede realizar peticiones hacia si mismo, esto es, para testear un servidor A, es necesario instalar AB en una máquina B, y desde ahí lanzarlo. Lo único que hace falta, como dijimos, es el paquete de apache.

Para instalarlo, en Mandriva:

$ su
# urpmi apache2

Y en Debian:

$ su
# apt-get install apache2

Una vez lo tengamos instalado en la máquina que realizará las peticiones, es tan simple como lanzar el comando hacia la otra máquina:

# ab -n [peticiones] -c [concurrentes] [URL]

Donde [peticiones] es la cantidad de peticiones totales que se harán al servidor, [concurrentes] la cantidad de peticiones simultáneas que se harán cada vez, y [URL] es la dirección a la que se van a hacer las peticiones, de la forma:

http://dominio/uri

o

http://IP/uri

Sobre esto, hay que hacer algunas consideraciones:

1. [peticiones] no debe ser un valor muy alto. Todas las páginas web tienen un máximo de peticiones que pueden admitir desde un mismo host, pasado el cual rechazarán conexionespor considerarlo un riesgo de seguridad. Del mismo modo, un servidor que esté ocupado sirviendo el máximo de peticiones soportado, no admitirá más peticiones en cola hasta haber liberado espacio en la misma. Experimenta con este parámetro para ver hasta donde llega tu servidor.
2. [concurrentes] tampoco debería ser demasiado alto. Del mismo modo que antes, los servidores web están preparados para soportar un número máximo de peticiones simultáneas. Si éste se supera antes de haber concluido con las que se le han encargado, cortará la conexión. Este es un valor que nos dará una buena idea de la capacidad de nuestro servidor.
3. Es importante considerar que página es la que vamos a testear. Una página dinámica en PHP o JSP genera mayor carga que un HTML plano, por lo que los resultados variarán. Para una prueba de carga total, lo suyo sería emplear una URL que incluyera servicio de HTML, ejecución de scripts (PHP, Perl, Python, Java) y acceso a DB (Oracle, MySQL, SQLServer, Sybase). Esto nos dará una idea más clara de la capacidad del servidor en un momento de trabajo clave.

ADVERTENCIA-YA-TE-LO-DIJE: Efectivamente AB se dirije hacia URLs, por lo que puedes lanzarlo hacia cualquier servidor web que tengas al alcance de tu red, incluso de Internet. Pero ya te aviso que lanzar un mega-comando hacia una web con el objetivo de tumbarla no sólo no será efectivo, sino facilmente trazable y constitutivo de delito, por considerarse un ataque de tipo DoS (Denial of Service), bastante cutre además. No quieras acabar con tu trasero en el talego por una tontería como esta, cacho de lamer.

Aclarados estos campos veamos el resultado de la ejecución de AB sobre el viejo Cosmicgirl:

galactus:~# ab -n 10000 -c 100 http://cosmicgirl/phpmyadmin
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking cosmicgirl (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
Completed 7000 requests
Completed 8000 requests
Completed 9000 requests
Completed 10000 requests
Finished 10000 requests


Server Software: Apache/2.2.9
Server Hostname: cosmicgirl
Server Port: 80

Document Path: /phpmyadmin
Document Length: 342 bytes

Concurrency Level: 100
Time taken for tests: 7.320 seconds
Complete requests: 10000
Failed requests: 0
Write errors: 0
Non-2xx responses: 10000
Total transferred: 6260000 bytes
HTML transferred: 3420000 bytes
Requests per second: 1366.10 [#/sec] (mean)
Time per request: 73.201 [ms] (mean)
Time per request: 0.732 [ms] (mean, across all concurrent requests)
Transfer rate: 835.13 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.3 0 4
Processing: 3 73 27.1 69 2165
Waiting: 3 72 26.6 69 2165
Total: 7 73 27.1 69 2165

Percentage of the requests served within a certain time (ms)
50% 69
66% 69
75% 70
80% 71
90% 87
95% 103
98% 120
99% 132
100% 2165 (longest request)

Como vemos se ha zampado 10000 conexiones en tandas de 100 con una velocidad de respuesta aceptable. Cabe decir que cantidades mayores tanto de número de conexiones como de concurrentes han hecho perder la conexión. Los tiempos de respuesta tampoco han estado mal, y no ha dado errores significativos.

Veamos ahora los resultados del test realizado a Galactus:

cosmicgirl:~# ab -n 100000 -c 100 http://10.1.10.110/phpmyadmin
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 10.1.10.110 (be patient)
Completed 10000 requests
Completed 20000 requests
Completed 30000 requests
Completed 40000 requests
Completed 50000 requests
Completed 60000 requests
Completed 70000 requests
Completed 80000 requests
Completed 90000 requests
Completed 100000 requests
Finished 100000 requests


Server Software: Apache/2.2.9
Server Hostname: 10.1.10.110
Server Port: 80

Document Path: /phpmyadmin
Document Length: 410 bytes

Concurrency Level: 100
Time taken for tests: 18.355 seconds
Complete requests: 100000
Failed requests: 0
Write errors: 0
Non-2xx responses: 100001
Total transferred: 75800758 bytes
HTML transferred: 41000410 bytes
Requests per second: 5448.16 [#/sec] (mean)
Time per request: 18.355 [ms] (mean)
Time per request: 0.184 [ms] (mean, across all concurrent requests)
Transfer rate: 4032.96 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 1 0.9 0 8
Processing: 0 18 45.1 5 997
Waiting: 0 6 10.9 5 865
Total: 1 18 45.1 6 998
WARNING: The median and mean for the initial connection time are not within a normal deviation
These results are probably not that reliable.

Percentage of the requests served within a certain time (ms)
50% 6
66% 9
75% 10
80% 12
90% 16
95% 136
98% 198
99% 220
100% 998 (longest request)

¡Que burro! Apenas ha tardado el doble de tiempo en resolver diez veces más número de peticiones de la misma página. Ha resuelto cerca de 5500 peticiones por segundo y ha transmitido casi 5 Mb de datos en ese tiempo. Por no hablar de que la petición más lenta se ha resuelto en menos de 1 segundo. Y todo sin errores y sin clausular la conexión. Ha gestionado 10 veces más trabajo en casi la mitad de tiempo, de lo que extraemos que ha llegado a ser 5 veces más rápido.

Cabe hacerse notar que un seguimiento a nivel de máquina nos indica que, en el momento de hacer estos tests, Galactus estaba al 45% de CPU y el 82% de uso de RAM (de un total de 1Gb), mientras que Cosmicgirl estaba al 100% de CPU y al 98% de uso de RAM (de 2Gb). Por otra parte, ambos Apaches están configurados por defecto para abrir sólo 100 hilos concurrentes, por lo que el límite se queda establecido así.

De lo que se puede desprender que, mientras que Cosmicgirl hace lo que puede el pobre, Galactus aún puede dar de si mucho más de lo que le pedimos. Nos sobra servidor, lo se. Pero así somos en LGDAI: sobrados.

Para aquellos que sigan pensando que el año que viene se acaba el mundo porque lo dijeron los mayas, que sepan que están equivocados. No muy lejos queda el fin del mundo, pero no será hasta el 2038 que se irá todo a la porra.

¿Y porqué se irá a la porra? Porque la gran mayoría de nuestros sistemas informáticos no está diseñado para generar una fecha superior al 19 de Febrero de 2038.

Bueno, el mundo no se acabará (esperemos), pero el problema en si es real y se están buscando soluciones.

¿Y porqué se acaba el mundo? Sencillamente, por una limitación de diseño en los sistemas basados en POSIX, en los cuales el tiempo se va midiendo en forma de un número decimal, encarnado por el número de segundos transcurridos desde el 1 de Enero de 1970 hasta ahora.

El problema es que ese número decimál, de tipo Integer, es de 32 bits. Y las fechas superiores a la indicada arriba desbordan la capacidad de este tipo de números, con lo que los sistemas, que son muy cucos, convierten dicho número en negativo. En la práctica volvemos a 1970.

Si con esto no te enteras de ná, este gráfico de la Wikipedia es muy explícito:

En el se puede comprobar como efectivamente a partir de 19 de Enero de 2038 el número entero que define el tiempo transcurrido se vuelve negativo, se resetea a si mismo. Es algo parecido a lo que sucedió con el famoso Efecto 2000, salvo que en aquel caso el problema erá también de hardware. En este caso, el hardware no tiene problema.

¿Y como vamos a evitar que una cosa tan tonta no nos arruine? Pues sencillamente, desarrollando e implantando los sistemas de 64 bits. En realidad todos los que hayáis adquirido un PC en los útlimos 2 o 3 años no tendréis este problema mientras instaléis un Sistema Operativo de 64 bits. El verdadero problema está en las grandes infraestructuras bancarias, militares, científicas, corporativas, etc. cuya tecnología se remonta al amanecer de los tiempos y que no queda más que migrar, en casos mediante inversiones millonarias.

Y si no, ya vendrá John Titor a salvarnos.

Referencias:

• Pagina web del problema del año 2038.
• FAQ’s del Efecto 2038
• John Titor, el viajero que vino del futuro para solucionar el problema del Y2k38 en su tiempo.

Pues sencillamente por esto:

¿Fichero corrupto? ¡No toques nada todavía!

Si uno tiene que manejar cadenas de comandos muy largas, comandos con muchísimas opciones, o es aficionado al &&, se puede encontrar con que un día, no puede editar un script porque se encuentra con una pantalla como la anterior. ¿Pero que significa esto? ¿Acaso el fichero de texto se ha corrompido? Y sobre todo, ¿por qué more me muestra la información del fichero correctamente?

La respuesta es que el viejo Vi sólo puede manejar líneas de fichero con una longitud máxima de 2048 caracteres (espacios incluidos). En el momento en que la línea sea màs larga os mostrará una pantalla como la que véis y un bonito mensaje como el que aparece en la última línea.

Por eso Vim y no Vi. Porque Vi como tal apenas ha sufrido cambias en sus ultimas versiones, mientras que Vim y otros clones han aumentado sus capacidades para ofrecer el manejo de líneas y ficheros más grandes, así como por ejemplo, sintaxis resaltada. Que es bien útil.

Que sea nuevo no significa que sea mejor. Que sea improved sí.

-Sobre Vim -> http://www.vim.org/

Finalmente Google ha presentado su apuesta final en pos de la dominación mundial:

Google TV propone la fusión entre la web y el televisor

Por fin la era digital ha llegado hasta donde querían: Fundir Internet y TV para adocenarnos definitivamente.

Leer mas... »

Yo creo que no es la primera vez que os lo digo, ceporrines. Pero seguis metiendo la gamba igual.

El formato de los ficheros de texto en Windows y Unix/Linux es diferente. Los ficheros de unix se ven mal en windows y viceversa. Esto en principio parece un problema de presentación, pero a la hora de ejecutar scripts es la diferencia entre la vida y la muerte.

Especialmente puñetero es el problema de los saltos de linea (line feed , LF) y los retornos de carro (chariot return, CR). No os voy a contar el rollo de que esto viene de las máquinas de escribir porque os lo cuenta muy bien la wikipedia.

Los sistemas unix-like (incluidos toooodos los Linux) emplean un solo carácter para indicar el final de línea, el carácter LF (decimal 10, hexadecimal 0A), mientras que los sistemas Windows emplean los el conjunto de dos caracteres, CR (decimal 13, hexadecimal 0D) y LF, o sea, CRLF.

Dado que esta marcación es empleada como separador de instrucciones en los lenguajes de scripting (cada nueva línea representa una línea de instrucción y separa, por ejemplo, líneas de comando), si creamos un fichero en un sistema y lo ejecutamos en el otro sin adaptarlo, no funcionará. Este problema es bastante habitual cuando se crea un script en una estación Windows y se sube a un servidor Unix/Linux.

Leer mas... »

Por mucho que Willy Toledo sea un paladin, protector de la luz, y todas esas gilipolleces, Mr. T y Ozzy Osbourne me han convencido finalmente. El futuro está en la Horda.

Pues si, después de mucho tiempo de abstinencia me ha empezado a dar por las drogas duras y me he metido de lleno en World of Warcraft. Eso si, quien espere encontrarme en un servidor oficial, lo lleva claro (12 pavazos por mes, titis!!).

Y es que hacer correr WoW sobre linux es tan sencillo que casi ni merece la pena hacer un manual. De hecho no lo voy a hacer, solamente voy a describir los pasos que hay que seguir para disponer de horas y horas de diversión:

1. Consigue una copia de WoW y sus expansiones: Burning Crusade y The Wrath of the Litch King (como conseguirla es cosa tuya, pero igual comprarlo no es mala idea).


2. Coge tu linux e instala la versión de Wine que tengas en repositorios. No hace falta la última porque WoW funciona bajo Wine desde sus primeras versiones.


3. Mete tu CD y navega con Linux hasta su raiz.


4. Ejecuta el instalador con normalidad (creo recordar que se llama ‘Setup.exe’).


5. Vete a tomar por culo un par de kilos de cafeses.


6. Vuelve y maravillate de cómo tu instalación ha finalizado correctamente.


7. Create una cuenta en WoWAura y conectate (proximamente tutorial, lo juro).


8. Únete a la Horda y disfruta. Únete a la Alianza y muere.

Los Alis usan addons (y los enseñan). Los addons cabrean a los GM. ¿De verdad quieres ser como esa escoria?

Y así de simple. Lo mejor de todo es que el rendimiento tanto a nivel de imagen como de sonido es inexplicablemente superior en la implementación de Wine que al nativo de Windows. Jamás tendrás problemas con el rendimiento del juego a no ser que tu conexión a Internet sea inestable. Y por estable se entienda estable, no necesariamente rápida, pues el paquete de datos de WoW es muy ligero lo cual hace posible jugar con relativa tranquilidad incluso con conexiones de 56K (pero tú no intentes hacerlo, ¿vale?).

Así que cosa güena. Juegas a tu rollo, te peleas o ayudas a otros, no se hacen muchos amigos la verdad, pero que hostias, para eso tengo la vida real. Juega, disfruta y nunca olvides que…

¡La Horda te quiere!