One liners (14): sacar un número decimal de /dev/random en bash

 

1
head -c 1 /dev/random | od -An -td
  • head -c 1 /dev/random: Lee un solo caracter de /dev/random.
  • od -An -td: od suele usarse para mostrar los valores octales de un archivo (de ahí octal dump), con -An indicamos que no queremos que se muestre el offset, y con -td hacemos que se muestre en decimal.

Diccionarios a lo Javascript en Python

Los "diccionarios" en javascript tienen una propiedad curiosa, que se pueden manejar los elementos como si fuera un array índicando el índice (con una variable) o como si fuera un atributo del objeto:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
> var x = {}
> x
{}
> x.name = "joe"
'joe'
> x
{ name: 'joe' }
> x['name']
'joe'
> x.name
'joe'
>

En python los diccionarios no tienen esa propiedad, pero es fácil de hacer una clase que sí, apoyandose en que cada objeto tiene un diccionario interno, self.dict que almacena sus atributos, jugando con él (al menos si no nos metemos con los atributos que define la clase :P)...

`true` o `false`, cuantas variaciónes son posibles?

true y false son comandos unix que al ejecutarlos simplemente se finalizan con código 0 y 1 respectivamente, algo que suele significar que hayan acabado correctamente (0) y haber fallado (no 0).

Cuanta diferencia puede haber entre el código en distintas implementaciones? No mucha verdad?, al fin y al cabo es más simple que un Hola mundo. Pues tiene gracia la cosa =) ...

(Sin ningún órden en concreto)

GNU: escrito en C, jugando con el preprocesador, ¿por que no?.
true.c (78 líneas)
false.c (2 líneas)
80 líneas físicas, SLOCCOUNT: 52

OpenBSD: en bash, un simple exit.
true.sh (3 líneas)
false.sh (3 líneas)
6 líneas físicas, SLOCCOUNT: 2

FreeBSD: en C, la mitad es licencia :P .
true.c (46 líneas)
false.c (46 líneas)
92 líneas físicas, SLOCCOUNT: 28

Solaris: en C, lo siento, no alcanzo a comprender a que viene _exit() y después return() ¿?.
true.c (41 líneas)
false.c (41 líneas)
82 líneas físicas, SLOCCOUNT: 16

Busybox: en C, no encontré un repo con los archivos en texto plano, hay que verlos .

Fin del CUSL, resultados con BLK

Al parecer, a menos que haya entendido mal, el Concurso Universitario de Software Libre de este año toca a su final, ha sido divertido, he aprendido mucho y me haría falta valgrind para recordar todos los leaks de horas de sueño.

Realmente no hay mucho que decir, el proyecto se estancó demasiado (sobretodo cada vez que había que implementar el endemoniado preprocesador de C xD), mucho más atrás de lo esperado. Aún así tengo pensado seguir trabajando, la experiencia no ha hecho más que confirmar que una herramienta para experimentar con estas cosas sería útil, sobretodo si algo muy básico requiere tanto tiempo.

Sobre el desarrollo en sí, el estado actual es bastante penoso (a estas alturas contaba con tener ya orientación a objetos, iluso de mi :P), el intérprete se porta relativamente bien, pero el único parser de C que a duras penas funciona es el de la rama de prototipado (una explicación de el árbol de proyecto, las ramas y tal en el

Una red P2P para compartir enlaces

La historia

Año 2012, los habitantes de Internet han desarrollado herramientas para distribuir información entre redes de pares, desde los enormemente extendidos (eDonkey y BitTorrent) a otros algo menos, de los que solo se preocupan de repartir información a los que se centran comprometer lo mínimo a los extremos (GNUnet y Freenet), de los que solo distribuyen archivos a los que conforman una capa sobre la que se pueden erigir otros protocolos (I2P).

Se han llegado a encontrar formas de coordinar toda esa nube de máquinas de forma distribuida, sin puntos centrales, con Tablas hash distribuidas. Incluso se ha conseguido llegar a una forma de identificar la forma de alcanzar la información con la llegada de los enlaces magnéticos que permitian representar un archivo en una de estas redes.

Queda dicho

Leyendo Mimi and Eunice me encontré esto:

Mimi and Eunice

  • Te denuncio por robar los potenciales beneficios de mi cliente.
  • Eso tiene sentido potencial.
  • Aquí tienes cien mil potenciales dólares.

One liners (13): sacar un número de urandom en python

 

1
reduce(lambda x, y: x * 256 + y, map(lambda x: ord(x), os.urandom(1024)))
  • os.urandom(1024) Lee 1024 bytes de urandom.
  • map(lambda x: ord(x), ...) Convierte la cadena en un array con los valores de los caracteres.
  • reduce(lambda x, y: x * 256 + y, ...) Junta los bytes respetando el valor dado por la posición.

Regreso al pasado en el juego de la vida

La mente es algo bien curioso, intenta obligarla a prestar atención durante un rato largo a algo tan estimulante como el crecer de la hierba y divagará y divagará... hasta darse de morros con algo sin saber como llegó allí. Hará como un par de semanas estaba yo en esta situación y sin saber como se me ocurrió tirar de cierto código para intentar dar "marcha atrás" en el juego de la vida de Conway, algo que por lo que parece solo sería posible por fuerza bruta (quizá que sea Turing completa tenga algo que ver :P).

Y aunque queda mucho pulir aquí y allá (solo puede obligar a las celulas vivas a mantenerse vivas, el código para las demás está escrito pero no acaba de funcionar así que hay que revisarlo), creo que puede ser interesante.

Los códigos son estos:

  • bool_solve.py (tiene unas cuantas optimizaciones con respecto al anterior)
  • life.py (el estado inicial se define con la variable state, hay ejemplos a partir de la línea 43)

Por ejemplo, figura objetivo:

Triángulo de Sierpinski

Tiene estas "soluciones":

Peleándose con P y NP

La época de exámenes es algo curioso, de repente todo lo trivial se vuelve interesante: la trayectoria de las moscas, cualquier cosa que uno se pueda encontrar en la Wikipedia...

En estas me hallaba yo ayer, así que tirando de clásicos acabe "enfrentándome" al problema de P contra NP, y para mi sorpresa creo que di con algo interesante (bueno, eso o entendí algo mal, que es lo más probable :P).

Pero no adelantemos acontecimientos, resulta que escojí un problema NP-completo, satisfacción booleana, y me lié a tirar código, este es el resultado (perdón por la escasez de comentarios):

bool_solve.py: Este es el algoritmo en sí.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99100101102103104105106107108109110111112113114115116117118119120121122123124

Getting the uploads safe

Note: ironically, the multiupload service has been taken down as well.

Yesterday megaupload falled and it's not likely that it'll recover, leaving apart the ethical implications this had the anonymous response and things like that there's something clear: it's not fun to lose your uploaded files.

And yes, there was people who actually used this services to share files without copyright over the internet!, for example as a way to replace the dropbox (which uses a privative daemon), so while the megaupload issue is not specially big, it's a good alert to take precautions. From now on, I'll opload everything to multiple servers.

Script: http://pastebin.com/rNA0Sps3

Result: http://www.multiupload.com/WBF5NQ6E1Y

Newer posts Older posts