Categoria: PRO

El Hotlinking o robo de ancho de banda es una práctica habitual en usuarios inexpertos o aprovechados. Consiste en que cuando un usuario se encuentra una imagen que le gusta en una web y la quiere colgar en la suya, en lugar de descargar esa imagen y subirla en su servidor directamente la enlaza desde su fuente original. ¿Cual es el problema de esto? Pues que cada vez que se muestra la página del usuario, se hace una llamada al servidor que contiene la imagen para mostrarla, consumiendo así su ancho de banda y sus recursos sin ofrecer un rendimiento a cambio. Es decir, tu servidor trabaja pero nadie está viendo tu web.

Como en algunos casos este tipo de acciones pueden suponer un intento de ataque, y en cualquier caso no está bien que la gente nos robe nuestros recursos (que cada palo aguante su vela), vamos a ver como podemos minimizar los daños de esta conducta en nuestro servidor Apache 2. Para ello veremos el ejemplo práctico que tenemos montado en este web:

Primero creamos una imagen bien llamativa, a ser posible incluso fea, para que aparezca cada vez que alguien nos intente hacer el hotlinking. Nosotros tenemos esta:

Como podéis ver, la imagen la hemos alojado en un servidor de imágenes externo, pues lo que nos interesa precisamente es que no tengamos que mostrarla desde nuestro servidor.

Una vez la tenemos, vamos a configurar Apache 2. Lo primero es habilitar el mod_rewrite que nos hace falta:

En Debian

$ su
# a2enmod rewrite

Ahora vamos a modificar el /etc/apache2/sites-available/default añadiendo AllowOverride All a las fuentes principales:

Options Indexes FollowSymLinks MultiViews AllowOverride All Order allow,deny allow from all


Reiniciamos Apache

# /etc/init/apache2 restart

En Mandriva:

Si no lo tienes, instala el paquete apache-modules

# urpmi apache-modules

Editamos el fichero httpd.conf de Apache 2 y descomentamos la siguiente línea:

LoadModule rewrite_module modules/mod_rewrite.so

Reiniciamos apache:

# service httpd restart

Una ve configurado Apache creamos un fichero llamado .htaccess con el contenido siguiente:

# Vamos a evitar el robo de ancho de banda
# Habilitamos Mod_Rewrite

RewriteEngine On

# Generamos las reglas principales de rewriting.
# 1 Se aplicará a todos los dominios

RewriteCond %{HTTP_REFERER} !^$

# Excepto al nuestro
RewriteCond %{HTTP_REFERER} !^http://(www\.)proyectopqmc.com(/)?.*$ [NC]

# 2 Si queremos autorizar a algunas páginas a mostrar imágenes,
# como por ejemplo a Google Imágenes o Facebook, o la de algún amiguete
# añadir su dominio aquí, como en este esquema.

RewriteCond %{HTTP_REFERER} !^google.com [NC]
RewriteCond %{HTTP_REFERER} !^http://ohmygood.spaces.live.com [NC]
RewriteCond %{HTTP_REFERER} !^blogdrake.net [NC]
RewriteCond %{HTTP_REFERER} !^freesoftwareando.com [NC]
RewriteCond %{HTTP_REFERER} !^facebook.com [NC]

# 3 Imagen que se va a mostrar a los dominios que no estén autorizados

RewriteRule .*.(gif|jpg|swf|png|jpeg)$ http://img293.imageshack.us/img293/8282/hotlinkinggw1.jpg [L]

Guardamos el fichero y lo subimos a la carpeta raíz de nuestro servidor web. Es posible que necesitemos recargarlo:

# /etc/init/apache2 force-reload

o

# service httpd reload

Ahora cada vez que un dominio no autorizado intente enlazar una imagen nuestra directamente, les aparecerá ese cartelon tan feo, para befa y mofa del perpetrador. Para muestra, un botón:

http://wiki.taringa.net/posts/tv-peliculas-series/6605732/1080p-|-Hackers-%281995%29.html

Con Firefox, haz botón derecho sobre la imagen y selecciona “Ver información de la Imagen“. Verás que efectivamente apunta a una imágen de éste artículo. Pero el resultado mostrado es la imagen subida al servidor externo. Igualmente si pinchas en “Ver imagen” te redirigirá a la imagen de alerta.

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.

Cuando nos enfrentamos ante una infraestructura amplia de servidores que deben trabajar con un mínimo de sincronización, es importante que todos ellos compartan la misma hora, y ajustar manualmente la hora de cada uno no solo es una tarea tediosa, sino que además es inútil ya que la precisión es muy baja, y la latencia del hardware de reloj de un servidor normal puede retrasarlo hasta 2 segundos a la semana. Insostenible a largo plazo.

Afortunadamente, existe un protocolo llamado Network Time Protocol (NTP, Protocolo de Tiempo de Red) que nos permite mediante un sistema jerárquico de clientes-servidores sincronizar a través de una red la hora de los servidores contra una o varias fuentes. Es decir, que los servidores pueden pedirse la hora unos a otros siguiendo un modelo escalonado, manteníendo todos la misma hora con un margen de diferencia mínimo.

Como comentamos, NTP tiene una estructura jerárquica dividida en ESTRATOS. El número de estrato de un servidor indica cuán lejos está de una fuente de hora original, siendo los servidores de estrato 1 los que constituyen una fuente de final de hora. Este tipo de servidores de estrato 1 son máquinas especiales equipadas con hardware específico capaz de obtener la hora en función de condiciones físicas externas, como por ejemplo los datos de un satelite de GPS o el eje de inclinación de la tierra. Este tipo de hardware es desorbitadamente caro, quepa decirlo. Ejemplos de este tipo de servidores de estrato 1 son los relojes atómicos de Greenwich (que miden el tiempo mediante las vibraciones del átomo de cesio) o los relojes astronómicos de la NASA.

En los siguientes estratos se van montando servidores que toman la hora de uno o varios estrato 1 y la sirven a estratos inferiores, con el objetivo de no saturar la carga de los servidores de más alto estrato y hacer más precisa su información. Los servidores de estrato 1 no suelen facilitar información a clientes, sólo a otros servidores. Técnicamente, no existe un limite en cuanto al número de estratos que puede haber en una jerarquía NTP, pero como convencíon podemos decir que 12 es el número máximo.

¿Como funciona NTP a nivel lógico? Sencillamente, cuando un cliente solicita información de hora a un servidor, este le devuelve su hora local, su huso horario y su estrato. Si no está configurado para ser fuente directa, en lugar de su hora local devuelve la hora del servidor o servidores con los que esté sincronizado. El cliente es el que se encarga de hacer los cálculos para decir que hora se queda.

Y ahora, ¿como se implementa? NTP es tremendamente sencillo. Veamos como se implementa en Windows y en Linux:

IMPLEMENTACIÓN DEL SERVIDOR

Windows:

Para implementar un servidor NTP en Windows, simplemente debemos descargar el servidor desde la web de Meinberg, que realiza el desarrollo para Windows. La licencia es libre.
Ejecutamos el fichero descargado y seguimos las instrucciones para instalación completa. Acto seguido, comenzamos a configurar el servidor:

En este menú, podemos dejar por defecto la ruta del fichero de configuración. A continuación marcamos la casilla “Crear configuración inicial”. Podemos elegir entre sincronizar contra fuentes estándar del pool de NTP.org en la primera pestaña, o especificar una lista de servidores personalizados en el cuadro de abajo. Puedes dejarlo vacío si quieres que la única fuente sea el reloj interno del servidor.

NOTA-YA-TE-LO-DIJE: No es buena idea utilizar el reloj interno del servidor como fuente de hora NTP por su imprecisión, salvo que este esté sincronizado a su vez con otra fuente por otro medio (como un controlador de dominio). Tampoco es conveniente tener muchas fuentes de hora: no te darán más precisión, si cabe menos. Es mejor tener dos o tres fuentes cerca de tu área geográfica que 14 de todo el mundo.

También se puede especificar si se va a usar la característica iburst. Más inforamción sobre esta característica en la web de Meinberg. En la siguiente casilla especificaremos que estrato tiene el servidor, útil si estás montando tu propia jerarquía.

Una vez instalado y configurado, dispones del siguiente menú en Inicio para controlar el servicio:

Haciendo click en la opción Start ya lo tendremos listo para aceptar peticiones.

Linux/Unix:

En los sistemas Linux/Unix es habitual que el demonio ntpd venga instalado de serie. Si no lo estuviese, es tán sencillo como instalarlo empleando los sistemas de paquetería habituales.

Los usuarios de Mandriva harán:

# su
# urpmi ntpd

Los usuarios de Debian harán:

# su
# apt-get install ntpd

Y si usas Solaris debes descargar el paquete desde Sun Freeware y ejecutar:

# su
# gunzip ntp-4.2.6-sol10-sparc-local.gz
# pkgadd -d ntp-4.2.6-sol10-sparc-local

A continuación procedemos a configuar el servicio. Si tienes un asistente gráfico, mejor que mejor, sino edita el ficero /etc/ntp.conf con tu editor de texto habitual. Veamos como es el fichero con su explicación:

# Esta línea permite que otros se sincronicen con nosotros,
# pero sin modificarnos.
restrict default kod nomodify notrap nopeer noquery

# Permitimos todas las conexiones por la interfaz de loopback,
# para sincronizarnos nosotros mismos
restrict 127.0.0.1
restrict -6 ::1

# En esta línea podemos dar permisos especiales a un determinado rango de red.
# Pon los rangos de red y la máscara de subred que se puedan conectar a tí.
# Más información sobre esto en ntpd.og.
#restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap

# Aquí indicamos que si no hay ninguna fuente disponible, utilicemos
# nuestro reloj de hardware como fuente, indicando el estrato.
fudge 127.127.1.0 stratum 10

# Este fichero contiene la varianza entre la hora cedida y la cargada.
# No lo toques.
driftfile /var/lib/ntp/drift

# Fichero de claves para uso de criptografía cruzada.
# No lo toques-.
keys /etc/ntp/keys

# A continuación especificamos los servidores con los que nos vamos a sincronizar,
# así como las reglas que vamos a aplicar con cada uno de ellos.
# Si no hay nada se empleará la fuente local.
server 192.168.13.238
restrict 192.168.13.238 mask 255.255.255.255 nomodify notrap noquery

Para crear un servidor, únicamente debemos especificar los servidores a los que vamos a sincronizar o la línea fudge para ser nosotros fuente, y especificar el rango de red que podrá solicitar sincronización.

Después, arrancamos el servicio según nuestro sistema operativo.

IMPLEMENTACION DEL CLIENTE:

Al ser un servicio estándar, para configurar el cliente es irrelevante el SO del servidor. Todos funcionan con todos. Veamos lo sencillo que es configurar un cliente:

Windows:

En Windows la forma más sencilla de configurar NTP es hacer doble click sobre el reloj. En el cuadro que se despliega seleccionamos la pestaña Sincronización de Hora de Internet y dentro marcamos la casilla “Sincronizar automáticamente con un servidor de hora“. Indicamos en la pestaña el nombre del servidor y pinchamos en “Actualizar ahora“.Si todo va bien debería coger la hora sin problemas.

Linux/Unix:

Para sincronizar con Linux y Unix, igualmente debemos tener instalado el paquete ntpd. Lo instalamos si no lo tenemos como hemos explicado antes.

Desde una consola, ejecutamos el siguiente comando:

# ntpq -p host-ntp

Donde host-ntp es el nombre de host o IP del servidor NTP que hemos configurado. Con este comando testeamos si somos capaces de sincronizar con el servidor. Si funciona, nos devolverá una línea por cada fuente configurada del servidor. En este ejemplo el servidor sólo tiene configurada com ofuente su hora local:

# ntpq -p time.server.com
remote refid st t when poll reach delay offset jitter
==============================================================================
*LOCAL(0) .LOCL. 12 l 35 64 377 0.000 0.000 0.001

Una vez hemos comprobado que llegamos, simplemente editamos el fichero /etc/ntp.conf y añadimos las siguientes líneas al final por cada fuente:

server [host]
restrict [host] mask [subnet] nomodify notrap noquery

Arrancamos o reiniciamos el demonio ntpd y podremos comprobar como ahora servidor y cliente comparten al segundo la misma hora.

Sin duda una de las herramientas más útiles, características e indispensables de cualquier shell de sistemas tipo Unix (Linux incluido of course), son las llamadas tuberías o pipes. Las tuberías (representadas con el carácter ASCII |)se emplean para interconectar procesos, siendo su uso más habitual el pasar el resultado de la ejecución de un comando a la entrada de otro. Un ejemplo habitual sería:

ps -ef | grep wine.exe

En este comando estamo ejecutando ps con las opciones e y f, con lo que obtenemos un listado completo de procesos con nombre de usuario, PID, y el comando completo que ha lanzado el proceso, entre otras cosas. Toda esa información, en lugar de mostrarla por salida estándar, se la pasamos como entrada mediante una pipe a grep, al que le indicamos que tome dicha entrada, filtre aquellas líneas que contienen la cadena “wine.exe”, y nos las muestre por salida estándar. Con esto localizaríamos todos los procesos que contengan dicha cadena, lo cual a efectos de administración es algo muy cómodo.

En principio conocemos a los pipes como pipes o tuberías, pero sería mas correcto conocerlos como pipes anonimos, puesto que existe otro tipo de tuberías con similares características pero diferente finalidad y uso llamadas Named Pipes (Tuberías con Nombre).

Las Named Pipes son, basicamente, un fichero en disco. La diferencia consiste en que en lugar de ser un contenedor de datos, los Named Pipes actúan como torrentes de caracteres (stream), por lo que se puede indicar a otro o a otros procesos que lo lean y capturen al vuelo la información que contiene.

Ya tenemos las dos primeras diferencias entre una pipe y un Named Pipe: De un Named Pipe pueden leer varios procesos al mismo tiempo, cada uno de ellos puede extraer la información que necesita y procesarla sin tener que esperar turno. Otra característica importante es que los Named Pipes no almacenan datos, por lo que una vez terminado su uso simplemente vuelven a tamaño cero.

Pero, ¿para que podemos usar un Named Pipe? Supongamos que tenemos un script de Perl que lee de varios ficheros de log del sistema y genera un reporte. Dicho reporte es muy largo y el fichero generado es muy pesado, por lo que queremos comprimirlo en un tar.gz para enviarlo por email. Dado que tar y gzip no leen por entrada estándar, es necesario especificarles un fichero, por lo que el proceso normal consistiría en ejecutar el script de Perl, escribir el fichero, y después generar el tar.gz.

Sin embargo, si utilizamos una Named Pipe, podemos hacer que el script vuelque su salida en un Named Pipe y mientras tanto tar vaya leyendo el Named Pipe y comprimiendo. El resultado será únicamente el fichero comprimido, pues el tamaño de la tubería seguirá siendo 0. Útil si tienes el espacio en disco ajustado y quieres ahorrarte un tiempecito.

¿Como se usa una Named Pipe?

Lo primero es crearla, para ello utilizamos el comando mkfifo:

$ mkfifo /tubería

Acto seguido la tendremos disponible para realizar cualquier operación utilizando redirecciones:

ls -lrt > /tuberia

De cara a un script, sería más sencillo introducirla en una variable:

mituberia = /tuberia
mkfifo $mituberia
ls -lrt > $tuberia.

Las Named Pipes no son ni de lejos las más utilizadas en Bash Script. De hecho, no es habitual verlas puesto que en la mayoría de los casos es más sencillo utilizar tuberías anónimas. En cualquier caso, es muy interesante saber de su existencia porque en determinados contextos pueden sernos de gran utilidad.

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:

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/

Amigos míos, queridos lectores. Hoy estreno mi propio alter-blog: El Autoestopista Informático.

No les aburro con más perorata aquí. Sigan el enlace y descubrandlo por ustedes mismos.ç

Y siiii… Ya tengo twitter.