Elucubrando

Algo que añadir a la colección de datos inútiles.

Hace tiempo me quejaba de los que creen que brincando juntos podríamos modificar la órbita de la Tierra. Esa vez calculé que toda la gente del planeta junta pesa menos de 10¹¹ Kg.

Pues bien, dice Cecil Adams, en The straight dope, que ‘se dice que la totalidad del oro que ha sido minado cabría en un cubo de 18 yardas por lado’. Ojo, esto es todo el oro minado en toda la historia de la humanidad.

No sé si eso sea cierto, pero supongamos que sí. 18 yardas son 1645.92 cm. El oro pesa (a temperatura ambiente) 19.3 g/cm³. Entonces, un cubo de oro de ese tamaño pesa 86056459.9 Kg que, para simplificar, redondeo a 10⁸ Kg.

Ahora, si todos brincaramos desde un metro de altura hacia el suelo, llegaríamos (ignorando la resistencia del aire y otras variables incómodas) a éste a 4.419 m/s, de modo que si aplicaramos toda esta fuerza al cubo de oro (usando por ejemplo un gran sube y baja) lo aceleraríamos a 4419 m/s. La velocidad de escape de la tierra es de 11.2 kilómetros por segundo. O sea que ni siquiera podríamos poner en órbita al cubo ese, sino que sólo se alzaría como 1 Km y luego volvería a caer. Lo que sí es que haría bastante ruido al llegar al piso.

(Corrección) Leyendo un poco más en el artículo de Wikipedia acerca del oro me encuentro con que estiman que la producción total de oro del mundo es de 145000 toneladas. Es decir mas o menos el doble de lo que estime aquí. Eso quiere decir que

• El cubo no subiría un kilometro, sino solamente poco menos de medio, y
• No medriría 18 yardas sino más o menos 22.5. (Poco más de 20 m.)

Me divierto haciendo esta clase de cosas. ¿Soy un geek o qué?

Me acabo de enterar hace rato que muchas de las facturas para nuestros clientes las enviamos por correo. Sí, esa cosa antigua con sobres y timbres. Y no sólo llegan. Lo hacen pronto y barato y los clientes están contentos y nosotros recibimos confirmación de que las recibieron y no sé que tanto más.

Estoy anonadado y patidifuso.

Van ya varias veces, en IRC, en blogs, en las listas de correo, que me encuentro con gente que dice cosas como ‘Es que yo soy un novato, apenas llevo n años con Linux’. Para valores de n entre 5 y 7. ¿Soy acaso muy soberbio, que me empecé a considerar bueno a los 3 y experto como a los 5? ¿A quien considerarían ellos un guru? ¿Ken Thompson? ¿O ni a él?

Como parte de la gran campaña Nul Unu para la mejora de los procesos (hola, Daniel), acabo de instalar un depósito central de subversion y una instalación generica de Trac para los proyectos. La intención es

• Tener un control de los problemas y faltantes por cada proyecto.
• Tener un punto central para la documentación.
• Coordinar estas cosas con el control de versiones.

Ahora bien, como en cada proyecto participan diferentes personas, necesito tener controles de acceso más o menos finos. Y sería bueno que dichos controles estuvieran coordinados entre subversion y Trac. Entonces, documentando para la posteridad, a continuación mis elecciones de configuración para lograr eso:

1. Todo debe quedar, por supuesto, en un servidor público. Por razones de llevarse bien con el proveedor, nuestro servidor usa RedHat. Enterprise 4, creo.
2. Los controles de acceso finos requieren, o que use subversion via Apache, o svnserve pero con subversion 1.3. Usar apache significa darle permisos de leer y escribir en el depósito al usuario apache. En un servidor con mucho PHP. Eso es una muy mala idea, así que nos vamos por svn1.3. Como RHES4 tiene 1.1.algo, tenemos que instalarlo aparte. Afortunadamente para mi salud mental, alguien ya hizo paquetes de subversion, así que nada de andar compilando e instalando a mano.
3. El punto malo de svnserve es que el protocolo no tiene opción para cifrar la comunicación. Hay dos formas de darle la vuelta a esto. O usamos svn+ssh, o usamos stunnel para encapsular el protocolo. Por ahora me fuí con stunnel, pero los métodos no son exclusivos, así que si veo que eso causa problemas intentaré lo del ssh. (¿Problemas, se preguntan? Pues sí, por que usar stunnel requiere que se configure en ambos extremos. Mi experiencia me dice que pedirle a personas externas que lo hagan en sus propias máquinas puede ser complicado. Por otro lado, ssh requeriría que configuren el acceso usando llaves públicas.)
4. Hecho esto, genero un archivo de usuarios/contraseñas, lo pongo en un lugar accesible al svnserve y refiero la configuración de todos los depósitos a ese mismo. ¡Autenticación centralizada!
5. Lo cual nos lleva al “todos los depósitos”. En realidad, en vez de colocar un depósito central, coloqué infraestructura para poner fácilmente un depósito por proyecto, accesibles todos con URLs similares. Eso permite controlar más fácilmente el acceso si hay situaciones especiales. Permite también simplificar la creación de respaldos y permite eliminar depósitos que se dejen de usar.
6. Todos los depósitos se crearán usando fsfs y no db. Tiene un manejo más sencillo de los permisos.
7. Ahora, Trac. Para esto no hay RPMs, así que hay que instalar a mano. Afortunadamente checkinstall nos permite generar un paquete que enlista lo que fué instalado. Antonces, aunque queden paquetes medio feos, sin dependencias y sin adecuarse muy bien al sistema, por lo menos hay un registro de qué se instaló dónde y como quitarlo.
8. Usamos SQLite como base de datos. Más fácil de instalar y respaldar que usar PostgreSLQ. Y de cualquier forma, no creo que vayamos a tener en esta infraestructura proyectos con miles de bugs o algo así.
9. La comunicación de Trac con el mundo está por ahora, con FastCGI. Pero esto tiene el problema de que obliga a darle al usuario de apache permiso de lectura a los depósitos de svn y de escritura a los de trac. Para evitar eso, próximamente(MR), cambiaremos a usar tracd corriendo como un usuario con privilegios reducidos, y lo expondrémos al mundo via mod_proxy.
10. Trac no lo vamos a colocar tras https. Eso hace difícil colocar todo tras un dominio virtual. Entonces, para por lo menos no andar mandando contraseñas en claro, usamos autenticación ‘Digest’. Las contraseñas para este método se guardan cifradas con MD5, mientras que las de subversion están en texto claro. Entonces declaramos la lista de subversion como la maestra y generamos la de apache a partir de ahí.

Puntos a revisar:

1. Todavía no acabo de entender los puntos finos de la autorización en svnserve. Y al parecer hay algunos bugs extraños en la implementación. Sería bueno que se pudieran incluir secciones comúnes.
2. Hace falta diseñar e implementar un mecanismo para los respaldos. Hay que determinar la frecuencia y cuanto tiempo queremos guardarlos.

Dice la jornada que Censor ayuda a paralíticos a mover cosas con sólo pensarlo Bueno, si en medio de andar buscando pensamientos prohibidos van a ayudar a la gente, pasan de la categoría de peligrosos e inútiles a la de simplemente peligrosos.

No estamos, por lo menos algo así como 14.9 millones de mexicanos, contentos con las elecciones. Y no me refiero al resultado, sino a como fueron llevadas. Pero no voy a explicar yo el porque, puesto que mi formación no es la suficiente para articularlo con claridad, así que cedo la palabra a Muñoz Ledo, en editorial del Universal:

Derecho al sufragio

Uno de los objetivos de DebConf es motivar a la gente a que participe en Debian. Pues bien, con orgullo reporto un caso de éxito:

http://qa.debian.org/developer.php?login=rodrigo@nul-unu.com