viernes, 7 de junio de 2013
lunes, 6 de febrero de 2012
Six Degrees of Separation
Seis Grados de Separación.
Vivimos en un mundo pequeño ..... ..... .... ¿vivimos en un mundo pequeño?"
A raíz de un experimento del año 1967 del psicólogo Stanley Milgram, surge este "mito urbano" de los seis grados de separación.
Desde 2011, se intenta reflotar el experimento (de convocatoria abierta), utilizando las actuales tecnologías aplicadas a las relaciones sociales:
Agradezco la iniciativa y la posibilidad de participar. Sin embargo estoy convencido de que hay otras herramientas más rigurosas para, en el marco de la comunidad Facebook sola y exclusivamente, probar los "seis grados de separación".
Una de las principales críticas que le hago al "remake" del experimento, es que se trata de hacer el mismo sin realizar un solo cambio a la estrategia. La tecnología da oportunidades: no solamente un entorno promueve el desarrollo de una herramienta, sino que también una nueva herramienta promueve un nuevo entorno: "qué puedo hacer con esta nueva herramienta?". El caso más típico y que más me gusta citar es el del rayo láser en la década del 60: "la solución a la espera de un problema".
En esta nueva versión del "small world", se reemplazan las cartas por el correo electrónico o la red social. La decisión que hace un participante en cuanto a quién es, dentro de su círculo de amigos, el candidato para conocer o estar más relacionado a la persona objetivo, continúa siendo una elección con un alto contenido de incertidumbre. Además: para verificar la teoría, se necesitan las "personas objetivo"?
El experimento resulta altamente intrigante y despierta la curiosidad. ¿No es hora de replantear la estrategia, de cambiar de paradigma? Qué se le hubiera ocurrido a Stanley Milgram si contara con la tecnología actual?
Precisamente, más allá de métodos analíticos que se podrían desarrollar para confirmar la hipótesis por "comprensión" (no me imagino cómo); simplemente con las api de FB (con su base de datos) y sin siquiera pertenecer al staff de la organización, es posible verificarlo por extensión, por exhaustividad, por "fuerza bruta".
Por supuesto que hay cuestiones de escala, seguridad y privacidad que están involucradas, y que hacen que a priori no sea posible realizar el proceso.
Probar todos los caminos posibles puede llegar a ser costoso computacionalmente. Más allá de eso, hay disponibles y de dominio público muchos algoritmos de recorrido de grafos que, junto con reglas que se puedan agregar y que brinden certeza de que no es necesario continuar por una cierta rama por ejemplo, permiten confirmar esta hipótesis para la "foto", es decir, para los datos tal cual se encuentran al momento de ejecutar el experimento.
El desarrollador que desea ahondar más en este tema, lo primero que tiene que hacer es investigar las herramientas que FB provee para acceder a su base de datos, especialmente en lo que refiere a políticas de privacidad. Por ejemplo, dada una persona, para obtener su lista de amigos, los mismos tienen que ser conscientes de la aplicación que se desarrolle para incluirlos en el recorrido del grafo de relaciones: eso implica al menos que aprueben la aplicación o que la incluyan dentro de su lista de aplicaciones. Así presentado parece que las restricciones de privacidad ya son un obstáculo inicial importante. De todos modos vale la pena continuar investigando.
Por supuesto que las políticas de privacidad de los desarrolladores "in company" (dentro de FB) seguramente que son otras y quizá no sean un obstáculo: en ese caso ya se podría pensar en el recorrido y por ejemplo en certificar el resultado a través de alguna entidad en la cual se confíe para no tener que publicar los datos en la verificación.
El debate de este "divertimento" queda abierto.
Pablo
viernes, 8 de abril de 2011
20th Anniversary of Linux
Linus:
Hello everybody out there ...
I'm doing a (free) operating system
(just a hobby, won't be anything big and professional like gnu) ...
it probably will never support anything other than AT-hard disks, as that's all I have ...."
miércoles, 22 de diciembre de 2010
Cerebro
"El cerebro es un órgano maravilloso. Comienza a trabajar apenas nos levantamos y no deja de funcionar hasta entrar en la oficina" (gracias Robert Frost)
domingo, 23 de mayo de 2010
Facebook chat a través de Pidgin
Facebook actualmente tiene soporte para el protocolo XMPP de chat, así que no es necesario agregar plugins ni nada por el estilo en Pidgin para conectarse a ese servicio de mensajería.
Los pasos pueden seguirse desde este link:
http://www.howtogeek.com/howto/12527/easily-add-facebook-chat-to-pidgin/
Tener en cuenta dos cosas:
1) Está en inglés
2) Tuve que deshabilitarle el requerimiento de SSL/TLS (al revés de como indica en los pasos) ya que el servidor responde que no admite cifrado (tener en cuenta por lo tanto que el intercambio de datos es sin cifrar).
Si no se desea seguir los pasos, simplemente basta tener en cuenta que se configura como una cuenta clásica XMPP y que el servidor es chat.facebook.com
Los pasos pueden seguirse desde este link:
http://www.howtogeek.com/howto/12527/easily-add-facebook-chat-to-pidgin/
Tener en cuenta dos cosas:
1) Está en inglés
2) Tuve que deshabilitarle el requerimiento de SSL/TLS (al revés de como indica en los pasos) ya que el servidor responde que no admite cifrado (tener en cuenta por lo tanto que el intercambio de datos es sin cifrar).
Si no se desea seguir los pasos, simplemente basta tener en cuenta que se configura como una cuenta clásica XMPP y que el servidor es chat.facebook.com
miércoles, 30 de diciembre de 2009
Backup
La gestión de backups o copias de seguridad es una actividad a planificarse a medida de la organización que la requiere a fin de obtener el objetivo esperado con el mínimo costo.
Estas son algunas pautas a tener en cuenta:
Seguridad de la información digital.
Cuando se habla de "seguridad de los datos", hay que tener en cuenta que la misma abarca dos aspectos:
* Por un lado, la confidencialidad. Esto es: cuáles son las medidas de seguridad o políticas para asegurar una libre disponibilidad de la información pero sólo a los niveles de recursos humanos indicados. Por ejemplo que ciertos datos no puedan estar disponibles fuera de la organización, o que aún dentro de la organización ciertos recursos estén disponibles sólo para un grupo de personas.
* Por otro lado, la integridad. Esto abarca todas las políticas para evitar pérdida de datos o pérdida de valor de los datos (datos corruptos).
Este documento sólo se ocupa de este último aspecto.
Velando por la integridad de la información digital.
Políticas para asegurar la integridad de la información.
Si las políticas de backup no se planifican formalmente, resultan en una pérdida de tiempo y dinero. A continuación algunos ejemplos:
Casos típicos de informalidades que llevan al fracaso de la política de backup:
. El encargado de sistemas de una organización deja una tarea programada que diariamente copia los datos originales a un repositorio de backup (pc con disco rígido con espacio suficiente para recibir la copia). Esos datos pueden ser: documentos, bases de datos, etc.
. Problemas:
. un empleado quiere un dato que había hace tres días porque le hizo cambios y ahora los quiere volver atrás: pero sólo se tiene una copia del último día.
. Ocurre un robo en el edificio y no sólo que se llevan las computadoras con las copias originales, sino que también se roban la pc con el backup.
. Ocurre un error en un disco y se recurre al backup pero en ese momento se dan cuenta que en el horario de la tarea programada de backup la pc repositoria se encontraba apagada (hace 1 mes que no se deja más prendida esa pc).
. Ocurre un borrado accidental de un documento y se recurre al backup pero hace un mes que la pc repositoria ha cambiado de nombre por lo tanto la tarea programada se ejecuta con errores.
. Se rompe el servidor principal y hay que cambiarlo. Se dispone del backup y se puede hacer una reconstrucción del mismo: comprar un nuevo servidor, instalarle el software de base, las aplicaciones y restaurarle los datos demora al menos 72 horas: pero la organización necesita que dentro de quince minutos esté disponible el servidor nuevamente.
. Se rompe un equipo y hay que restaurar su información. Se recurre al backup y el mismo existe, pero al momento de restaurar la información por alguna razón el backup no puede ser restaurado: el proceso de restauración da errores o algunos documentos no se encuentran en el backup.
. Ocurre un borrado accidental, se recurre al backup pero los datos borrados son de un proyecto nuevo que comenzó luego de haber planificado el backup y por lo tanto el proceso de copia no contemplaba esos nuevos datos.
Pautas a tener en cuenta para evitar lo anterior:
. Normalmente no es suficiente mantener una "foto" de la información al último día. Puede ocurrir que se necesite un dato que estuvo disponible hace diez días. Para eso se debe resguardar el estado de los datos de los últimos n días. Cuanto más días se resguarden, más complejo será el proceso (de backup y de recuperación) pero se dispondrá de más chances de recrear el estado perdido. Afortunadamente para hacer más eficiente ese proceso, minimizando recursos necesarios, desde hace muchos años que hay modelos, procedimientos y herramientas disponibles como por ejemplo los modelos incrementales (ver http://es.wikipedia.org/wiki/Copia_de_seguridad).
. La copia de seguridad debe encontrarse geográficamente distante: si ocurre un fenómeno natural o un robo, probablemente se pierdan tanto los datos originales como los de respaldo (es decir que se deben tener en cuenta los imponderables naturales y sociales además de los técnicos). Debe considerarse un procedimiento que automática o manualmente asegure que los datos se encuentren fuera del edificio en otra área confiable. Pueden ser procesos de copia remota o que una persona responsable reciba recordatorios periódicos para trasladar la información.
. Auditoría!! Las copias de seguridad pueden no encontrarse como se sospecha. Es muy importante que la política incluya un responsable que reciba un recordatorio para que a intevalos regulares busque el backup, lo restaure y se asegure de que ante un imponderable en ese backup se van a poder obtener los datos necesarios sin inconvenientes.
. Tolerancia a fallos / recuperación ante desastres: muchas veces no es suficiente con disponer del backup sino que es necesario asegurar una recuperación en un tiempo máximo. Por ejemplo cuando se trata de un servidor de misión crítica, como puede ser una base de datos para facturación a clientes, habrá que asegurar que si ocurre un desastre con el servidor, en una hora el problema esté resuelto. Para ello se recurre a diferentes modelos:
. la tolerancia a fallos asegura, normalmente con redundancia de recursos, directamente evitar el inconveniente, que el mismo no ocurra (por ejemplo que un equipo cuente con dos fuentes de alimentación, con dos discos rígidos con la misma información, etc).
. la alta recuperación ante desastres normalmente hace uso de servidores idénticos disponibles en todo momento y ante la falla de uno se continúa con el otro que venía siendo impactado con las mismas novedades que el servidor original de manera simultánea.
Planificando la seguridad
En defintiva, con mínimas pautas es posible mejorar notablemente la confiabilidad del backup. En la mayoría de los casos no es necesario invertir más dinero: los recursos para copia de seguridad se encuentran y a menudo en exceso. Lo que normalmente falta es organizar esos recursos para poder aprovechar su utilización de manera eficiente y a largo plazo.
Estas son algunas pautas a tener en cuenta:
Seguridad de la información digital.
Cuando se habla de "seguridad de los datos", hay que tener en cuenta que la misma abarca dos aspectos:
* Por un lado, la confidencialidad. Esto es: cuáles son las medidas de seguridad o políticas para asegurar una libre disponibilidad de la información pero sólo a los niveles de recursos humanos indicados. Por ejemplo que ciertos datos no puedan estar disponibles fuera de la organización, o que aún dentro de la organización ciertos recursos estén disponibles sólo para un grupo de personas.
* Por otro lado, la integridad. Esto abarca todas las políticas para evitar pérdida de datos o pérdida de valor de los datos (datos corruptos).
Este documento sólo se ocupa de este último aspecto.
Velando por la integridad de la información digital.
Políticas para asegurar la integridad de la información.
Si las políticas de backup no se planifican formalmente, resultan en una pérdida de tiempo y dinero. A continuación algunos ejemplos:
Casos típicos de informalidades que llevan al fracaso de la política de backup:
. El encargado de sistemas de una organización deja una tarea programada que diariamente copia los datos originales a un repositorio de backup (pc con disco rígido con espacio suficiente para recibir la copia). Esos datos pueden ser: documentos, bases de datos, etc.
. Problemas:
. un empleado quiere un dato que había hace tres días porque le hizo cambios y ahora los quiere volver atrás: pero sólo se tiene una copia del último día.
. Ocurre un robo en el edificio y no sólo que se llevan las computadoras con las copias originales, sino que también se roban la pc con el backup.
. Ocurre un error en un disco y se recurre al backup pero en ese momento se dan cuenta que en el horario de la tarea programada de backup la pc repositoria se encontraba apagada (hace 1 mes que no se deja más prendida esa pc).
. Ocurre un borrado accidental de un documento y se recurre al backup pero hace un mes que la pc repositoria ha cambiado de nombre por lo tanto la tarea programada se ejecuta con errores.
. Se rompe el servidor principal y hay que cambiarlo. Se dispone del backup y se puede hacer una reconstrucción del mismo: comprar un nuevo servidor, instalarle el software de base, las aplicaciones y restaurarle los datos demora al menos 72 horas: pero la organización necesita que dentro de quince minutos esté disponible el servidor nuevamente.
. Se rompe un equipo y hay que restaurar su información. Se recurre al backup y el mismo existe, pero al momento de restaurar la información por alguna razón el backup no puede ser restaurado: el proceso de restauración da errores o algunos documentos no se encuentran en el backup.
. Ocurre un borrado accidental, se recurre al backup pero los datos borrados son de un proyecto nuevo que comenzó luego de haber planificado el backup y por lo tanto el proceso de copia no contemplaba esos nuevos datos.
Pautas a tener en cuenta para evitar lo anterior:
. Normalmente no es suficiente mantener una "foto" de la información al último día. Puede ocurrir que se necesite un dato que estuvo disponible hace diez días. Para eso se debe resguardar el estado de los datos de los últimos n días. Cuanto más días se resguarden, más complejo será el proceso (de backup y de recuperación) pero se dispondrá de más chances de recrear el estado perdido. Afortunadamente para hacer más eficiente ese proceso, minimizando recursos necesarios, desde hace muchos años que hay modelos, procedimientos y herramientas disponibles como por ejemplo los modelos incrementales (ver http://es.wikipedia.org/wiki/Copia_de_seguridad).
. La copia de seguridad debe encontrarse geográficamente distante: si ocurre un fenómeno natural o un robo, probablemente se pierdan tanto los datos originales como los de respaldo (es decir que se deben tener en cuenta los imponderables naturales y sociales además de los técnicos). Debe considerarse un procedimiento que automática o manualmente asegure que los datos se encuentren fuera del edificio en otra área confiable. Pueden ser procesos de copia remota o que una persona responsable reciba recordatorios periódicos para trasladar la información.
. Auditoría!! Las copias de seguridad pueden no encontrarse como se sospecha. Es muy importante que la política incluya un responsable que reciba un recordatorio para que a intevalos regulares busque el backup, lo restaure y se asegure de que ante un imponderable en ese backup se van a poder obtener los datos necesarios sin inconvenientes.
. Tolerancia a fallos / recuperación ante desastres: muchas veces no es suficiente con disponer del backup sino que es necesario asegurar una recuperación en un tiempo máximo. Por ejemplo cuando se trata de un servidor de misión crítica, como puede ser una base de datos para facturación a clientes, habrá que asegurar que si ocurre un desastre con el servidor, en una hora el problema esté resuelto. Para ello se recurre a diferentes modelos:
. la tolerancia a fallos asegura, normalmente con redundancia de recursos, directamente evitar el inconveniente, que el mismo no ocurra (por ejemplo que un equipo cuente con dos fuentes de alimentación, con dos discos rígidos con la misma información, etc).
. la alta recuperación ante desastres normalmente hace uso de servidores idénticos disponibles en todo momento y ante la falla de uno se continúa con el otro que venía siendo impactado con las mismas novedades que el servidor original de manera simultánea.
Planificando la seguridad
En defintiva, con mínimas pautas es posible mejorar notablemente la confiabilidad del backup. En la mayoría de los casos no es necesario invertir más dinero: los recursos para copia de seguridad se encuentran y a menudo en exceso. Lo que normalmente falta es organizar esos recursos para poder aprovechar su utilización de manera eficiente y a largo plazo.
Suscribirse a:
Entradas (Atom)