Buenas, os traigo algo calentito y en fase de pruebas. Es una utilidad que acabo de portar y que es capaz de cifrar los elf que compilamos para que cualquier PSP los tome por archivos "oficiales". A partir de ahora podremos crear nuestros propios programas con herramientas libres y ejecutarlos en consolas con firmware oficiales o customizados. También deberían funcionar en cualquier modelo de consola. En fin, ya no necesitamos a Sony ;) .
Para firmar un EBOOT.PBP simplemente debemos hacer:
$ebootsign EBOOT.PBP EBOOT_signed.PBP
Y voilá, ahora podemos llevarnos el EBOOT_signed.PBP a cualquier PSP para probarlo.
Makefiles
Podemos añadir el siguiente target en nuestros makefiles para generar directamente los archivos firmados:
EBOOT_signed.PBP: EBOOT.PBP
ebootsign $^ $@
Y bueno, eso es todo... la aplicación está en pruebas y el código es bastante feo puesto que tiene partes de aquí y de allá. Además principalmente es un port de otra aplicación de PSP. En fin, agradecería testers, parches, críticas, etc. ;)
Donald Knuth, autor de «The art of computing programing» y creador de TeX es uno de los auténticos padres de las ciencias de la computación. Me temo que mucho menos conocido de lo que se merece.
Hola buenas, hoy voy a hablaros sobre un tema que vengo siguiendo desde hace tiempo relativo a la libertad de los usuarios sobre los cacharros que se compran. Por poner un nombre os hablaré de Sony y de la PS3.
Un Kōan es, en la tradición Zen, una especie de acertijo que el maestro propone a su discípulo para averiguar en qué punto se encuentra en su camino hacia la iluminación. Se trata de un problema cuya solución no puede ser encontrada a través de la razón, si no a través de la intuición…
Ya, ya, esto suena demasiado raro incluso para CRySoL.
He visto en varias páginas que ha nacido el primero dominio de primer nivel orientado el software libre :-) Es una iniciativa, parece ser, de Mozilla, para crear un dominio que identifique de alguna manera las webs relacionadas con el software libre.
Al parecer, Javier Bardem ha salido en "defensa" de los artistas y arremete contra los "piratas" en un artículo publicado en el diario El País, titulado El Botón Mágico. Por suerte, el usuario humitsec (fan de los tebeos de Superlópez) le ha respondido en un aplastante comentario en meneame. Lo reproduzco aquí a continuación:
Una de las cosas que más chocan al empezar a utilizar un lenguaje dinámico (Python, Ruby, Lua, etc.) es que las variables no se declaran o definen con un tipo concreto. Eso normalmente no es un problema y de hecho resulta bastante cómodo. Pero cuando un programa adquiere cierta envergadura empiezan a surgir problemas.
Poder forzar la interfaz de un método, sobre todo de un constructor es más que conveniente. Permite detectar muchos usos inadecuados cuando el usuario de una clase y su programador son personas distintas (o uno mismo si ha pasado demasiado tiempo). Esto es básico para cosas como el Diseño por contrato y otras metodologías en las que es imprescindible tener comprobación estricta de tipos.
Cuando queremos transmitir datos entre dos máquinas, almacenar la configuración o guardar datos para un uso posterior, tenemos que decidir el formato del archivo que estamos usando.
En algunos casos la decisión pasa por un archivo binario, lo cual puede estar bien en muchos casos. En otros puede ser un gran error, ya que siempre es mejor utilizar formatos existentes. Estos formatos suelen proporcionarnos librerías con el fin de facilitarnos la creación y/o el uso de los archivos.
Imaginemos que tenemos un sistema con 20 procesadores. Nuestro linux (si, el kernel) tiene un planificador (o scheduler) muy majo que reparte todos los procesos entre los procesadores de forma que todos se queden más o menos equiparados en cuanto a carga. Ahora supongamos que algunos procesos consumen de vez en cuando mucha CPU y no queremos que esta sobrecarga afecte a algunas CPU's (vale, es un escenario muy específico, pero os aseguro que se da ;)). ¿Cómo podemos alterar esta planificación para algunos casos? pues fácil, con esta receta :).
La herramienta taskset
Este programilla en Debian lo podemos encontrar en util-linux:
#aptitude install util-linux
Y es el que nos permitirá jugar con el affinity flag
En algunos sistemas esta herramienta se encuentra en el paquete schedutils.
El affinity flag
El AF es una máscara de bits que se crea para cada nuevo proceso e indica al planificador qué procesadores pueden ejecutar dicho proceso. En esta máscara cada bit representa a un procesador, siendo el procesador #0 el bit menos significativo.
Cuando un proceso se crea, por defecto su AF es 0xFFFFFFFF. Esto significa que cuando el proceso sea desalojado de un procesador, cualquier otro procesador podrá seguir con su ejecución.
Por defecto esta solución permite al planificador del kernel seleccionar cada vez cualquier CPU para cualquier proceso.
Cualquier usuario puede obtener el AF de un proceso de una forma fácil, imaginemos que el proceso tiene como PID el 12345:
$taskset -p 12345
pid 1611's current affinity mask: 3
¡Vaya! ¡os he engañado! esto me ha dicho <3> en lugar del numerajo que os había dicho... Pues muy sencillo, en el caso del ejemplo resulta que el sistema tiene sólo 2 procesadores: esto es, los dos bits menos significativos a 1 o lo que es lo mismo, 3 en decimal. ¿Qué quiere decir esto? pues que por defecto el FA tiene a 1 todos los CPU's de nuestro sistema.
Modificar el AF
Ya sabemos como funciona por defecto el AF, ahora bien, hemos dicho que un determinado proceso no queremos que nos ocupe una determinada CPU. Lo único que debemos hacer es alterar su AF: si no queremos que pueda entrar en la CPU #0 entonces su AF debe ser 0xFFFFFFFE. Ahora supongamos que el PID de dicho proceso es 12345:
#taskset -p 0xFFFFFFFE 12345
Esta solución es válida si el proceso ya estaba en ejecución, pero si queremos lanzar uno nuevo especificando su AF:
#taskset 0xFFFFFFFE /etc/init.d/lapd start
Y si somos unos vaguetes y no queremos andar con máscaras, podemos indicar también una lista de CPU's donde puede correr nuestro proceso:
#taskset -p-c 1,2,5-8 12345
Esto hace que el proceso cuyo PID es 12345 pueda ser procesado por las CPU's #1, #2, #5, #6, #7 y #8. Si queremos lanzar un proces nuevo:
#taskset -c 0 ls
Esto hace que el comando ls sea ejecutado únicamente por la CPU #0.
Un apunte más: sólo el señor root puede establecer un FA. También lo pueden hacer usuarios con CAP_SYS_NICE activo (pero eso es harina de otro gran costal).
