Probé varios sitios que transforman una página en un feed RSS, pero sin suerte, hasta que me crucé con Feedity, que te permite hacer un feed en cuestión de minutos, sin registros, y pudiendo personalizar los resultados si la configuración automática no te sirvió.

En mi caso, tuve que personalizar sólo una de las tantas páginas, ya que todas las demás funcionaron de una.

Si andan necesitando esto... visiten Feedity

Es decir, alguien envía un correo a micorreo@midominio.com, pero en realidad me llega a una cuenta de GMail, por ejemplo.

Como varias de estas cuentas las hice allá por el 2001 (fiu... como pasa el tiempo), las configuré para que la redirección se haga por medio de MyDomain, un servicio que en aquellas épocas era de lo mejorcito que existía.

El tiempo pasó, y parece que este servicio sufrió algunos inconvenientes de calidad... al punto tal de que el filtro de SPAM que tienen, suele agarrar prácticamente cualquier correo con adjuntos y considerarlo como no deseado.

Es por esto, que a partir de hoy, soy "MyDomain-Free", y he migrado mis aliases a otros servicios como ZoneEdit, que se viene comportando bastante bien con los últimos dominios que registré.

Si alguien tiene problemas con correos y está haciendo las redirecciones con MyDomain... tengan en cuenta este agujero negro de correo... una pena, pero bueno.

Leyendo un poco, me enteré de que la implementación de PulseAudio en Ubuntu fue algo más bien a las apuradas, y se dejaron muchas cosas en el tintero... por lo que el sistema de por sí no se lleva bien con este. Para la versión 9.04 se esperan mejoras... aunque esto es un deseo, más que un compromiso, claro.

Luego de leerme de "todo" por la web... me encuentro con una solución más drástica respecto al problema de PulseAudio en Ubuntu 8.10... sacarlo y usar ALSA.

La solución involucra una consola... aunque es bien fácil:

sudo killall pulseaudio
sudo alsa force-reload
Una vez que han hecho esto (no se asusten si ALSA les tira unos cuantos errores), van a Sistema > Preferencias > Sonido, y cambian todo a ALSA... y se olvidan de PulseAudio.

Vía Swik

Mi novia me dijo que su máquina estaba adelantada, y renegué por varios lados (BIOS, línea de comandos, cambiando manualmente, etc).

Recién me entero por Sebastián que hubo un problema con el paquete tzdata (alguien lo actualizó indebidamente, pasando a -02, en vez de -03 como debería estar).

La solución, por aquí. (el parche ha sido liberado por Margarita Manterola)

Más info aquí

He visto que este problema no tiene una buena solución cuando el usuario ya está registrado, ya que las formas implementadas para exigir que se 'cambie' la clave, son un tanto agresivas.
Por un lado, tenemos la petición de renovar la clave cada cierto tiempo. Esto presenta una mejora en seguridad, siempre y cuando el usuario no sea vago/descuidado, ya que supongamos que dicha advertencia le aparece a un usuario de este tipo cuando está apurado... ¿resultado? una clave débil que seguramente será usada para sacar provecho de la cuenta de ese pobre indefenso (esta implementación la he visto en varios sistemas de Home-Banking). También vale mencionar que es bastante molesto, que cada X días, al sistema se le ocurra pedirte que cambies la clave... ¿o no? (fuera de todo aspecto de seguridad... es como si la policía nos exigiera que cambiemos la llave de nuestra casa todos los meses, para evitar robos...).

Por otro lado, tenemos simplemente el aviso de renovar la clave, lo cual suele pasar como "parte" del entorno... ya que nadie lo lee. En este caso, se puede mejorar la idea (lo cual no asegura efectividad), dándole un color (siempre el mismo color, no se me pongan creativos, que luego parece un circo) que resalte al mensaje que estamos intentándole dar al usuario, y que este mensaje solo se muestre en pantalla que no estén involucradas en el medio de una transacción... solo al inicio, o al final de esta. Un ejemplo de como no implementarlo... es poner el aviso de cambio de clave durante un proceso "crítico" -para el usuario-, como efectuar un pago (introduciendo clave, numero de tarjeta, etc). Aunque si podemos implementarlo en las pantallas de menú, o aquellas en donde el usuario esté más tranquilo.

Luego, tenemos los intentos más acertados, los que apuntan a solucionar el problema de raíz (que no están exentos de problemas, aunque minimizan la responsabilidad del administrador del sistema).

Uno de estas formas, es permitir que el usuario elija su contraseña -en el formulario de registro-, lo cual puede convertirse en un serio problema de seguridad para él, si el usuario es vago/descuidado (es el más utilizado).

Otra forma, es sugerir al usuario una contraseña, la cual puede parecer mágica, ya que nosotros como administradores estaremos contentos de que el usuario tendrá una contraseña "fuerte", aunque visto desde el lado del usuario, puede ser inseguro (¿por qué el sistema me sugiere una clave?), y hasta molesto (¿por qué me eligió una clave tan complicada?).

La tercera forma, es muy similar a la primera, ya que consiste en permitir que el usuario elija su contraseña, la primera vez que va a ser uso del servicio. Como habrán notado en este caso, la petición de contraseña no está dada en el registro mismo, sino en el primer encuentro que el usuario tiene con el sistema.

Esta última forma, se puede implementar de dos maneras... una es otorgando al usuario una clave blanca (es decir, vacía), cosa de que cuando haga su primer conexión al sistema, se encuentre con la petición de poner una clave (lo cual puede ser inseguro, si alguien se entera que tal o cual usuario se registró); mientras que la otra es brindarle un enlace para su primera conexión, de modo que en dicho enlace vaya un parámetro de código -aleatorio- (que deberá ser guardado como un campo más en la tabla de usuarios, para verificar luego que sea el mismo)., cosa que no se presente la falla de seguridad anteriormente mencionada en este párrafo (que alguien pruebe y encuentre un usuario nuevo, tomando posesión de la cuenta de este).

El problema es que no siempre podremos brindarle un enlace a un usuario para su primera conexión, dado que el sitio puede estar protegido por .htaccess y la generación de clave "en manos" del usuario es un tanto compleja (dado que el usuario aún no tiene clave, debería ingresar por medio de una página que está fuera de la protección del htaccess, haciendo débil esa parte del sistema); o bien que el sitio se encuentra en una Intranet, por lo que ingresando en el enlace desde fuera de la misma, caemos en la nada. Para estos casos, las otras medidas deberían ser tomadas en cuenta, intentando identificar al usuario medio... ya que si este suele ser vago, entonces deberemos evitar todo intento de complicarle su vida (digamos, que tenga que pensar demasiado).

Para ir cerrando, a modo de prueba, en un sistema basado en Joomla, se modificó el código de cambiar contraseña, para que guarde en un archivo de 'log' cuantos cambio ha habido. En un año, y con más de 190 usuarios, solo se cambió una clave... (¿más triste? fue la mía, de Administrador... para probar si funcionaba el log).

Lamentablemente, si queremos velar por la seguridad de nuestros usuarios, debemos enseñarles los problemas que trae la (in)seguridad, o bien, buscar formas de hacerles vivir en un paraíso donde la seguridad misma reine por si sola

Lo normal hubiese sido avisarle que podía haber sido víctima de una trampa, pero mi cerebro se puso a pensar en como solucionar el problema... lamentablemente (cuando una idea se me mete en la cabeza, esta difícil que salga... y encima dicen que soy cabezón, así que peor jejej).

Actualmente, estos servicios gratuitos de correo (Hotmail, Yahoo! Mail, GMail, etc), implementan APIs (no todos) que permiten a otros sitios hacer uso de tu lista de contactos, para que puedas invitar "fácilmente" a otros usuarios.

El problema está, en que tenemos que ingresar un usuario y clave, y eso puede o no ser capturado por el sitio que está tratando de hacer la invitación. En el mejor caso, no pasará nada, pero en el peor... podemos llegar a ser víctimas de una trampa, y terminar perdiendo nuestros correos o directamente nuestra cuenta (si cambian la clave o solicitan su eliminación).

Acá tiene tanto culpa el usuario, como la empresa que está de cada uno de esos servicios, ya que el primero es suficientemente "tonto" para caer en la trampa, y las segundas son suficientemente "vagas" como para implementar una solución "segura".

Todas las soluciones que me pasan por la cabeza, son un tanto incómodas para el usuario, pero si analizamos la incomodidad de copiar y pegar cada contacto, en relación a una "mediana" incomodidad, pasamos al frente.

Veamos algunos ejemplos:

• Al momento de completar los datos en el sitio X sobre nuestra cuenta, solo debería pedirnos el "usuario". Una vez que envíamos dicho dato, el sistema nos debería avisar que tenemos que abrir nuestra casilla de correo para confirmar la solicitud. Por lo que una vez que ingresamos con nuestro usuario y clave al "sitio de la casilla de correo" (o sea, no a un sitio de terceros posiblemente inseguro), este nos avisaría de que tenemos una solicitud del "sitio X" que está necesitando acceso a "nuestros contactos" o "nuestro calendario" (o lo que sea). De esta forma, una vez que aceptamos... el sitio recibe la autorización (que tendría una vigencia temporal de N minutos), y luego se revoca dicho permiso para que no pueda hacer uso más de nuestros datos.
• Otra forma, sería que al momento de ingresar a nuestra casilla de correo, podamos activar temporalmente el uso de, ya sea, nuestros contactos, calendario, etc... pero ingresando una clave de al menos N dígitos generada por el sistema. De este modo, al ir al "sitio X", este nos solicitaría nuestro usuario y dicha clave generada, evitando así que este reciba datos sobre nuestra clave real del usuario. El acceso, nuevamente, sería temporal... y limitado a los datos que permitimos en nuestro correo.

Aplicando alguno de estos simples métodos, eliminaríamos gran parte de las trampas que existen en la web, y que permiten el robo de cuentas de correo fácilmente (con las consecuencias que eso puede traer).

En este caso, como dije anteriormente, debemos tener en cuenta de que estamos dejando de lado un poco el aspecto de facilidad, para hacer hincapié en la seguridad.

En fin, tenía que dejarlo escrito... es algo que no puedo implementar por mi cuenta, por lo que no me molestaría que una empresa lo ponga en vigencia... siempre y cuando sea para el bien de todos.

Si sos Blogger, usas Firefox y usas la excelente extensión ScribeFire, seguramente te vas a encontrar con problemas a la larga, debido a su sistema de respaldo de entradas que vas escribiendo.

A medida que escribimos, la extensión va guardando información cada 5 o 10 segundos (no sabría asegurar el timing correcto), lo que provoca en discos lentos y ocupados, una especie de demora.

En mi caso, estoy escribiendo y veo que de a ratos el texto en pantalla se desfasaba con lo que yo iba tipeando (y tan rápido no soy como para ganarle a una máquina de ese modo, jeje).

El problema, luego de ponerme a medir varios registros y demas del sistema (pensé que era algo de Firefox y/o de algún proceso en Cron, pero no encontré nada por allí), es que el archivo en donde se van guardando las "notas", es actualizado de forma constante... y en él, incluso se guardan las entradas viejas que hayas decidido almacenar.

En mi caso, el archivo pesaba unos 10 MB, y dado que en cada guardado vuelca la información de la extensión por completo (eso implica escribir 10MB en el disco), en una máquina ocupada (1GB de RAM, pero con GIMP, Firefox 3, Konqueror, Amarok y Pidgin funcionando)... implica un gran parate.

En fin, la solución está en renombrar el archivo performancing-notes.xml, que se encuentra en la carpeta de extensiones de tu perfil de Firefox, para que este se regenere vacío.

Otra opción, sería borrar todas las entradas, pero así perderíamos información valiosa sobre entradas que hayamos guardado en el sistema, por lo que en mi caso no lo considero una opción

Espero que le sea útil a alguien