Libertonia
Portada · Todo · Software Libre · Desarrolladores · Comunidad · Internet · Tecnología · Meta · Diarios
No me gustan la Sindicación (los RSS)

jamarier's Diary
Por jamarier
departamento Comite por una red mejor , Sección Diarios
Puesto a las Fri May 21st, 2004 at 02:09:15 PM CET

Antes de que empeceis a tirar piedras, diré que el título fué escogido por sensacionalista. No por porque sea exactamente mi pensamiento. Ahora que tengo vuestra atención puedo desarrollar la idea:

[Nota del autor: Tenía una preciosa introducción sobre el tema, pero superaba el límite de palabras, así que hago un feo resumen aquí para el que no quiera leer la noticia completa y el resto en el cuerpo de la misma: la utilidad que proporcinal la sindicación me parece buena. la implementación no.]

 


Existe una posible clasificación de las páginas web:

  1. Las que generan información. Pueden tener una tematica más o menos definida, pero el contenido exacto de cada noticia o información no se sabe hasta que no se publica. Esta publicación puede ser «síncrona» o «asíncrona» es decir, publicarse de forma regular en el tiempo o cuando le da la gana a los mantenedores. Las web de noticias como libertonia, weblogs y otras están en esta categoría.
  2. Las que tienen información a consultar. Solo visitamos dichas páginas cuando necesitamos una información y sabemos que la vamos a encontrar ahí: los buscadores como google o imdb están entre ellas.
  3. Las páginas de nuestros amigos que las actualizan cuando les da la gana. Con minutos, dias o meses entre cada actualización. Como por ejemplo la mía propia
(Por supuesto estas categorias se solapan en mayor o menor medida).

La idea es buscar un mecanismo para estar al tanto de cuando se producen cambios en los casos 1 y 3 sin tener que hacerlo nosotros manualmente. Aquí entra el «Fabuloso mundo de la sindicación» (los RSS).

(No voy a dar definiciones precisas, porque tampoco son necesarias. Además aunque aquí emplee el término RSS, os comentaré que es uno de los distintos formatos disponibles para la sindicación, otros son RDF, atom y no se que más.)

Visto desde fuera, la sindicación es lo siguiente: Cuando una página web te gusta y ofrece posibilidades de sindicación, tu la activas y cada vez que cambia la página automáticamente te avisan los cambios con un pequeño resumen de dicho cambio. ¡Prueba superada!

Desde dentro la realidad es bien distinta: las páginas que ofrecen sindicación, son aquellas que tienen a disposición de los usuarios de un fichero resumen de si misma (en el formato RSS u otro). Cada vez que se actualiza la página se hace consecuentemente lo mismo con el resumen. Cuando un usuario se sindica lo que hace es suministrar a un programa (el lector de RSS) la dirección de dicho resumen. La misión del lector es cada cierto tiempo bajarse el resumen y compararlo con un resumen previamente bajado. Si existen diferencias se las comunica al usuario.

Se supone que esto anterior lo debe saber todo el mundo que lee libertonia. Quizás el siguiente apartado no lo sepa ya tanta gente:

En la electrónica digital y en la informática existen 2 sistemas de controlar recursos externos (los perifericos): el poll y las interrupciones. En el primer caso, el micro deja de trabajar cada cierto tiempo para preguntar a cada periférico si tiene alguna información nueva que suministrar, espera la respuesta de cada periférico y sigue trabajando con lo suyo. En el segundo caso, el micro trabaja sin parar y cuando un periférico tiene nueva información este manda al micro una petición de interrupción («oye, cuando puedas te paras y miras lo que te tengo»). Este, cuando puede se para y atiende a la petición.

En función de las necesidades y la simplicidad requerida del diseño, se emplea un sistema u otro. El poll es bastante simple de utilizar. Aunque tiene 2 inconvenientes: el micro deja de trabajar para consultar cosas (perdida de potencia) y los buses de comunicaciones se llenan de mensajes del tipo: "¿tienes algo para mí?", "no". El sistema de interrupción en cambio tiene un inconveniente: es más complejo de implementar periféricos inteligentes.

Volvamos al mundo de la sindicación. Como podreis suponer, todo el sistema de la sindicación se efectuan por llamadas tipo poll. Esto significa que estamos bajandonos a nuestro equipo resumenes que en la mayoría de los casos no varía con respecto lo que ya teníamos. Es cierto que los resumenes, como su nombre indica, no pesan tanto como las páginas web completas, pero los lectores comprueban cada muy poco tiempo (30 minutos, 1 hora aprox) si ha habido variación. Con lo cual al cabo del día lo descargado llega a ser superior a visitar la página web.

Hay un segundo aspecto a tener en cuenta. La multiplicidad de usuarios. Si muchos usuarios te sindican, significa que muchos robots van a bombardear el servidor para conseguir el resumen cargando constantemente el equipo. Recientemente he leido (lo siento, no recuerdo el enlace) de una página que retiraba el RSS de su web. Había muerto de éxito. Tenía tantas peticiones de RSS que le hundían el servidor.

No me gusta la sindicación

En general mueve mucha información que no sirve para nada. Sobrecarga innecesariamente al cliente y al servidor. Consume ancho de banda.

Solución, la generación de eventos de cambio de página o fórmulas híbridas.

  • Generación de eventos o suscripción. Determinar algún sistema para que la página web pueda emitir un aviso de que ha variado (por correo electrónico y otro sistema a determinar) esto permite la serialización en los avisos: Si una web puede dar 10 páginas por minuto y tiene a 100 personas suscritas, puede avisar a cada persona con 6 segundos de intervalo. Así evita que 100 personas o robots accedan simultáneamente a la página.
  • Fórmulas híbridas. Es el sistema que yo empleo en este momento. En vez de tener un lector de RSS particular, me he suscrito a un robot jabber: jabrss@jabber.at Este robot, es un lector RSS que hace las consultas via RSS. Cuando hay variaciones en una de las páginas web, me envia un mensaje y me lo comunica. ¿Cuál es la ventaja respecto al método directo? Si 2 personas que usan el servicio están suscritos a la misma página web no hace falta dos peticiones del RSS. Imaginad el ahorro para 10 o 100 usuarios. Creo que http://www.syndic8.com (no los voy a enlazar porque no se lo merecen B-P ), tambien tiene un servicio similar aunque cobran ¡¡$25!! por la sindicación de una página web durante ¡una semana!

Para terminar, la idea es que hay que intentar ser respetuosos con los servicios que nos ofrecen desde internet para no agotar los recursos de los que los ofrecen gratuitamente. El uso de lectores «comunitarios» frente a los personales, es una buena medida de cortesía.

< Introducción a Subversion (8 comments) | De GNOME a KDE (57 comments) >
Enlaces Relacionados
· escomposlinux.org
· libertonia
· google
· imdb
· More on jamarier's Diary
· Also by jamarier

Encuesta
Tu sindicas...
· No sindico, visito regularmente las páginas que me interesan (1 vez/día o menos) 15%
· No sindico, visito compulsivamente las páginas que me interesan (más de 1 vez/día) 53%
· Sindico con programa personal pero intervalos de consulta del robot de 1 vez/día o menos 7%
· Sindicación programa personal de forma intensiva (más de 1 vez/día) 23%
· Lo que diga la rubia, digo^U Uso algún sistema de sindicación comunitaria 0%

Votos: 13
Resultados | Otras Encuestas

Menu
· crear cuenta
· FAQ
· búsqueda
· Fuentes de Noticias

Login
Nueva cuenta
Usuario:
Contraseña:

Ver: Modo: Orden:
No me gustan la Sindicación (los RSS) | 15 comentarios (15 temáticos, editoriales, 0 ocultos)
If-Modified-Since y Last-Modified. Poll y más (none / 0) (#1)
por jorginius ("jorginius" en Google Mail) a las Fri May 21st, 2004 at 08:16:29 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

Esto significa que estamos bajandonos a nuestro equipo resumenes que en la mayoría de los casos no varía con respecto lo que ya teníamos.

No te los bajas de nuevo, a menos que el programador del cliente de sindicación y/o el administrador de la web sindicado hayan metido la pata. Se espera que con la sindicación uses GET condicionado a la fecha del último cambio en el resumen.

Del lado del cliente descargas la primera vez y de la respuesta que te da el servidor te quedas con la cabecera Last-Modified. Al siguiente intento, el cliente debería incluir en su petición una cabecera If-Modified-Since con el último valor de Last-Modified que obtuvo: en caso de que no haya habido cambios desde entonces, el servidor responderá con un 302 y no despachará de nuevo el resumen.

Esa es la idea, pero puede que el cliente esté mal escrito ignore las pistas que le da el servidor y se empeñe en volver a descargar lo que ya tiene. También puede ocurrir que el servidor esté mal configurado y o bien no incluya Etag y Last-Modified en sus respuestas o bien mienta en esos campos. Esto último es bastante común en todos esos servidores configurados mal apropósito para ¿boicotear? el proxy transparente de Telefónica (y cualquier otro proxy, de paso).

Por otra parte, la puntilla pedante:

El poll es bastante simple de utilizar. Aunque tiene 2 inconvenientes: el micro deja de trabajar para consultar cosas (perdida de potencia) y los buses de comunicaciones se llenan de mensajes del tipo: "¿tienes algo para mí?", "no".

Depende, no siempre "se pierde potencia". En ocasiones el mecanismo de poll es el más eficiente. Una interrupción implica un cambio de contexto y los cambios de contexto son caros en tiempo. En un sistema monoproceso gana de calle el polling frente a las interrupciones (quizás no en consumo, pero si en velocidad de respuesta) y en un sistema multiproceso puede que el polling sea una buena idea si el dispositivo es más rápido que un cambio de contexto, o si es crítico actualizar una salida lo más deprisa posible en función de lo que leamos de un dispositivo.



Perdón, perdón. Donde dije 302... (none / 0) (#3)
por jorginius ("jorginius" en Google Mail) a las Fri May 21st, 2004 at 08:38:01 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

...Sustituid mentalmente por 304. 302 es "Moved temporarily" y 304 es "Not modified" (que es de lo que se trata).

[ Padre ]


 
El fondo, mira el fondo B-) (none / 0) (#4)
por jamarier a las Sat May 22nd, 2004 at 12:13:23 AM CET
(Información Usuario) http://barbacana.net/blog/

Siempre es de agradecer las notas tecnológicas. Efectivamente, el proceso que he descrito es burdo y acepta optimizaciones. No es necesario bajarse el fichero si miramos las fechas (suponiendo que estén bien configuradas).

De todas formas aunque sea menor el tránsito, sigue existiendo el mismo. Sigue siendo una conexión abierta que el servidor ha de atender y si se hace una consulta cada media hora es un trasiego. Un usuario normal, a menos que sea muy ansioso, visita las páginas una vez al día o una cada dos dias. (De hecho, antes de usar RSS, usaba websec para que me avisase de las modificaciones en las páginas y lo activaba con cron una vez a la semana).

Respecto a lo de poll e interrupción, habría tanto que discutir ;-) depende de la complejidad del periférico, del controlador, potencia del controlador, de la frecuencia de barrido de periféricos (la del poll), de la frecuencia de la producción de la interrupción, coste de la subrutina de encuesta, coste de la entrada de la interrupción...

Simplemente lo que quería decir es que la idea es buena (la de la sindicación) pero que la implementación no es para tirar cohetes. Si yo me suscribo a una revista no es para tener que ir cada 30 minutos a preguntarle al quiosquero si ha llegado (por poco que tarde en hacerlo). Es para que cuando salga la revista me la lleven a casa.

-----
- Porque mañana será un gran día.
[ Padre ]



¿La alternativa? (none / 0) (#6)
por jorginius ("jorginius" en Google Mail) a las Sat May 22nd, 2004 at 11:13:11 AM CET
(Información Usuario) http://www.rodriguezmoreno.com

De todas formas aunque sea menor el tránsito, sigue existiendo el mismo. Sigue siendo una conexión abierta que el servidor ha de atender y si se hace una consulta cada media hora es un trasiego.

Cierto, pero es que usando sólo HTTP como protocolo de transporte no se puede hacer mucho más. A menos que el servidor pueda iniciar conexiones de notificación en los clientes (y eso supone abrir puertos y olvidarse de nat), eso es lo que hay.

En cuanto al sistema de suscripción y notificiación que propones, la implementación que se me ocurre es usar un servicio universal que permita broadcast de mensajes, como Jabber. La sindicación funcionaría de esta manera: añades a tu roster el bot de tal o cual página y éste te avisa si estás presente, avisa a todo su roster, haciendo broadcast de mensajito de tipo "headline" ("headline" es una extensión del mensaje estándar que soportan algunos clientes como Jarl. Screenshot de Jarl leyendo headlines).

Desde el lado del cliente es perfecto, pero desde el lado del servidor no sé si sería muy adecuado (vaya por delante que no soy un experto en Jabber):

Supongamos un sitio web de noticias con un nivel medio de lectores de RSS (unos 10.000 distintos a diario). Eso supone un roster de 10.000 entradas.

El servidor Jabber mantiene una conexión abierta por cada servidor par en el que tengamos al menos un contacto en el roster pero esto no es lo peor, lo peor son los mensajes de presencia: cada vez que enviemos un titular, tendremos el tráfico de sendos mensajes XML (petición/respuesta) por cada contacto disponible en el roster, con sus esperas y la carga despachar 10.000 mensajes distintos en un lapso de tiempo pequeño. Cuando tengamos las respuestas de presencia, empieza el broadcast del mensaje headline (eso sin contar con que es "pseudo-broadcast").

En realidad no sé si esto supondría un problema para el servidor Jabber. JabberRss soporta algo parecido pero no sé su número de usuarios ni que hardware ni que tráfico mueve). Puede que sea peor el remedio que la enfermedad.

Por otra parte, el peso de un mensaje de presencia Jabber es similar al de una petición HTTP o al de una respuesta HTTP que no sirva página (como 304), luego si el tiempo de actualización del sitio es pequeño (Tipo Slashdot, por ejemplo) nos estamos complicando la vida con otro protocolo y otro servidor (desplazando la carga del servidor HTTP al de Jabber) para quedarnos igual que estábamos. Ahora estaremos en el caso en que es más eficiente el polling... Siempre que se haga con GET condicional.

Quizás dependiendo del sitio (SI tiene un número de visitas menos que X... SI tiene servidor de Jabber propio...) un sistema de suscripción como el que describo, "por interrupción", fuera útil. Habría que verlo, pero de todas formas ya no estamos usando sólo HTTP y eso puede ser un problema (cortafuegos que sólo dejan conexiones al puerto 80, tener que desplegar un servidor Jabber, etc).

[ Padre ]


 
Más lectores comunitarios (none / 0) (#2)
por filete a las Fri May 21st, 2004 at 08:17:32 PM CET
(Información Usuario) http://adobo.org

Buenas, precisamente hace 3 ó 4 días me metí un poco más en el tema. La razón es que leí en microsiervos.com que se había lanzado un lector vía web de RSS, programado por dos personas, Feedmanía. Es un servicio al estilo bloglines, aunque este último no lo he usado. Por si a alguien le interesa probar Feedmanía, he de decir que va muy bien, no tiene publicidad y... cumple con su función.

En cuanto a mi opinión acerca de los RSS, pues tengo básicamente la misma que tú. Yo creo que el problema es que, al transmitirse XML, hay un tráfico excesivo. Es algo parecido a lo que ocurre con Jabber, algo que creo que se ha discutido y se discutirá siempre acerca de él: el uso de XML es una ventaja pero a la vez una desventaja, por el ancho de banda que consume.

Volviendo al tema original, creo que hasta que no se invente algo mejor, RSS cumple su cometido, ya que hace la visita a tus webs preferidas más cómoda.

Un saludín

---
Estoy en mi salsa...


posi, posi, posi. (none / 0) (#5)
por jamarier a las Sat May 22nd, 2004 at 12:31:51 AM CET
(Información Usuario) http://barbacana.net/blog/

Iluso de mí iba a darte una contraréplica diciendo que los diseñadores de jabber no iba a cometer la estupidez de enviar la información en XML.

Para documentarme he analizado mis puertos y me he enviado un mensaje jabber y AGHHHH horror!!, era xml. B-(

Una ventaja que tiene el xml es que es facilmente comprimible al tener estructuras que se repiten mucho (los tags por ejemplo).

Yo sabía que Jabber funciona con xml, pero suponía que se enviaba al servidor comprimido para reducir el «overhead» (que se llama); pero o se envía sin comprimir o el ethereal que he usado es tan listo como para descomprimirlo al vuelo.

Cosas veredes amigo Sancho.

-----
- Porque mañana será un gran día.
[ Padre ]



Pues mira, no es que tenga que ver pero... (none / 0) (#7)
por jorginius ("jorginius" en Google Mail) a las Sat May 22nd, 2004 at 01:43:57 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

Hablando de la compresión y de Libertonia: resulta que tienen instalado (y configurado, supongo) el mod_gzip, para servir las páginas comprimidas si el cliente lo soporta, pero a la hora de la verdad no sirven nada comprimido :-?.

Quizás esté mal configurado Scoop o Apache, o quizás me estoy equivocando yo al mirarlo. Escribo un mini-script en python de 3 segundos para mostrar lo que quiero decir:
from socket import *
import sys

if len(sys.argv) == 1:
    print "Uso: prueba_comp http://sitio.com/pagina.html"
    sys.exit(0)

surl = filter(None, sys.argv[1].replace("http:", "").split("/"))
surl.append("")
sock = socket(AF_INET, SOCK_STREAM)
sock.connect((surl[0], 80))

sock.send(
    'GET /%s HTTP/1.1\nHost: %s\nAccept-Encoding: gzip\n\n' %
        (reduce(lambda x, y: x+"/"+y, surl[1:]), surl[0]))
data = sock.recv(1024)
sock.close()

if data.find("Content-Encoding: gzip") != -1:
    print "Ok. Comprimido"
else:
    print "Fallo. No comprimido"


Y ahora probamos:
$ prueba_comp http://libertonia.escomposlinux.org
$ prueba_comp http://www.kuro5hin.org


¿Algún BOFH que me ilumine?.

[ Padre ]


Algo tienes mal (none / 0) (#8)
por Draco a las Sat May 22nd, 2004 at 05:49:24 PM CET
(Información Usuario)

Diría yo:
wget --header="Accept-Encoding: gzip"  -S -O /dev/null  \ 
http://libertonia.escomposlinux.org/story/2004/5/21/14915/1337

 1 HTTP/1.0 200 OK
 [....]
 6 Content-Encoding: gzip
 7 Content-Length: 8288
 8 Age: 2
 9 Connection: keep-alive


Aunque ahora mismo no veo qué... De todas formas te gusta hacer las cosas complicadas ¿por qué partes las cadenas si luego tienes que unirlas?
There are two major products to come out of Berkeley: LSD & BSD Unix. I don't believe this to be a coincidence.
[ Padre ]


Pués no (none / 0) (#9)
por Draco a las Sat May 22nd, 2004 at 05:59:25 PM CET
(Información Usuario)

Mil perdones. Por lo que sea, la página principal no se comprime, no así las demás. Tu script estaba bien (aunque sigue siendo lioso :-). Pruébalo contra esta misma página.

Ahora soy yo quién está intrigado ;-)
There are two major products to come out of Berkeley: LSD & BSD Unix. I don't believe this to be a coincidence.
[ Padre ]


 
Síp, lo único que no comprime es la portada (none / 0) (#10)
por jorginius ("jorginius" en Google Mail) a las Sat May 22nd, 2004 at 06:44:16 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

Bueno, las parto para quedarme con la parte del Host por un lado y la parte de la página por otro, sin tener que controlar ningún caso (si escribes o no un "http://" al principio, o un "/" al final o...) y sin tener que usar el módulo de expresiones regulares. Yo no lo veo nada lioso, de hecho pensé que así era más sencillo que si lo escribía con re o con notación de comprensión de listas. Seguro que era más corto de la otra forma, incluso.

De todas formas, sólo lo probé una vez :-). La prueba buena la hice hace semanas con ethereal, al equivocarme con el filtro, pillar por casualidad una petición de konqui a Libertonia y ver que la portada no la recibía comprimída.

Porque sí, tienes razón: las páginas de las historias, los comentarios, las portadas de las secciones y los resúmenes de sindicación sí que los sirve comprimidos. Lo que no comprime es la portada principal, que fue lo que me despistó. No entiendo por qué todo lo demás sí y eso no :-?

Precisamente, para mejorar el asunto de la sindicación (que es de lo que trata la entrada de diario) también es interesante que los RSS deberían servirse comprimidos, y los clientes deberían soportarlo.

[ Padre ]


Cuestión de estilo (none / 0) (#11)
por Draco a las Sat May 22nd, 2004 at 10:47:08 PM CET
(Información Usuario)

Bueno, lo que a uno le puede parecer lioso a otro no y viceversa. Lo que pasa es que yo lo hubiera hecho así a la hora de separar:
sys.argv[1].replace("http://", "").split("/",1)
o a la hora de unir:
"/".join(surl[1:])
o directamente el módulo re, claro.
There are two major products to come out of Berkeley: LSD & BSD Unix. I don't believe this to be a coincidence.
[ Padre ]


Ah, split tiene dos parámetros, vaya (none / 0) (#13)
por jorginius ("jorginius" en Google Mail) a las Sat May 22nd, 2004 at 11:43:14 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

Jurl, pues sí: olvidé que split() puede recibir dos parámetros. Corrige mentalmente el script, que tienes toda la razón del mundo.

Lo del join() sí que es más deliberado. Yo creo que queda más claro de la otra forma. Al join() antes le encontraba sentido, cuando formaba parte del módulo string, pero ahora es que no entiendo lo que quiere decir. Para concatenar cadenas llamas a un método de la cadena separadora y el método te devuelve un nuevo objeto, ¿eso se entiende? ... ¿No es mejor objstr.join(secuencia,[separador]) (y que objstr sea sobreescrito)?, o como estaba antes, no sé.

Bueno, en todo caso gracias por el apunte. Escribiré más despacio la próxima vez #iÍ)

[ Padre ]


 
No me preguntes por qué (none / 0) (#12)
por iarenaza a las Sat May 22nd, 2004 at 11:24:39 PM CET
(Información Usuario) http://www.escomposlinux.org/

Por qué no tengo ni idea de porqué la portada no se comprime, la verdad.

He estado mirando de arriba a abajo la configuración de Apache y no tiene ningún sentido lo que hace actualmente. Estoy completamente despistado.

De hecho, tras leer tu comentario he pensado que no comprimía nada y me he tirado 2 horas revisando la config de Apache, la de mod_gzip, bajando otro módulo más reciente, revisando decenas de páginas en google, y siempre me pasaba lo mismo: no comprimía (siempre le pedía la página principal). Sospecho de alguna interacción rara entre mod_gzip y mod_perl.

En todo caso, el caso de www.kuro5hin.org es diferente. Alli funcionan con un proxy inverso por delante de la máquina con Scoop, y es este proxy inverso el que hace la compresión con mod_gzip, así que allí si que se comprimime la portada también.

Saludos. Iñaki.

[ Padre ]


 
RSS Reader para Firebird/Firefox (none / 0) (#14)
por jcantero (jcantero@agujero-negro.escomposlinux.org) a las Sun May 23rd, 2004 at 11:02:34 AM CET
(Información Usuario) http://www.escomposlinux.org/jcantero/

Je, tu mensaje me ha motivado a echar un vistazo para ver si había salido alguna nueva herramienta de lectura de RSS, y me he encontrado en el Wiki de la Blogosfera con el RSS Panel Reader para Firebird (0.7) y Firefox (0.8). Muy fácil de instalar y configurar, y sólo hace peticiones --salvo que lo configures de otro modo-- cuando tú le digas. ¿Alguien más lo ha probado?

--
"Papá, ¡Internet es más que una red pornográfica global!" -- Lisa Simpson


 
A favor de la sindicación (none / 0) (#15)
por RinzeWind (chema AT sl-form DOT com) a las Sun May 23rd, 2004 at 10:10:16 PM CET
(Información Usuario) http://chema.sl-form.com

Pero con un poquito de control, como todo. Yo tengo ahora mismo sindicados (entre blogs y sitios de noticias) unas 60 webs. Lógicamente no me voy a pasar todos los días por ellas para ver si se han actualizado (ni siquiera tengo la mayoría en mis bookmarks. Si quiero monitorizar alguna, la añado al Liferea y a correr).

Lo único que hay que tener es un poco de sentido común y no recargar los feeds cada rato. Con una vez que se recarguen al día (que es lo que hago yo) va que arde. Algunos sitios incluso te niegan el acceso al feed si ven que abusas (creo que Slashdot lo hace si refrescas cada menos de media hora, aunque ahora mismo no recuerdo dónde vi eso).

--
Las Penas del Agente Smith


 
No me gustan la Sindicación (los RSS) | 15 comentarios (15 temáticos, editoriales, 0 ocultos)
Ver: Modo: Orden:

ecol Logo Powered by Scoop
Todas las Marcas Registradas y copyrights de esta página son propiedad de sus respectivos dueños.
Los comentarios son propiedad del que los escribe.
Los iconos de las noticias y el logotipo son propiedad de Javier Malonda.
El Resto © 2002 Escomposlinux.org y aledaños.

Puedes sindicar los contenidos de libertonia en formato RSS 1.0 y RDF 0.9. También se puede sindicar la cola de envíos pendientes de moderación.

El proyecto escomposlinux.org está dedicado a la memoria de tas

crear cuenta | faq | búsqueda